idnits 2.17.1 draft-lee-sip-dns-sd-uri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 857. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 870. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 6002 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-04 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-06 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Lee 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia U. 5 Expires: May 21, 2008 W. Kellerer 6 Z. Despotovic 7 DoCoMo Euro 8 November 18, 2007 10 SIP URI Service Discovery using DNS-SD 11 draft-lee-sip-dns-sd-uri-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes how to use the DNS-based Service Discovery 45 (DNS-SD), better known as Apple Bonjour, for advertising Session 46 Initiation Protocol (SIP) URIs in local area networks. Using this 47 mechanism, a SIP user agent (UA) can communicate with another UA even 48 when no SIP registrar is available, as in a wireless ad-hoc network 49 for example. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 55 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6 56 4. SIP URI Advertisement Format . . . . . . . . . . . . . . . . . 9 57 4.1. SIP URI Service Instance Name . . . . . . . . . . . . . . 9 58 4.2. TXT Record Attributes . . . . . . . . . . . . . . . . . . 11 59 4.2.1. txtvers . . . . . . . . . . . . . . . . . . . . . . . 11 60 4.2.2. name . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.2.3. contact . . . . . . . . . . . . . . . . . . . . . . . 11 62 5. Making a Call Using Discovered SIP URI . . . . . . . . . . . . 13 63 5.1. Forming the SIP Request . . . . . . . . . . . . . . . . . 13 64 5.2. Sending the SIP Request . . . . . . . . . . . . . . . . . 13 65 6. User Interface Guidelines . . . . . . . . . . . . . . . . . . 15 66 7. Other Related Mechanisms . . . . . . . . . . . . . . . . . . . 16 67 7.1. SIP Multicast . . . . . . . . . . . . . . . . . . . . . . 16 68 7.2. "sip" DNS-SD Service Type . . . . . . . . . . . . . . . . 16 69 7.3. Peer-to-Peer SIP . . . . . . . . . . . . . . . . . . . . . 17 70 8. Transport Protocol in Service Instance Name . . . . . . . . . 18 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 73 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 75 Intellectual Property and Copyright Statements . . . . . . . . . . 23 77 1. Introduction 79 The Session Initiation Protocol (SIP) [RFC3261], an application-layer 80 protocol for controlling multimedia sessions such as voice-over-IP 81 calls, uses SIP Uniform Resource Identifiers (SIP URIs) to represent 82 who to contact or where to place a call. There are two types of SIP 83 URIs. An Address-of-Record (AOR) represents the user's logical 84 identity, analogous to an email address. A contact URI, on the other 85 hand, indicates the network location of a host machine or a 86 communication device where the user can be currently reached. The 87 mappings between AORs and contact URIs are stored using SIP servers 88 called registrars, and they are used by SIP servers called proxy 89 servers to route calls (Section 10, [RFC3261]). For example, Carol, 90 whose AOR is sip:carol@chicago.com, registers 91 sip:carol@cube2214a.chicago.com as the current contact location using 92 the registrar for the chicago.com domain. When the proxy server for 93 the chicago.com domain receives a call request for 94 sip:carol@chicago.com, it looks up the binding and routes the request 95 to cube2214a.chicago.com. 97 Server-based mechanisms are not suitable for all types of networks, 98 however. Consider, for example, a wireless ad-hoc network formed 99 temporarily to address a specific situation, such as disaster 100 recovery. In this case, it is clearly impractical to deploy SIP 101 servers and configure user agents (UAs) to use the servers. What is 102 needed here is a mechanism for the SIP UAs to learn the identities 103 and locations of each other without using any server. 105 DNS-based Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd] and 106 Multicast DNS (mDNS) [I-D.cheshire-dnsext-multicastdns], better known 107 as Apple Bonjour, provide a generic multicast-based solution for 108 discovering services available in a local network without requiring 109 any server deployment. DNS-SD/mDNS defines a set of naming rules for 110 certain DNS record types that it uses for advertising and discovering 111 services. PTR records are used to enumerate service instances of a 112 given service type. A service instance name is mapped to a host name 113 and a port number using a SRV record. If a service instance has more 114 information to advertise than the host name and port number contained 115 in its SRV record, the additional information is carried in a TXT 116 record. 118 Those DNS records are not stored in a conventional unicast DNS 119 server. Instead, they are stored in a collection of mDNS daemons, 120 which are limited-functionality DNS servers running on each host in a 121 local subnet. The mDNS daemons collectively manage a special top- 122 level domain, ".local.", which is used for names that are meaningful 123 only in a local subnet. The queries and answers are sent via link- 124 local multicast using UDP port 5353 instead of 53, the conventional 125 port for DNS. Thus, an application can advertise a network service 126 to the local subnet by creating appropriate DNS records and 127 depositing them into the mDNS daemon running on the same host. The 128 mDNS daemon will then respond with these records when it hears a 129 multicast query for a matching service. We will see an example of 130 this process in Section 3. Note that creating DNS records and 131 storing them with mDNS are usually done by invoking API calls in a 132 DNS-SD/mDNS client library implementation. A hardware device can 133 also advertise its network service using DNS-SD/mDNS, in which case a 134 stripped-down implementation of mDNS customized for the specific 135 service is usually embedded in the device. 137 This document specifies how the SIP UAs in the same subnet use DNS- 138 SD/mDNS to advertise and discover the identities and locations of 139 each other, enabling the communications between them without using 140 SIP servers. Section 3 describes this process using a simple example 141 of a UA discovering a SIP URI advertised by another UA. Section 4 142 defines the format of the SIP URI advertisement, and Section 5 143 specifies the behavior of a UA that discovers a SIP URI in the local 144 network and wants to initiate a call. 146 It should be noted that the DNS-SD/mDNS mechanism described in this 147 document and the SIP server mechanism in [RFC3261] are not mutually 148 exclusive. Implementing SIP URI discovery via DNS-SD/mDNS will 149 merely augment the functionality of a SIP UA, making it more useful 150 in an ad-hoc network where the SIP servers are unavailable. 151 Section 6 discusses how such enhancements can be incorporated to the 152 existing user interface of a UA. 154 The generic nature of DNS-SD/mDNS make it a good candidate for the 155 discovery mechanism of other SIP resources such as server location 156 and capability. While we hope that the usage of DNS-SD/mDNS will 157 become more pervasive in the SIP ecosphere, the scope of this 158 document is limited to the discovery of SIP URIs among the UAs in a 159 local network. 161 2. Requirements Notation 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 3. Overview of Operation 169 This section gives an overview of SIP URI advertisement in DNS-SD/ 170 mDNS environment using a simple example scenario. 172 Consider two users, Alice and Bob, who are running SIP UAs on their 173 laptop computers on the same subnet. Assume that a DNS-SD/mDNS 174 implementation, such as Bonjour or Avahi, is installed and running on 175 both computers. Further assume that SIP registrar and proxy server 176 are not available to the UAs (there is no SIP server in the network 177 or the UAs are not configured with the local servers, for instance), 178 but the UAs are equipped with an implementation of the mechanism 179 described in this document. Alice, knowing that Bob is in the 180 vicinity with his computer connected probably to the same subnet as 181 hers, would like to make a SIP call to Bob. 183 Bob's UA advertises sip:bob@example.com, Bob's AOR, to the local 184 subnet. This is done by the UA invoking an API function in a DNS-SD/ 185 mDNS client library, which in turn connects to the mDNS daemon 186 process running on the same computer using an IPC mechanism and sends 187 the following DNS records: 189 _sipuri._udp.local. PTR sip:bob@example.com._sipuri._udp.local. 191 sip:bob@example.com._sipuri._udp.local. 192 SRV 0 0 5060 bobs-machine.local. 194 bobs-machine.local. A 192.168.0.100 196 The mDNS daemon receives and stores these records, and starts 197 listening for multicast DNS queries that might ask for those records. 198 The PTR record says that there is a service instance called 199 "sip:bob@example.com", that it is of the service type "sipuri", that 200 it uses UDP transport, and that it is available in the local subnet 201 (".local."). The SRV record maps the service instance to the host, 202 "bobs-machine.local.", and the port, 5060. Finally the A record 203 provides the IP address. In short, using these records, Bob's UA is 204 advertising that it is listening on the UDP port 5060 at 205 192.168.0.100 for a SIP request addressed to sip:bob@example.com. 207 Alice's UA tries to discover the SIP URIs being advertised in the 208 local subnet by multicasting a PTR query for "_sipuri._udp.local.". 209 (It will probably send out queries for _sipuri._tcp.local. and 210 _sipuri._sctp.local. as well, so it can also discover the UAs 211 advertising those transport protocols. But we will limit our 212 scenario to UDP for simplicity.) 214 Alice's UA receives the following two answers to its multicast PTR 215 query: 217 _sipuri._udp.local. PTR sip:bob@example.com._sipuri._udp.local. 218 _sipuri._udp.local. PTR sip:carol@chicago.com._sipuri._udp.local. 220 Those two answers came from two different machines. The mDNS daemons 221 running on Bob's and Carol's computers both heard the multicast query 222 and each replied to Alice's UA with its PTR record. Alice's UA then 223 communicates to the user, Alice, that it found the two SIP URI 224 advertisement in the local subnet. It does this perhaps by 225 displaying sip:bob@example.com and sip:carol@chicago.com in a window 226 titled "Local Users". (Section 6 discusses the user interface in 227 further detail.) 229 Alice decides that she wants to call Bob and clicks on Bob's URI 230 displayed in the window presented by her UA. Alice's UA then sends 231 another series of multicast queries, a SRV query followed by an A 232 query, to which it receives the following responses from Bob's mDNS: 234 sip:bob@example.com._sipuri._udp.local. 235 SRV 0 0 5060 bobs-machine.local. 237 bobs-machine.local. A 192.168.0.100 239 From these answers, Alice's UA obtains the IP address and port 240 number, to which it sends a SIP INVITE addressed to 241 sip:bob@example.com. 243 It should be noted that, for clarity of exposition, our example 244 glosses over many details of how the mDNS daemons actually exchange 245 DNS packets. The mDNS specification 246 ([I-D.cheshire-dnsext-multicastdns]) spends considerable efforts to 247 provide immediate and on-going discovery of services while reducing 248 network traffic. For example, a mDNS daemon will send out a 249 gratuitous multicast DNS answer packet containing all of its resource 250 records whenever it starts up, wakes from sleep, or detects a change 251 in network configuration. The other mDNS daemons in the subnet will 252 receive the gratuitous packet and cache the information contained in 253 it. Thus, in our example of Alice and Bob, what actually happened 254 could have been that Alice's mDNS might have already cached the 255 gratuitous packet sent by Bob's mDNS even before Alice launched her 256 UA, and when Alice wanted to call Bob, her mDNS could have provided 257 all the necessary DNS records from its cache without sending any 258 multicast query. DNS-SD/mDNS also tracks newly arriving services 259 using these gratuitous announcements as other UAs enter and leave the 260 subnet. 262 In many cases, an application or a device advertising a service has 263 more information to convey than what a SRV record can carry, namely, 264 the host name and port number. For example, a printer advertising a 265 LPR port should convey a queue name as well. The necessary 266 additional data can be carried in a TXT record with the same name as 267 the SRV record. In our previous example, Bob's UA could have 268 included the following TXT record in the service advertisement: 270 sip:bob@example.com._sipuri._udp.local. TXT 271 txtvers=1 name=Bob contact=;audio;video 273 Under the same name as the SRV record, it defines several name/value 274 attributes that the other UAs would find useful. Using the "name" 275 attribute, the "Local Users" window of Alice's UA can now display 276 "Bob (sip:bob@example.com)" rather than just the URI. The "contact" 277 attribute contains a contact URI that includes the IP address and 278 port number (thereby obviating the SRV and A queries) and the 279 supported media types. The formats of the attributes are defined in 280 Section 4.2. 282 4. SIP URI Advertisement Format 284 This section specifies the format of a SIP URI advertisement. 285 Section 4.1 specifies the format of the service instance name, which 286 is the name of the SRV and TXT resource records. Section 4.2 defines 287 the attribute names that can be stored in the TXT record, and 288 specifies the rules for their values. 290 4.1. SIP URI Service Instance Name 292 Section 4.1 of [I-D.cheshire-dnsext-dns-sd] specifies that a service 293 instance name in DNS-SD has the following structure: 295 . . 297 The portion specifies the DNS sub-domain where the service 298 instance is registered. It may be "local.", indicating the mDNS 299 local domain, or it may be a conventional domain name such as 300 "example.com.". 302 The portion of the SIP URI service instance name MUST be 303 "_sipuri._udp", "_sipuri._tcp", or "_sipuri._sctp", depending on the 304 transport protocol desired by the UA advertising the service 305 instance. If a UA supports multiple protocols, it SHOULD advertise 306 multiple service instances. Note that, while this usage with the 307 protocol part is in agreement with DNS SRV RR definition ([RFC2782]) 308 and with the previous usage of SRV RR in SIP (Section 4.1, 309 [RFC3263]), it does not agree with the DNS-SD guideline. This is 310 discussed further in Section 8. 312 The portion is a DNS label, containing UTF-8-encoded text, 313 limited to 63 octets in length. It is meant to be a user-friendly 314 description of the service instance, suitable for a menu-like user 315 interface display. Thus it can contain any characters including 316 spaces, punctuation, and non-Latin characters as long as they can be 317 encoded in UTF-8. 319 For the SIP URI service instance, however, there is a required 320 format. The portion of the SIP URI service instance MUST 321 start with a valid SIP or SIPS URI, optionally followed by a space 322 character and an arbitrary text further describing the URI. In 323 Augmented BNF (ABNF) [RFC2234], this is expressed as follows: 325 instance = ( SIP-URI / SIPS-URI ) [ SP description ] 327 The definition and the ABNF for SIP-URI and SIPS-URI are given in 328 Section 19.1 and Section 25.1 of [RFC3261]. SP denotes a space 329 character and "description" is an arbitrary UTF-8-encoded text 330 string. The entire instance string cannot be more than 63 octets in 331 length. 333 For example, the SIP URI service instance names for Bob's two SIP 334 devices may be: 336 sip:bob@example.com - Softphone._sipuri._udp.local. 338 sip:bob@example.com - PDA._sipuri._udp.local. 340 This scheme is also compatible with the automatic name conflict 341 resolution of Apple's mDNS implementation, which appends a numerical 342 suffix such as " (2)" to a name in order to distinguish it from 343 another instance with the same name in the same subnet. If both of 344 Bob's devices advertise themselves as "sip:bob@example.com" in such 345 an environment, the resulting service instance names will be: 347 sip:bob@example.com._sipuri._udp.local. 349 sip:bob@example.com (2)._sipuri._udp.local. 351 which are both valid SIP URI service instance names. Since an 352 advertiser is free to choose any arbitrary text for the description 353 following the URI, the other UAs discovering the service instance 354 should not attempt to parse the text for any specific information. 355 The text is meant to be displayed to the human user as is, in a menu 356 listing the discovered service instances for example. 358 The reason for requiring that the instance name begins with a valid 359 SIP URI is that having a SIP URI available in the name makes the 360 service advertisement contain sufficient information for a UA to 361 initiate a call. The UA resolves the service instance name and 362 obtains the IP address and the port number. (This is done by issuing 363 an SRV query. See Section 5, [I-D.cheshire-dnsext-dns-sd].) Then it 364 can send a SIP request using the SIP URI from the service name as the 365 Request-URI. This makes the information from the TXT record 366 (described in the next section) optional, in accordance with the 367 recommendation that the TXT record should be viewed as a performance 368 optimization (Section 6.2, [I-D.cheshire-dnsext-dns-sd]). 370 The SIP or SIPS URI in the service instance name SHOULD be an 371 Address-of-Record (AOR). It is conceivable that a UA may not be 372 configured with an AOR. A group of UAs in an ad-hoc network may be 373 configured only with user names, for example. In such cases, the UA 374 host names or IP addresses may be used to form a valid SIP URI for 375 service advertisement. 377 4.2. TXT Record Attributes 379 In addition to the service instance name, IP address and the port 380 number, DNS-SD provides a way to publish other information pertinent 381 to the service being advertised. The additional data can be stored 382 as name/value attributes in a TXT record with the same name as the 383 SRV record for the service. Each name/value pair within the TXT 384 record is preceded by a single length byte, thereby limiting the 385 length of the pair to 255 bytes. (See Section 6 of 386 [I-D.cheshire-dnsext-dns-sd] and Section 3.3.14 of [RFC1035] for 387 details.) 389 The following subsections describe the attributes defined for the SIP 390 URI service. Note that, while the presence of any of these 391 attributes in a SIP URI advertisement is optional, the presence of 392 certain attributes affects the behavior of the UA processing the 393 service instance. (See Section 5 for detail.) 395 4.2.1. txtvers 397 The "txtvers" attribute defines the version number of the TXT record 398 specification as recommended in Section 6.7, 399 [I-D.cheshire-dnsext-dns-sd]. If present, this attribute MUST be the 400 first name/value pair in the TXT record. For this specification, it 401 MUST be "txtvers=1". 403 4.2.2. name 405 The "name" attribute contains the display name of the user. For 406 example, "name=John Doe". 408 It MUST conform to the "display-name" ABNF element in Section 25.1, 409 [RFC3261], so that it can be used in the "To" SIP header, as in "To: 410 John Doe ". 412 4.2.3. contact 414 The "contact" attribute contains a SIP or SIPS URI that represents a 415 direct route to the user. The URI usually contains a fully qualified 416 domain name (FQDN) or an IP address indicating the physical contact 417 location of the user. For example, 418 "contact=sip:carol@cube2214a.chicago.com". 420 Note that, while this attribute has the same semantics as the 421 "Contact" SIP header defined in [RFC3261], the attribute does not 422 allow the full syntax of the SIP header. First, only SIP or SIPS 423 URIs are allowed in the attribute, whereas non-SIP URIs are allowed 424 in the Contact header. Non-SIP URIs are not applicable in the SIP 425 URI service discovery. Second, the attribute can contain only a 426 single URI, whereas the Contact header can contain multiple URIs in a 427 comma-separated list. We argue that multiple contact locations can 428 (and should) be advertised as multiple service instances. 430 [RFC3261] also defines two Contact parameters "q" and "expires". The 431 "q" parameter is only applicable when there are multiple Contact 432 locations. The "expires" parameter is also not relevant in this 433 environment since the service instance must be created and removed 434 according to the rules of the underlying service discovery system. 436 The attribute name/value pair has the following syntax ABNF: 438 contact-attr = "contact=" 439 ( name-addr / uri ) *( SEMI contact-extension ) 440 name-addr = [ display-name ] LAQUOT uri RAQUOT 441 uri = SIP-URI / SIPS-URI 443 SEMI, LAQUOT and RAQUOT denote ";", "<" and ">", respectively. Note 444 that whitespace is often allowed around these characters. The 445 contact attribute value has nearly the same syntax as the "contact- 446 param" element in Section 25.1 of [RFC3261]. The difference is that 447 the contact attribute syntax disallows non-SIP URIs and it omits the 448 "q" and "expires" parameters. See Section 25.1 of [RFC3261] for the 449 other syntax elements that are not expanded here, such as contact- 450 extension and display-name. Also see Section 20.10 and the last 451 paragraph of Section 20 of [RFC3261] for the important information 452 regarding the Contact header parsing rules, which are equally 453 applicable to the contact attribute. 455 The attribute syntax allows one or more contact-extension elements, 456 which are generic name/value parameter provisions for future 457 extensions. Currently, [RFC3840] defines a mechanism by which SIP 458 UAs can exchange information about their capabilities and 459 characteristics through these parameters. Such a mechanism is 460 particularly germane to service discovery. 462 5. Making a Call Using Discovered SIP URI 464 This section specifies the behavior of the UA that sends a SIP 465 request using the discovered SIP URI service instance. In 466 particular, it specifies how to form the Request-URI and the "To" 467 header of the request, and how to determine the destination host to 468 which the SIP request should be transported. Beyond that, Section 469 8.1 and 18.1 of [RFC3261] describe in detail the behavior of a UA 470 generating and sending a SIP request. 472 5.1. Forming the SIP Request 474 The "To" header MUST be formed using the SIP or SIPS URI from the 475 service instance name. The URI is either the first DNS label of the 476 service instance name if it contains no space, or the longest prefix 477 in the first DNS label that does not include the first space 478 character. (See Section 4.1.) 480 If the "name" attribute of the TXT record is available, it SHOULD be 481 used as the "display-name" in the "To" header according to the 482 formatting rules outlined in Section 20.10 of [RFC3261]. 484 The Request-URI MUST be formed using the SIP or SIPS URI from the 485 "contact" attribute of the TXT record. If the "contact" attribute is 486 not available, the Request-URI MUST be set to the same value as the 487 "To" header. 489 5.2. Sending the SIP Request 491 First, the UA determines the transport protocol from the service type 492 portion of the discovered service instance name. The three possible 493 values are "_sipuri._udp", "_sipuri._tcp", or "_sipuri._sctp", for 494 which the UDP, TCP, or SCTP transport protocol MUST be used, 495 respectively. 497 Next, the UA determines the IP address and port number to which to 498 send the request. This procedure differs depending on whether the 499 "contact" attribute is available in the TXT record. 501 If the "contact" attribute is available, the IP address and the port 502 number of the destination host MUST be determined from the SIP/SIPS 503 URI in the attribute as follows. The value of the maddr parameter of 504 the URI, if present, becomes the destination host. Otherwise, the 505 host value of the hostport component of the URI becomes the 506 destination host. (See [RFC3261] for the description of the maddr 507 parameter and the definition of the SIP/SIPS URI.) If the 508 destination host is already in the form of a numeric IP address, the 509 UA uses that address. If not, the UA performs an A or AAAA record 510 lookup of the description host to obtain the IP address. The A/AAAA 511 query should be sent to the local mDNS daemon if the destination host 512 name belongs in the ".local." domain. The DNS-SD/mDNS 513 implementations usually modify the resolver configuration of the 514 operating system to direct all .local queries to mDNS, so the UA can 515 simply make a DNS query as usual without worrying about whether it is 516 for a local name or not. If a port number is present in the SIP/SIPS 517 URI, the UA uses that port. Otherwise, the UA uses the default port 518 for the particular transport protocol. 520 If the "contact" attribute is not available, the UA MUST resolve the 521 service instance name to obtain the host name and port number to 522 which to send the request. The service instance name is resolved by 523 sending a SRV query or by calling the equivalent API routine in the 524 DNS-SD library implementation (Section 5, 525 [I-D.cheshire-dnsext-dns-sd]). The host name is then further 526 resolved to an IP address by performing an A/AAAA lookup. 528 We should note that the host name and the port number in the SRV 529 record are ignored when the "contact" attribute is present. Normally 530 the destination obtained from the contact URI will be the same as 531 that from the SRV record. But a UA has an option to advertise a 532 contact URI pointing to a host or device different from its own, 533 perhaps in order to redirect incoming calls to voice mail or to have 534 the calls go through a proxy server for accounting reasons, for 535 example. 537 As described above, the host name from the contact URI or from the 538 SRV record is resolved by performing an A/AAAA query. This is in 539 contrast with [RFC3263], which requires additional steps using NAPTR 540 and SRV lookups in resolving a host name in a SIP URI. (The SRV 541 lookups in [RFC3263] are plain SRV lookups described in [RFC2782], so 542 they should not be confused with the DNS-SD's use of SRV records that 543 we have been discussing.) The flexibility provided by the additional 544 levels of indirection specified in [RFC3263] is of limited value in 545 the usual serverless setting of DNS-SD/mDNS, so it was deemed not a 546 strong enough reason to deviate from the normal DNS-SD convention of 547 resolving a host name using an A/AAAA query. 549 6. User Interface Guidelines 551 This section considers the user interface of a UA that implements the 552 behavior specified in Section 5. As a model for our discussion, let 553 us consider a typical graphical UA that presents three user interface 554 elements: an address book window containing the AORs manually 555 maintained by the human user, another window listing the SIP URIs 556 currently available through DNS-SD, and a text edit box in which the 557 user can directly type a URI not listed in either window. 559 The address book entries and the DNS-SD entries SHOULD be presented 560 in a way that makes it clear to the user that they are two separate 561 lists. When the user selects an entry from the DNS-SD list, the UA 562 MUST follow the behavior outlined in Section 5. 564 When the user selects an entry from the address book window, the UA 565 MUST follow the normal user agent client behavior specified in 566 Section 8.1 of [RFC3261]. This means that the SIP request is routed 567 either using a configured outbound proxy or using the SIP server 568 location mechanisms described in [RFC3263]. If such an effort fails, 569 due to a network outage or a server failure for example, and there is 570 a DNS-SD entry with the same URI as the address book entry that the 571 user has selected, then (and only then) the UA MAY try the DNS-SD 572 entry with the same URI, following the behavior in Section 5. In 573 this case, the address book entry might indicate that the URI is also 574 being announced via DNS-SD advertisement. The reason for requiring 575 that the UA first follows the server mechanisms when processing an 576 address book entry is discussed in Section 9. 578 A URI directly typed in by the user MUST be processed as if it has 579 been selected from the address book window. 581 7. Other Related Mechanisms 583 7.1. SIP Multicast 585 The previous SIP specification [RFC2543] included sending INVITE 586 requests via multicast. The intended purpose was to provide the 587 mechanism where a UA can send an INVITE message to a logical entity 588 comprised of multiple hosts serving a single function such as a help 589 desk. Due to the complexity of the mechanism, the multicast INVITE 590 has been removed from the current specification. Currently the use 591 of multicast is limited to "single-hop-discovery-like" services such 592 as registrations. (Section 10.2.6 and 18.1.1, [RFC3261]) 594 Multicast REGISTER requests provide another way to discover peer 595 locations. When using multicast REGISTER, UAs send the REGISTER 596 requests to the SIP multicast address (sip.mcast.net or 224.0.1.75). 597 They would also listen to that address and keep a local database of 598 peer locations as they encounter REGISTER requests. This may seem 599 similar to the SIP URI advertisement using DNS-SD/mDNS as described 600 in this document. The most important difference is that the 601 multicast REGISTER method provides passive discovery only. Unlike in 602 the DNS-SD/mDNS environment where a UA can simply make a query, in 603 the multicast REGISTER setting a newly arriving UA would not discover 604 the existing UAs until their registrations are refreshed, which could 605 introduce up to an hour delay even if we assume no packet loss. This 606 makes multicast REGISTER unsuitable for high-churn environments such 607 as wireless ad-hoc networks. 609 7.2. "sip" DNS-SD Service Type 611 There is another DNS-SD service type related to SIP. The "sip" 612 service type is primarily used for server advertisements. Most 613 notably, it is used by Asterisk, a popular open-source software 614 system for IP PBX (). In contrast, the 615 "sipuri" service type described in this document is intended for user 616 agent advertisements. 618 Some UA implementations are currently using the "sip" service type 619 for user agent advertisements. This is not ideal because the TXT 620 attributes defined for the "sip" type are geared towards server 621 announcements, and thus are not suitable for user agent 622 advertisements. This leads the UAs using the "sip" type to ignore 623 the TXT attributes, or even worse, to define their own set of 624 attributes. Ekiga softphone () uses the "sip" 625 type, but introduces a number of TXT attributes not defined for the 626 "sip" type. Gizmo Project () uses the 627 "sip" service type to advertise SIP URIs in the same way as the 628 "sipuri" type advertisement described in this document: it uses the 629 SIP URI as the name of the SRV resource record. But it does not use 630 any TXT attribute. We encourage the UA implementations to use the 631 "sipuri" service type described in this document, which defines a set 632 of TXT attributes that are suitable for user agent advertisements. 634 7.3. Peer-to-Peer SIP 636 The IETF Peer-to-peer SIP (P2PSIP) working group has been formed 637 recently. The working group's goal is to develop protocols and 638 mechanisms to replace or augment the centralized SIP servers with the 639 services provided by the peer-to-peer network of SIP endpoints. 641 This may seem similar to the DNS-SD/mDNS setting considered in this 642 document. The difference is that while DNS-SD/mDNS is primarily for 643 local area networks, P2PSIP is concerned with the peer-to-peer 644 overlays of SIP endpoints spanning the globe. In fact, its charter 645 () 646 specifically excludes multicast and dynamic DNS based approaches from 647 the scope of its work. 649 8. Transport Protocol in Service Instance Name 651 Section 7 of [I-D.cheshire-dnsext-dns-sd] states: 653 The "_tcp" or "_udp" should be regarded as little more than 654 boilerplate text, and care should be taken not to attach too much 655 importance to it. Some might argue that the "_tcp" or "_udp" 656 should not be there at all, but this format is defined by RFC 657 2782, and that's not going to change. In addition, the presence 658 of "_tcp" has the useful side-effect that it provides a convenient 659 delegation point to hand off responsibility for service discovery 660 to a different DNS server, if so desired. 662 The web site for DNS-SD service type registration (see Section 10) 663 goes further and says: 665 Protocols that can run over either UDP or TCP (e.g. NFS) are 666 usually advertised using whichever transport is considered the 667 'normal' or 'primary' mode of operation (and clients should 668 attempt communication with the service using either or both 669 transports, as appropriate for the client). 671 This interpretation and policy are reasonable for those application 672 protocols that have clear "primary" transport protocols, but they 673 present difficulty in a protocol such as SIP that supports multiple 674 transports without favoring any particular one. [RFC3263] specifies 675 how NAPTR and SRV records are used to resolve a SIP URI into the IP 676 address, port, and transport protocol of the request destination. 677 The transport label in the SRV record ("_udp", "_tcp", or "_sctp") 678 plays an important role in determining which transport protocol 679 should be used. 681 It would be inconsistent and confusing for a SIP UA to interpret the 682 transport labels in SRV records differently depending on whether it 683 is processing a DNS-SD service or not. This document follows the 684 conventional SRV record interpretation that treats the transport 685 label as indicating the desired transport protocol (Section 4.1). We 686 believe the DNS-SD interpretation is an oversight and hope to see a 687 change in the subsequent iterations of [I-D.cheshire-dnsext-dns-sd]. 689 9. Security Considerations 691 In a DNS-SD/mDNS environment, there is no restriction on who can 692 advertise what services. An attacker who has gained access to a 693 local area network, such as an unsecured wireless network, can 694 impersonate any SIP URI simply by advertising it using DNS-SD. At a 695 minimum, a UA must be careful to present the URIs discovered through 696 DNS-SD in a way clearly distinguishable from the ones in the user's 697 address book. The discovered URIs and the address book entries 698 SHOULD be presented to the user in two separate lists. Moreover, the 699 DNS-SD entries can use the display names rather than the advertised 700 URIs in order to further indicate the fact that the URIs are not 701 authenticated in any way. This security concern underlies the user 702 interface guidelines in Section 6. 704 When it is important to verify the authenticity of the advertised 705 AORs, SIPS URIs should be used. Ideally a UA advertising a SIPS URI 706 should authenticate itself using a certificate signed by a 707 certificate authority (CA), but the burden of obtaining a CA-signed 708 certificate may not be justifiable for a few SIP end-points 709 communicating directly with each other in a local area network. In 710 such cases, self-signed certificates can be used to obtain most of 711 the security benefits provided by TLS without having to acquire a CA- 712 signed certificate. A self-signed certificate provides no 713 authentication when the connection is made for the first time. The 714 UA SHOULD present a clear warning to the user indicating that the 715 SIPS URI that the user wants to contact is using a self-signed 716 certificate, therefore it is unauthenticated, and encouraging the 717 user to verify the authenticity in some other way. Once the user has 718 successfully made the first connection (perhaps after checking the 719 authenticity by external means), the UA can store the self-signed 720 certificate in its local database so that all the subsequent 721 connections can be authenticated by comparing the certificate being 722 presented to the one stored in the local database. The usefulness of 723 this mechanism is clearly demonstrated by the widespread adoption of 724 SSH, which uses essentially the same mechanism for authenticating the 725 servers. (Section 4.1, [RFC4251]) 727 Since this document is essentially a naming and usage convention 728 within the framework of DNS-SD and mDNS, the security considerations 729 for those systems apply here as well. [I-D.cheshire-dnsext-dns-sd] 730 recommends the use of DNSSEC [RFC2535] when the authenticity of 731 information is important. [I-D.cheshire-dnsext-multicastdns] 732 suggests, among other things, IPSEC and/or DNSSEC signatures when it 733 is desirable to distinguish a group of cooperating nodes from other 734 (possibly) antagonistic ones operating on the same physical link. 736 10. IANA Considerations 738 Currently, DNS-SD service type names are not managed by IANA. 739 Section 19 of [I-D.cheshire-dnsext-dns-sd] proposes an IANA 740 allocation policy for unique application protocol or service type 741 names. Until the proposal is adopted and in force, Section 19 points 742 to for instruction on how 743 to register a unique service type name for DNS-SD. 745 The service type "sipuri" for the discovery method presented in this 746 document has been registered according to that instruction. 748 11. Normative References 750 [I-D.cheshire-dnsext-dns-sd] 751 Krochmal, M. and S. Cheshire, "DNS-Based Service 752 Discovery", draft-cheshire-dnsext-dns-sd-04 (work in 753 progress), August 2006. 755 [I-D.cheshire-dnsext-multicastdns] 756 Cheshire, S. and M. Krochmal, "Multicast DNS", 757 draft-cheshire-dnsext-multicastdns-06 (work in progress), 758 August 2006. 760 [RFC1035] Mockapetris, P., "Domain names - implementation and 761 specification", STD 13, RFC 1035, November 1987. 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 766 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 767 Specifications: ABNF", RFC 2234, November 1997. 769 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 770 RFC 2535, March 1999. 772 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 773 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 774 March 1999. 776 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 777 specifying the location of services (DNS SRV)", RFC 2782, 778 February 2000. 780 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 781 A., Peterson, J., Sparks, R., Handley, M., and E. 782 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 783 June 2002. 785 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 786 Protocol (SIP): Locating SIP Servers", RFC 3263, 787 June 2002. 789 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 790 "Indicating User Agent Capabilities in the Session 791 Initiation Protocol (SIP)", RFC 3840, August 2004. 793 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 794 Protocol Architecture", RFC 4251, January 2006. 796 Authors' Addresses 798 Jae Woo Lee 799 Columbia University 800 Dept. of Computer Science 801 1214 Amsterdam Avenue 802 New York, NY 10027 803 US 805 Email: jae@cs.columbia.edu 807 Henning Schulzrinne 808 Columbia University 809 Dept. of Computer Science 810 1214 Amsterdam Avenue 811 New York, NY 10027 812 US 814 Email: schulzrinne@cs.columbia.edu 816 Wolfgang Kellerer 817 DoCoMo Communications Laboratories Europe 818 Landsberger Str. 312 819 Munich 80687 820 Germany 822 Email: kellerer@docomolab-euro.com 824 Zoran Despotovic 825 DoCoMo Communications Laboratories Europe 826 Landsberger Str. 312 827 Munich 80687 828 Germany 830 Email: despotovic@docomolab-euro.com 832 Full Copyright Statement 834 Copyright (C) The IETF Trust (2007). 836 This document is subject to the rights, licenses and restrictions 837 contained in BCP 78, and except as set forth therein, the authors 838 retain all their rights. 840 This document and the information contained herein are provided on an 841 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 842 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 843 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 844 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 845 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 846 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 848 Intellectual Property 850 The IETF takes no position regarding the validity or scope of any 851 Intellectual Property Rights or other rights that might be claimed to 852 pertain to the implementation or use of the technology described in 853 this document or the extent to which any license under such rights 854 might or might not be available; nor does it represent that it has 855 made any independent effort to identify any such rights. Information 856 on the procedures with respect to rights in RFC documents can be 857 found in BCP 78 and BCP 79. 859 Copies of IPR disclosures made to the IETF Secretariat and any 860 assurances of licenses to be made available, or the result of an 861 attempt made to obtain a general license or permission for the use of 862 such proprietary rights by implementers or users of this 863 specification can be obtained from the IETF on-line IPR repository at 864 http://www.ietf.org/ipr. 866 The IETF invites any interested party to bring to its attention any 867 copyrights, patents or patent applications, or other proprietary 868 rights that may cover technology that may be required to implement 869 this standard. Please address the information to the IETF at 870 ietf-ipr@ietf.org. 872 Acknowledgment 874 Funding for the RFC Editor function is provided by the IETF 875 Administrative Support Activity (IASA).