idnits 2.17.1 draft-ietf-mmusic-sip-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 167 instances of too long lines in the document, the longest one being 16 characters in excess of 72. == There are 47 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 45 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances 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 2 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 214: '...Location servers MAY be co-located wit...' RFC 2119 keyword, line 244: '... server and MAY offer location se...' RFC 2119 keyword, line 288: '...lication program MAY be capable of act...' RFC 2119 keyword, line 366: '... A SIP client MUST follow the follow...' RFC 2119 keyword, line 374: '... A client SHOULD rely on ICMP "Port ...' (420 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 205 has weird spacing: '...ment if they...' == Line 270 has weird spacing: '... number as ...' == Line 295 has weird spacing: '...edirect pro...' == Line 813 has weird spacing: '...Contact ext...' == Line 816 has weird spacing: '...ndatory x ...' == (33 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD not be repeated. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 18, 1998) is 9349 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 5591 looks like a reference -- Missing reference section? '3' on line 5595 looks like a reference -- Missing reference section? '4' on line 5599 looks like a reference -- Missing reference section? '5' on line 5603 looks like a reference -- Missing reference section? '6' on line 5606 looks like a reference -- Missing reference section? '7' on line 5609 looks like a reference -- Missing reference section? '8' on line 5613 looks like a reference -- Missing reference section? '9' on line 5617 looks like a reference -- Missing reference section? '10' on line 5621 looks like a reference -- Missing reference section? '11' on line 5625 looks like a reference -- Missing reference section? '12' on line 5628 looks like a reference -- Missing reference section? '13' on line 5632 looks like a reference -- Missing reference section? '14' on line 5636 looks like a reference -- Missing reference section? '15' on line 5639 looks like a reference -- Missing reference section? '16' on line 5643 looks like a reference -- Missing reference section? '17' on line 5646 looks like a reference -- Missing reference section? '18' on line 5651 looks like a reference -- Missing reference section? '20' on line 5658 looks like a reference -- Missing reference section? '21' on line 5661 looks like a reference -- Missing reference section? '22' on line 5665 looks like a reference -- Missing reference section? '23' on line 5668 looks like a reference -- Missing reference section? '24' on line 5671 looks like a reference -- Missing reference section? 'H6' on line 1330 looks like a reference -- Missing reference section? '19' on line 5655 looks like a reference -- Missing reference section? '25' on line 5675 looks like a reference -- Missing reference section? '26' on line 5678 looks like a reference -- Missing reference section? '27' on line 5681 looks like a reference -- Missing reference section? '28' on line 5686 looks like a reference -- Missing reference section? 'H11' on line 3038 looks like a reference -- Missing reference section? '29' on line 5689 looks like a reference -- Missing reference section? '30' on line 5694 looks like a reference -- Missing reference section? '1' on line 5588 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MMUSIC WG 3 Internet Draft Handley/Schulzrinne/Schooler/Rosenberg 4 ietf-mmusic-sip-09.txt ISI/Columbia U./Caltech/Bell Labs. 5 September 18, 1998 6 Expires: February 1999 8 SIP: Session Initiation Protocol 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 The Session Initiation Protocol (SIP) is an application- 33 layer control (signaling) protocol for creating, 34 modifying and terminating sessions with one or more 35 participants. These sessions include Internet multimedia 36 conferences, Internet telephone calls and multimedia 37 distribution. Members in a session can communicate via 38 multicast or via a mesh of unicast relations, or a 39 combination of these. 41 SIP invitations used to create sessions carry session 42 descriptions which allow participants to agree on a set 43 of compatible media types. It supports user mobility by 44 proxying and redirecting requests to the user's current 45 location. Users can register their current location. SIP 46 is not tied to any particular conference control 47 protocol. SIP is designed to be independent of the 48 lower-layer transport protocol and can be extended with 49 additional capabilities. 51 This document is a product of the Multi-party Multimedia 52 Session Control (MMUSIC) working group of the Internet 53 Engineering Task Force. Comments are solicited and 54 should be addressed to the working group's mailing list 55 at confctrl@isi.edu and/or the authors. 57 1 Introduction 59 1.1 Overview of SIP Functionality 61 The Session Initiation Protocol (SIP) is an application-layer control 62 protocol that can establish, modify and terminate multimedia sessions 63 or calls. These multimedia sessions include multimedia conferences, 64 distance learning, Internet telephony and similar applications. SIP 65 can invite both persons and "robots", such as a media storage 66 service. SIP can invite parties to both unicast and multicast 67 sessions; the initiator does not necessarily have to be a member of 68 the session to which it is inviting. Media and participants can be 69 added to an existing session. 71 SIP can be used to initiate sessions as well as invite members to 72 sessions that have been advertised and established by other means. 73 Sessions can be advertised using multicast protocols such as SAP, 74 electronic mail, news groups, web pages or directories (LDAP), among 75 others. 77 SIP transparently supports name mapping and redirection services, 78 allowing the implementation of ISDN and Intelligent Network telephony 79 subscriber services. These facilities also enable personal mobility 80 services, this is defined as: "Personal mobility is the ability of 81 end users to originate and receive calls and access subscribed 82 telecommunication services on any terminal in any location, and the 83 ability of the network to identify end users as they move. Personal 84 mobility is based on the use of a unique personal identity (i.e., 85 mobility complements terminal mobility, i.e., the ability to maintain 86 communications when moving a single end system from one subnet to 87 another. 89 SIP supports five facets of establishing and terminating multimedia 90 communications: 92 User location: determination of the end system to be used for 93 communication; 95 User capabilities: determination of the media and media parameters to 96 be used; 98 User availability: determination of the willingness of the called 99 party to engage in communications; 101 Call setup: "ringing", establishment of call parameters at both 102 called and calling party; 104 Call handling: including transfer and termination of calls. 106 SIP can also initiate multi-party calls using a multipoint control 107 unit (MCU) or fully-meshed interconnection instead of multicast. 108 Internet telephony gateways that connect PSTN parties can also use 109 SIP to set up calls between them. 111 SIP is designed as part of the overall IETF multimedia data and 112 control architecture currently incorporating protocols such as RSVP 113 (RFC 2205 [2]) for reserving network resources, the real-time 114 transport protocol (RTP) (RFC 1889 [3]) for transporting real-time 115 data and providing QOS feedback, the real-time streaming protocol 116 (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media, 117 the session announcement protocol (SAP) for advertising multimedia 118 sessions via multicast and the session description protocol (SDP) 119 (RFC 2327 [5]) for describing multimedia sessions. However, the 120 functionality and operation of SIP does not depend on any of these 121 protocols. 123 SIP can also be used in conjunction with other call setup and 124 signaling protocols. In that mode, an end system uses SIP exchanges 125 to determine the appropriate end system address and protocol from a 126 given address that is protocol-independent. For example, SIP could be 127 used to determine that the party can be reached via H.323, obtain the 128 H.245 gateway and user address and then use H.225.0 to establish the 129 call. 131 In another example, SIP might be used to determine that the callee is 132 reachable via the public switched telephone network (PSTN) and 133 indicate the phone number to be called, possibly suggesting an 134 Internet-to-PSTN gateway to be used. 136 SIP does not offer conference control services such as floor control 137 or voting and does not prescribe how a conference is to be managed, 138 but SIP can be used to introduce conference control protocols. SIP 139 does not allocate multicast addresses. 141 SIP can invite users to sessions with and without resource 142 reservation. SIP does not reserve resources, but can convey to the 143 invited system the information necessary to do this. 145 1.2 Terminology 147 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 148 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 149 and "OPTIONAL" are to be interpreted as described in RFC 2119 [6] and 150 indicate requirement levels for compliant SIP implementations. 152 1.3 Definitions 154 This specification uses a number of terms to refer to the roles 155 played by participants in SIP communications. The definitions of 156 client, server and proxy are similar to those used by the Hypertext 157 Transport Protocol (HTTP) (RFC 2068 [7]). The terms URI and URL are 158 defined in [8]. The following terms have special significance for 159 SIP. 161 Call: A call consists of all participants in a conference invited by 162 a common source. A SIP call is identified by a globally unique 163 call-id (Section 6.12). Thus, if a user is, for example, invited 164 to the same multicast session by several people, each of these 165 invitations will be a unique call. A point-to-point Internet 166 telephony conversation maps into a single SIP call. In a MCU- 167 based call-in conference, each participant uses a separate call 168 to invite himself to the MCU. 170 Call leg: A call leg is identified by the combination of Call-ID, To 171 and From. 173 Client: An application program that establishes connections for the 174 purpose of sending requests. Clients may or may not interact 175 directly with a human user. User agents and proxies contain 176 clients (and servers). 178 Conference: A multimedia session (see below), identified by a common 179 session description. A conference can have zero or more members 180 and includes the cases of a multicast conference, a full-mesh 181 conference and a two-party "telephone call", as well as 182 combinations of these. Any number of calls can be used to 183 create a conference. 185 Downstream: Requests sent in the direction from the caller to the 186 callee. 188 Final response: A response that terminates a SIP transaction, as 189 opposed to a provisional response that does not. All 2xx, 3xx, 190 4xx, 5xx and 6xx responses are final. 192 Initiator, calling party, caller: The party initiating a conference 193 invitation. Note that the calling party does not have to be the 194 same as the one creating the conference. 196 Invitation: A request sent to a user (or service) requesting 197 participation in a session. A successful SIP invitation consists 198 of two transactions: an INVITE request followed by an ACK 199 request. 201 Invitee, invited user, called party, callee: The person or service 202 that the calling party is trying to invite to a conference. 204 Isomorphic request or response: Two requests or responses are defined 205 to be isomorphic for the purposes of this document if they have 206 the same values for the Call-ID, To, From and CSeq header 207 fields. In addition, requests have to have the same Request-URI. 209 Location server: See location service 211 Location service: A location service is used by a SIP redirect or 212 proxy server to obtain information about a callee's possible 213 location(s). Location services are offered by location servers. 214 Location servers MAY be co-located with a SIP server, but the 215 manner in which a SIP server requests location services is 216 beyond the scope of this document. 218 Parallel search: In a parallel search, a proxy issues several 219 requests to possible user locations upon receiving an incoming 220 request. Rather than issuing one request and then waiting for 221 the final response before issuing the next request as in a 222 sequential search , a parallel search issues requests without 223 waiting for the result of previous requests. 225 Provisional response: A response used by the server to indicate 226 progress, but that does not terminate a SIP transaction. 1xx 227 responses are provisional, other responses are considered final 229 Proxy, proxy server: An intermediary program that acts as both a 230 server and a client for the purpose of making requests on behalf 231 of other clients. Requests are serviced internally or by passing 232 them on, possibly after translation, to other servers. A proxy 233 interprets, and, if necessary, rewrites a request message before 234 forwarding it. 236 Redirect server: A redirect server is a server that accepts a SIP 237 request, maps the address into zero or more new addresses and 238 returns these addresses to the client. Unlike a proxy server , 239 it does not initiate its own SIP request. Unlike a user agent 240 server , it does not accept calls. 242 Registrar: A registrar is server that accepts REGISTER requests. A 243 registrar is typically co-located with a proxy or redirect 244 server and MAY offer location services. 246 Ringback: Ringback is the signaling tone produced by the calling 247 client's application indicating that a called party is being 248 alerted (ringing). 250 Server: A server is an application program that accepts requests in 251 order to service requests and sends back responses to those 252 requests. Servers are either proxy, redirect or user agent 253 servers or registrars. 255 Session: "A multimedia session is a set of multimedia senders and 256 receivers and the data streams flowing from senders to 257 receivers. A multimedia conference is an example of a multimedia 258 session." (RFC 2327 [5]) (A session as defined for SDP can 259 comprise one or more RTP sessions.) As defined, a callee can be 260 invited several times, by different calls, to the same session. 261 If SDP is used, a session is defined by the concatenation of the 262 user name , session id , network type , address type and address 263 elements in the origin field. 265 (SIP) transaction: A SIP transaction occurs between a client and a 266 server and comprises all messages from the first request sent 267 from the client to the server up to a final (non-1xx) response 268 sent from the server to the client. A transaction is identified 269 by the CSeq sequence number (Section 6.17) within a single call 270 leg The ACK request has the same CSeq number as the 271 corresponding INVITE request, but comprises a transaction of its 272 own. 274 Upstream: Responses sent in the direction from the called client to 275 the caller. 277 URL-encoded: A character string encoded according to RFC 1738, 278 Section 2.2 [9]. 280 User agent client (UAC), calling user agent: A user agent client is a 281 client application that initiates the SIP request. 283 User agent server (UAS), called user agent: A user agent server is a 284 server application that contacts the user when a SIP request is 285 received and that returns a response on behalf of the user. The 286 response accepts, rejects or redirects the request. 288 An application program MAY be capable of acting both as a client and 289 a server. For example, a typical multimedia conference control 290 application would act as a user agent client to initiate calls or to 291 invite others to conferences and as a user agent server to accept 292 invitations. The properties of the different SIP server types are 293 summarized in Table 1. 295 property redirect proxy user agent registrar 296 server server server 297 __________________________________________________________________________ 298 also acts as a SIP client no yes no no 299 returns 1xx status yes yes yes yes 300 returns 2xx status no yes yes yes 301 returns 3xx status yes yes yes yes 302 returns 4xx status yes yes yes yes 303 returns 5xx status yes yes yes yes 304 returns 6xx status no yes yes no 305 inserts Via header no yes no no 306 accepts ACK yes yes yes no 308 Table 1: Properties of the different SIP server types 310 1.4 Summary of SIP Operation 312 This section explains the basic protocol functionality and operation. 313 Callers and callees are identified by SIP addresses, described in 314 Section 1.4.1. When making a SIP call, a caller first locates the 315 appropriate server (Section 1.4.2) and then sends a SIP request 316 (Section 1.4.3). The most common SIP operation is the invitation 317 (Section 1.4.4). Instead of directly reaching the intended callee, a 318 SIP request may be redirected or may trigger a chain of new SIP 319 requests by proxies (Section 1.4.5). Users can register their 320 location(s) with SIP servers (Section 4.2.6). 322 1.4.1 SIP Addressing 324 The "objects" addressed by SIP are users at hosts, identified by a 325 SIP URL. The SIP URL takes the form similar to a mailto or telnet 326 URL, i.e., user@host user part is a user name, a civil name or a 327 telephone number. The host part is either a domain name having a DNS 328 SRV (RFC 2052 [10]), MX (RFC 974 [11], CNAME or A record (RFC 1035 329 [12]), or a numeric network address. 331 A user's SIP address can be obtained out-of-band, can be learned via 332 existing media agents, can be included in some mailers' message 333 headers, or can be recorded during previous invitation interactions. 334 In many cases, a user's SIP URL can be guessed from his email 335 address. 337 Examples of SIP URLs include: 339 sip:mjh@metro.isi.edu 340 sip:watson@bell-telephone.com 341 sip:root@193.175.132.42 342 sip:info@ietf.org 344 A SIP URL address can designate an individual (possibly located at 345 one of several end systems), the first available person from a group 346 of individuals or a whole group. The form of the address, e.g., 347 sip:sales@example.com , is not sufficient, in general, to determine 348 the intent of the caller. 350 If a user or service chooses to be reachable at an address that is 351 guessable from the person's name and organizational affiliation, the 352 traditional method of ensuring privacy by having an unlisted "phone" 353 number is compromised. However, unlike traditional telephony, SIP 354 offers authentication and access control mechanisms and can avail 355 itself of lower-layer security mechanisms, so that client software 356 can reject unauthorized or undesired call attempts. 358 1.4.2 Locating a SIP Server 360 When a client wishes to send a request, the client either sends it to 361 a locally configured SIP proxy server (as in HTTP), independent of 362 the Request-URI, or sends it to the IP address and port corresponding 363 to the Request-URI. For the latter case, the client performs the 364 following steps to obtain the server's IP address. 366 A SIP client MUST follow the following steps to resolve the host part 367 of the Request-URI. If a client supports only TCP or UDP, but not 368 both, the client omits the respective address type. If the SIP 369 address contains a port number, that number is to be used, otherwise, 370 the default port number 5060 is to be used. The default port number 371 is the same for UDP and TCP. In all cases, the client first attempts 372 to contact the server using UDP, then TCP. 374 A client SHOULD rely on ICMP "Port Unreachable" messages rather than 375 time-outs to determine that a server is not reachable at a particular 376 address. (For socket-based programs: For TCP, connect() returns 377 ECONNREFUSED if there is no server at the designated address; for 378 UDP, the socket needs to be bound to the destination address using 379 connect() rather than sendto() or similar so that a second write() 380 fails with ECONNREFUSED. ) 382 If the SIP address contains a numeric IP address, the client contacts 383 the SIP server at that address. Otherwise, the client follows the 384 steps below. 386 1. If there is a SRV DNS resource record (RFC 2052 [10]) of 387 type sip.udp or type sip.tcp, order all such records by 388 their priority value and attempt to contact the servers in 389 that order. If a port number is explicitly specified in the 390 SIP URL, it overrides the port number in the SRV record. It 391 is RECOMMENDED that DNS zone files give higher weight to 392 servers running UDP than those running TCP. If a server 393 responds, skip the remaining steps below. 395 2. If there is a DNS MX record (RFC 974 [11]), contact the 396 hosts listed in their order of preference at the port 397 number listed in the URL or the default SIP port number if 398 none. For each host listed, first try to contact the SIP 399 server using UDP, then TCP. If a server responds, skip the 400 remaining steps. 402 3. Finally, check if there is a DNS CNAME or A record for the 403 given host and try to contact a SIP server at the one or 404 more addresses listed, again trying first UDP, then TCP. If 405 a server responds, skip the remaining step. 407 4. If all of the above methods fail to locate a server, the 408 caller MAY contact an SMTP server at the user's host and 409 use the SMTP EXPN command to obtain an alternate address 410 and repeat the steps above. As a last resort, a client MAY 411 choose to deliver the session description to the callee 412 using electronic mail. 414 A client MAY cache the result of the reachability steps for a 415 particular address and retry that host address for the next request. 416 If the client does not find a SIP server at the cached address, it 417 MUST start the search at the beginning of the sequence. 419 This sequence is modeled after that described for SMTP, 420 where MX records are to be checked before A records (RFC 421 1123 [13]). 423 1.4.3 SIP Transaction 425 Once the host part has been resolved to a SIP server, the client 426 sends one or more SIP requests to that server and receives one or 427 more responses from the server. A request (and its retransmissions) 428 together with the responses triggered by that request make up a SIP 429 transaction. The ACK request following an INVITE is not part of the 430 transaction since it may traverse a different set of hosts. 432 If TCP is used, request and responses within a single SIP transaction 433 are carried over the same TCP connection (see Section 10). Several 434 SIP requests from the same client to the same server MAY use the same 435 TCP connection or MAY open a new connection for each request. 437 If the client sent the request via unicast UDP, the response is sent 438 to the address contained in the next Via header field (Section 6.40) 439 of the response. If the request is sent via multicast UDP, the 440 response is directed to the same multicast address and destination 441 port. For UDP, reliability is achieved using retransmission (Section 442 10). 444 The SIP message format and operation is independent of the transport 445 protocol. 447 1.4.4 SIP Invitation 449 A successful SIP invitation consists of two requests, INVITE followed 450 by ACK. The INVITE (Section 4.2.1) request asks the callee to join a 451 particular conference or establish a two-party conversation. After 452 the callee has agreed to participate in the call, the caller confirms 453 that it has received that response by sending an ACK (Section 4.2.2) 454 request. If the caller no longer wants to participate in the call, it 455 sends a BYE request instead of an ACK. 457 The INVITE request typically contains a session description, for 458 example written in SDP (RFC 2327 [5]) format, that provides the 459 called party with enough information to join the session. For 460 multicast sessions, the session description enumerates the media 461 types and formats that are allowed to be distributed to that session. 462 For a unicast session, the session description enumerates the media 463 types and formats that the caller is willing to receive and where it 464 wishes the media data to be sent. In either case, if the callee 465 wishes to accept the call, it responds to the invitation by returning 466 a similar description listing the media it wishes to receive. For a 467 multicast session, the callee SHOULD only return a session 468 description if it is unable to receive the media indicated in the 469 caller's description or wants to receive data via unicast. 471 The protocol exchanges for the INVITE method are shown in Fig. 1 for 472 a proxy server and in Fig. 2 for a redirect server. (Note that the 473 messages shown in the figures have been abbreviated slightly.) In 474 Fig. 1, the proxy server accepts the INVITE request (step 1), 475 contacts the location service with all or parts of the address (step 476 2) and obtains a more precise location (step 3). The proxy server 477 then issues a SIP INVITE request to the address(es) returned by the 478 location service (step 4). The user agent server alerts the user 479 (step 5) and returns a success indication to the proxy server (step 480 6). The proxy server then returns the success result to the original 481 caller (step 7). The receipt of this message is confirmed by the 482 caller using an ACK request, which is forwarded to the callee (steps 483 8 and 9). Note that an ACK can also be sent directly to the callee, 484 bypassing the proxy. All requests and responses have the same Call- 485 ID. 487 +....... cs.columbia.edu .......+ 488 : : 489 : (~~~~~~~~~~) : 490 : ( location ) : 491 : ( service ) : 492 : (~~~~~~~~~~) : 493 : ^ | : 494 : | hgs@play : 495 : 2| 3| : 496 : | | : 497 : henning | : 498 +.. cs.tu-berlin.de ..+ 1: INVITE : | | : 499 : : henning@cs.col: | | 4: INVITE 5: ring : 500 : cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) : 501 : <........................( )<.........( ) : 502 : : 7: 200 OK : ( )6: 200 OK ( ) : 503 : : : ( tune ) ( play ) : 504 : : 8: ACK : ( )9: ACK ( ) : 505 : ========================>(~~~~~~)=========>(~~~~~~) : 506 +.....................+ +...............................+ 508 ====> SIP request 509 ....> SIP response 510 ----> non-SIP protocols 512 Figure 1: Example of SIP proxy server 514 The redirect server shown in Fig. 2 accepts the INVITE request (step 515 1), contacts the location service as before (steps 2 and 3) and, 516 instead of contacting the newly found address itself, returns the 517 address to the caller (step 4), which is then acknowledged via an ACK 518 request (step 5). The caller issues a new request, with the same 519 call-ID but a higher CSeq, to the address returned by the first 520 server (step 6). In the example, the call succeeds (step 7). The 521 caller and callee complete the handshake with an ACK (step 8). 523 The next section discusses what happens if the location service 524 returns more than one possible alternative. 526 1.4.5 Locating a User 528 A callee may move between a number of different end systems over 529 time. These locations can be dynamically registered with the SIP 530 server (Sections 1.4.7, 4.2.6). A location server MAY also use one or 531 more other protocols, such as finger (RFC 1288 [14]), rwhois (RFC 532 2167 [15]), LDAP (RFC 1777 [16]), multicast-based protocols [17] or 533 operating-system dependent mechanisms to actively determine the end 534 system where a user might be reachable. A location server MAY return 535 several locations because the user is logged in at several hosts 536 simultaneously or because the location server has (temporarily) 537 inaccurate information. The SIP server combines the results to yield 538 a list of a zero or more locations. It is recommended that each 539 location server sorts results according to the likelihood of success. 541 The action taken on receiving a list of locations varies with the 542 type of SIP server. A SIP redirect server returns the list to the 543 client as Contact headers (Section 6.13). A SIP proxy server can 544 sequentially or in parallel try the addresses until the call is 545 successful (2xx response) or the callee has declined the call (6xx 546 response). With sequential attempts, a proxy server can implement an 547 "anycast" service. 549 If a proxy server forwards a SIP request, it MUST add itself to the 550 end of the list of forwarders noted in the Via (Section 6.40) 551 headers. The Via trace ensures that replies can take the same path 552 back, ensuring correct operation through compliant firewalls and 553 avoiding request loops. On the response path, each host MUST remove 554 its Via, so that routing internal information is hidden from the 555 callee and outside networks. A proxy server MUST check that it does 556 not generate a request to a host listed in the Via sent-by, via- 557 received or via-maddr parameters (Section 6.40). (Note: If a host has 558 several names or network addresses, this does not always work. Thus, 559 each host also checks if it is part of the Via list.) 561 A SIP invitation may traverse more than one SIP proxy server. If one 562 of these "forks" the request, i.e., issues more than one request in 563 response to receiving the invitation request, it is possible that a 564 client is reached, independently, by more than one copy of the 565 invitation request. Each of these copies bears the same Call-ID. The 566 user agent MUST return the appropriate status response. Duplicate 567 +....... cs.columbia.edu .......+ 568 : : 569 : (~~~~~~~~~~) : 570 : ( location ) : 571 : ( service ) : 572 : (~~~~~~~~~~) : 573 : ^ | : 574 : | hgs@play : 575 : 2| 3| : 576 : | | : 577 : henning| : 578 +.. cs.tu-berlin.de ..+ 1: INVITE : | | : 579 : : henning@cs.col: | | : 580 : cz@cs.tu-berlin.de =======================>(~~~~~~) : 581 : | ^ | <.......................( ) : 582 : | . | : 4: 302 Moved : ( ) : 583 : | . | : hgs@play : ( tune ) : 584 : | . | : : ( ) : 585 : | . | : 5: ACK : ( ) : 586 : | . | =======================>(~~~~~~) : 587 : | . | : : : 588 +.......|...|.........+ : : 589 | . | : : 590 | . | : : 591 | . | : : 592 | . | : : 593 | . | 6: INVITE hgs@play.cs.columbia.edu (~~~~~~) : 594 | . ==================================================> ( ) : 595 | ..................................................... ( ) : 596 | 7: 200 OK : ( play ) : 597 | : ( ) : 598 | 8: ACK : ( ) : 599 ======================================================> (~~~~~~) : 600 +...............................+ 602 ====> SIP request 603 ....> SIP response 604 ----> non-SIP protocols 606 Figure 2: Example of SIP redirect server 607 requests are not an error. 609 1.4.6 Changing an Existing Session 611 In some circumstances, it is desirable to change the parameters of an 612 existing session. For example, two parties may have been conversing 613 and then want to add a third party, switching to multicast for 614 efficiency. One of the participants invites the third party with the 615 new multicast address and simultaneously sends an INVITE to the 616 second party, with the new multicast session description, but with 617 the old call identifier. 619 1.4.7 Registration Services 621 The REGISTER request allows a client to let a proxy or redirect 622 server know at which address(es) it can be reached. A client MAY also 623 use it to install call handling features at the server. 625 1.5 Protocol Properties 627 1.5.1 Minimal State 629 A single conference session or call involves one or more SIP 630 request-response transactions. Proxy servers do not have to keep 631 state for a particular call, however, they MAY maintain state for a 632 single SIP transaction, as discussed in Section 12. For efficiency, a 633 server MAY cache the results of location service requests. 635 1.5.2 Lower-Layer-Protocol Neutral 637 SIP makes minimal assumptions about the underlying transport and 638 network-layer protocols. The lower-layer can provide either a packet 639 or a byte stream service, with reliable or unreliable service. 641 In an Internet context, SIP is able to utilize both UDP and TCP as 642 transport protocols, among others. UDP allows the application to more 643 carefully control the timing of messages and their retransmission, to 644 perform parallel searches without requiring TCP connection state for 645 each outstanding request, and to use multicast. Routers can more 646 readily snoop SIP UDP packets. TCP allows easier passage through 647 existing firewalls, and given the similar protocol design, allows 648 common servers for SIP, HTTP and the Real Time Streaming Protocol 649 (RTSP) (RFC 2326 [4]). 651 When TCP is used, SIP can use one or more connections to attempt to 652 contact a user or to modify parameters of an existing conference. 653 Different SIP requests for the same SIP call MAY use different TCP 654 connections or a single persistent connection, as appropriate. 656 For concreteness, this document will only refer to Internet 657 protocols. However, SIP MAY also be used directly with protocols 658 such as ATM AAL5, IPX, frame relay or X.25. The necessary naming 659 conventions are beyond the scope of this document. User agents SHOULD 660 implement both UDP and TCP transport, proxy and redirect servers 661 MUST. 663 1.5.3 Text-Based 665 SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This 666 allows easy implementation in languages such as Java, Tcl and Perl, 667 allows easy debugging, and most importantly, makes SIP flexible and 668 extensible. As SIP is used for initiating multimedia conferences 669 rather than delivering media data, it is believed that the additional 670 overhead of using a text-based protocol is not significant. 672 2 SIP Uniform Resource Locators 674 SIP URLs are used within SIP messages to indicate the originator 675 (From), current destination (Request-URI) and final recipient (To) of 676 a SIP request, and to specify redirection addresses (Contact). A SIP 677 URL can also be embedded in web pages or other hyperlinks to indicate 678 that a particular user or service can be called via SIP. When used 679 as a hyperlink, the SIP URL indicates the use of the INVITE method. 681 The SIP URL scheme is defined to allow setting SIP request-header 682 fields and the SIP message-body. 684 This corresponds to the use of mailto: URLs. It makes it 685 possible, for example, to specify the subject, urgency or 686 media types of calls initiated through a web page or as 687 part of an email message. 689 A SIP URL follows the guidelines of RFC 2396 [18] and has the syntax 690 shown in Fig. 3. Note that reserved characters have to be escaped. 692 The URI character classes referenced above are described in Section 693 C. 695 userinfo: The SIP scheme MAY use the format "user:password" in the 696 userinfo field. The use of passwords in the userinfo is NOT 697 RECOMMENDED, because the passing of authentication information 698 in clear text (such as URIs) has proven to be a security risk in 699 almost every case where it has been used. 701 SIP-URL = "sip:" [ userinfo "@" ] hostport 702 url-parameters [ headers ] 703 userinfo = user [ ":" password ] 704 user = *( unreserved | escaped 705 | "&" | "=" | "+" | "$" | "," ) 706 password = *( unreserved | escaped 707 | "&" | "=" | "+" | "$" | "," ) 708 hostport = host [ ":" port ] 709 host = hostname | IPv4address 710 hostname = *( domainlabel "." ) toplabel [ "." ] 711 domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum 712 toplabel = alpha | alpha *( alphanum | "-" ) alphanum 713 IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit 714 port = *digit 715 url-parameters = *( ";" url-parameter ) 716 url-parameter = transport-param | user-param | method-param 717 | ttl-param | maddr-param | other-param 718 transport-param = "transport=" ( "udp" | "tcp" ) 719 user-param = "user=" ( "phone" | "ip" ) 720 method-param = "method=" Method 721 ttl-param = "ttl=" ttl 722 ttl = 1*3DIGIT ; 0 to 255 723 maddr-param = "maddr=" host 724 other-param = *uric 725 headers = "?" header *( "&" header ) 726 header = hname "=" hvalue 727 hname = *uric 728 hvalue = *uric 729 uric = reserved | unreserved | escaped 730 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | 731 "$" | "," 732 digits = 1*DIGIT 734 Figure 3: SIP URL syntax 736 If the host is an Internet telephony gateway, the user field MAY also 737 encode a telephone number using the notation of telephone-subscriber 738 (Fig. 4). The telephone number is a special case of a user name and 739 cannot be distinguished by a BNF. Thus, a URL parameter, user, is 740 added to distinguish telephone numbers from user names. The phone 741 identifier is to be used when connecting to a telephony gateway. Even 742 without this parameter, recipients of SIP URLs MAY interpret the 743 pre-@ part as a phone number if local restrictions on the name space 744 for user name allow it. 746 telephone-subscriber = global-phone-number | local-phone-number 747 global-phone-number = "+" 1*phonedigit [isdn-subaddress] 748 [post-dial] 749 local-phone-number = 1*(phonedigit | dtmf-digit | 750 pause-character) [isdn-subaddress] 751 [post-dial] 752 isdn-subaddress = ";isub=" 1*phonedigit 753 post-dial = ";postd=" 1*(phonedigit | dtmf-digit 754 | pause-character) 755 phonedigit = DIGIT | visual-separator 756 visual-separator = "-" | "." 757 pause-character = one-second-pause | wait-for-dial-tone 758 one-second-pause = "p" 759 wait-for-dial-tone = "w" 760 dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" 762 Figure 4: SIP URL syntax; telephone subscriber 764 If a server handles SIP addresses for another domain, it MUST URL- 765 encode the "@" character (%40). The ";" character MUST be URL- 766 encoded, as otherwise it is not possible to distinguish, in one 767 parsing pass, the case host;parameter and user;moreuser@host 769 host: The mailto: URL and RFC 822 email addresses require that 770 numeric host addresses ("host numbers") are enclosed in square 771 brackets (presumably, since host names might be numeric), while 772 host numbers without brackets are used for all other URLs. The 773 SIP URL requires the latter form, without brackets. 775 port: If missing, the port number is assumed to be the SIP default 776 port, 5060. 778 URL parameters: SIP URLs can define specific parameters of the 779 request. URL parameters are added after the host component and 780 are separated by semi-colons. The transport parameter determines 781 the the transport mechanism (UDP or TCP). UDP is to be assumed 782 when no explicit transport parameter is included. The maddr 783 parameter provides the server address to be contacted for this 784 user, overriding the address supplied in the host field. This 785 address is typically a multicast address, but could also be the 786 address of a backup server. The ttl parameter determines the 787 time-to-live value of the UDP multicast packet and MUST only be 788 used if maddr is a multicast address and the transport protocol 789 is UDP. The user parameter was described above. For example, to 790 specify to call j.doe@big.com using multicast to 239.255.255.1 791 with a ttl of 15, the following URL would be used: 793 sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 795 The transport, maddr, and ttl parameters MUST NOT be used in the From 796 and To header fields and the Request-URI; they are ignored if 797 present. 799 Headers: Headers of the SIP request can be defined with the "?" 800 mechanism within a SIP URL. The special hname "body" indicates 801 that the associated hvalue is the message-body of the SIP INVITE 802 request. Headers MUST NOT be used in the From and To header 803 fields and the Request-URI; they are ignored if present. 805 Method: The method of the SIP request can be specified with the 806 method parameter. This parameter MUST NOT be used in the From 807 and To header fields and the Request-URI; they are ignored if 808 present. 810 Table 2 summarizes where the components of the SIP URL can be used 811 and what default values they assume if not present. 813 default Request-URI To From Contact external 814 user -- x x x x x 815 password -- x x x x 816 host mandatory x x x x x 817 port 5060 x x x x x 818 user-param ip x x x x x 819 method INVITE x x 820 maddr-param -- x x 821 ttl-param 1 x x 822 transport-param -- x x 823 headers -- x x 825 Table 2: Use and default values of URL components for SIP headers, 826 Request-URI and references 828 Examples of SIP URLs are: 830 sip:j.doe@big.com 831 sip:j.doe:secret@big.com;transport=tcp 832 sip:j.doe@big.com?subject=project 833 sip:+1-212-555-1212:1234@gateway.com;user=phone 834 sip:1212@gateway.com 835 sip:alice@10.1.2.3 836 sip:alice@example.com;tag=f81d4fae-7dec-11d0-a765-00a0c91e6bf6 837 sip:alice 838 sip:alice@registrar.com;method=REGISTER 840 Within a SIP message, URLs are used to indicate the source and 841 intended destination of a request, redirection addresses and the 842 current destination of a request. Normally all these fields will 843 contain SIP URLs. 845 SIP URLs are case-insensitive, so that for example the two URLs 846 sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All 847 URL parameters are included when comparing SIP URLs for equality. 849 SIP header fields MAY contain non-SIP URLs. As an example, if a call 850 from a telephone is relayed to the Internet via SIP, the SIP From 851 header field might contain a phone URL. 853 3 SIP Message Overview 855 SIP is a text-based protocol and uses the ISO 10646 character set in 856 UTF-8 encoding (RFC 2279 [20]). Lines are terminated by CRLF, but 857 receivers MUST also interpret CR and LF by themselves as line 858 terminators. 860 Except for the above difference in character sets, much of the 861 message syntax is identical to HTTP/1.1; rather than repeating it 862 here we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 863 specification (RFC 2068 [7]). In addition, we describe SIP in both 864 prose and an augmented Backus-Naur form (BNF) [H2.1] described in 865 detail in RFC 2234 [21]. 867 Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP 868 transactions can be carried in a single TCP connection or UDP 869 datagram. UDP datagrams, including all headers, SHOULD NOT be larger 870 than the path maximum transmission unit (MTU) if the MTU is known, or 871 1400 bytes if the MTU is unknown. 873 The 1400 bytes accommodates lower-layer packet headers 874 within the "typical" MTU of around 1500 bytes. Recent 875 studies [22] indicate that an MTU of 1500 bytes is a 876 reasonable assumption. The next lower common MTU values are 877 1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191 879 [23]). Thus, another reasonable value would be a message 880 size of 950 bytes, to accommodate packet headers within the 881 SLIP MTU without fragmentation. 883 A SIP message is either a request from a client to a server, or a 884 response from a server to a client. 886 SIP-message ___ Request | Response 888 Both Request (section 4) and Response (section 5) messages use the 889 generic-message format of RFC 822 [24] for transferring entities (the 890 body of the message). Both types of messages consist of a start-line, 891 one or more header fields (also known as "headers"), an empty line 892 (i.e., a line with nothing preceding the carriage-return line-feed 893 (CRLF)) indicating the end of the header fields, and an optional 894 message-body. To avoid confusion with similar-named headers in HTTP, 895 we refer to the headers describing the message body as entity 896 headers. These components are described in detail in the upcoming 897 sections. 899 generic-message = start-line 900 *message-header 901 CRLF 902 [ message-body ] 904 start-line = Request-Line | Section 4.1 905 Status-Line Section 5.1 907 message-header = ( general-header 908 | request-header 909 | response-header 910 | entity-header ) 912 In the interest of robustness, any leading empty line(s) MUST be In 913 other words, if the Request or Response message begins with a CRLF, 914 CR, or LF, these characters MUST be ignored. 916 4 Request 917 general-header = Call-ID ; Section 6.12 918 | Contact ; Section 6.13 919 | CSeq ; Section 6.17 920 | Date ; Section 6.18 921 | Encryption ; Section 6.19 922 | Expires ; Section 6.20 923 | From ; Section 6.21 924 | Record-Route ; Section 6.29 925 | Timestamp ; Section 6.36 926 | To ; Section 6.37 927 | Via ; Section 6.40 928 entity-header = Content-Encoding ; Section 6.14 929 | Content-Length ; Section 6.15 930 | Content-Type ; Section 6.16 931 request-header = Accept ; Section 6.7 932 | Accept-Encoding ; Section 6.8 933 | Accept-Language ; Section 6.9 934 | Authorization ; Section 6.11 935 | Contact ; Section 6.13 936 | Hide ; Section 6.22 937 | Max-Forwards ; Section 6.23 938 | Organization ; Section 6.24 939 | Priority ; Section 6.25 940 | Proxy-Authorization ; Section 6.27 941 | Proxy-Require ; Section 6.28 942 | Route ; Section 6.33 943 | Require ; Section 6.30 944 | Response-Key ; Section 6.31 945 | Subject ; Section 6.35 946 | User-Agent ; Section 6.39 947 response-header = Allow ; Section 6.10 948 | Proxy-Authenticate ; Section 6.26 949 | Retry-After ; Section 6.32 950 | Server ; Section 6.34 951 | Unsupported ; Section 6.38 952 | Warning ; Section 6.41 953 | WWW-Authenticate ; Section 6.42 955 Table 3: SIP headers 957 The Request message format is shown below: 959 Request = Request-Line ; Section 4.1 960 *( general-header 961 | request-header 962 | entity-header ) 963 CRLF 964 [ message-body ] ; Section 8 966 4.1 Request-Line 968 The Request-Line begins with a method token, followed by the 969 Request-URI and the protocol version, and ending with CRLF. The 970 elements are separated by SP characters. No CR or LF are allowed 971 except in the final CRLF sequence. 973 Request-Line = Method SP Request-URI SP SIP-Version CRLF 975 4.2 Methods 977 The methods are defined below. Methods that are not supported by a 978 proxy or redirect server are treated by that server as if they were 979 an OPTIONS method and forwarded accordingly. Methods that are not 980 supported by a user agent server or registrar cause a 501 (Not 981 Implemented) response to be returned (Section 7). 983 Method = "ACK" | "BYE" | "CANCEL" | "INVITE" 984 | "OPTIONS" | "REGISTER" 986 4.2.1 INVITE 988 The INVITE method indicates that the user or service is being invited 989 to participate in a session. The message body contains a description 990 of the session to which the callee is being invited. For two-party 991 calls, the caller indicates the type of media it is able to receive 992 as well as their parameters such as network destination. A success 993 response indicates in its message body which media the callee wishes 994 to receive. 996 A server MAY automatically respond to an invitation for a conference 997 the user is already participating in, identified either by the SIP 998 Call-ID or a globally unique identifier within the session 999 description, with a 200 (OK) response. 1001 If a user agent receives an INVITE request for an existing Call-ID 1002 with a higher CSeq sequence number than any previous INVITE for the 1003 same Call-ID, it MUST check any version identifiers in the session 1004 description or, if there are no version identifiers, the content of 1005 the session description to see if it has changed. It MUST also 1006 inspect any other header fields for changes and act accordingly. If 1007 the session description has changed, the user agent server MUST 1008 adjust the session parameters accordingly, possibly after asking the 1009 user for confirmation. (Versioning of the session description can be 1010 used to accommodate the capabilities of new arrivals to a conference, 1011 add or delete media or change from a unicast to a multicast 1012 conference.) 1014 This method MUST be supported by SIP proxy, redirect and user agent 1015 servers as well as clients. 1017 4.2.2 ACK 1019 The ACK request confirms that the client has received a final 1020 response to an INVITE request. (ACK is used only with INVITE 1021 requests.) 2xx responses are acknowledged by client user agents, all 1022 other final responses by the first proxy or client user agent to 1023 receive the response. The Via is always initialized to the host that 1024 originates the ACK request, i.e., the client user agent after a 2xx 1025 response or the first proxy to receive a non-2xx final response. The 1026 ACK request is forwarded as the corresponding INVITE request, based 1027 on its Request-URI. See Section 10 for details. 1029 The ACK request MAY contain a message body with the final session 1030 description to be used by the callee. If the ACK message body is 1031 empty, the callee uses the session description in the INVITE request. 1033 A proxy server receiving an ACK request after having sent a 3xx, 4xx, 1034 5xx, or 6xx response must make a determination about whether the ACK 1035 is for it, or for some user agent or proxy server further downstream. 1036 This determination is made by examining the tag in the To field. If 1037 the tag in the ACK To header field matches the tag in the To header 1038 field of the response, the ACK is meant for the proxy server. 1039 Otherwise, the ACK SHOULD be proxied downstream as any other request. 1041 It is possible for a user agent client or proxy server to 1042 receive multiple 3xx, 4xx, 5xx, and 6xx responses to a 1043 request along a single branch. This can happen under 1044 various error conditions, typically when a forking proxy 1045 transitions from stateful to stateless before receiving all 1046 responses. The various responses will all be identical, 1047 except for the tag in the To field, which is different for 1048 each one. It can therefore be used as a means to 1049 disambiguate them. 1051 This method MUST be supported by SIP proxy, redirect and user agent 1052 servers as well as clients. 1054 4.2.3 OPTIONS 1056 The server is being queried as to its capabilities. A server that 1057 believes it can contact the user, such as a user agent where the user 1058 is logged in and has been recently active, MAY respond to this 1059 request with a capability set. A called user agent MAY return a 1060 status reflecting how it would have responded to an invitation, e.g., 1061 600 (Busy). Such a server SHOULD return an Allow header field 1062 indicating the methods that it supports. Proxy and redirect servers 1063 simply forward the request without indicating their capabilities. 1065 This method MUST be supported by SIP proxy, redirect and user agent 1066 servers, registrars and clients. 1068 4.2.4 BYE 1070 The user agent client uses BYE to indicate to the server that it 1071 wishes to release the call. A BYE request is forwarded like an INVITE 1072 request and MAY be issued by either caller or callee. A party to a 1073 call SHOULD issue a BYE request before releasing a call ("hanging 1074 up"). A party receiving a BYE request MUST cease transmitting media 1075 streams specifically directed at the party issuing the BYE request. 1077 If the INVITE request contained a Contact header, the callee MAY send 1078 a BYE request to that address rather than the From address. 1080 This method MUST be supported by proxy servers and SHOULD be 1081 supported by redirect and user agent SIP servers. 1083 4.2.5 CANCEL 1085 The CANCEL request cancels a pending request with the same Call-ID, 1086 To, From and CSeq (sequence number only) header field values, but 1087 does not affect a completed request. (A request is considered 1088 completed if the server has returned a final status response.) 1090 A user agent client or proxy client MAY issue a CANCEL request at any 1091 time. A proxy, in particular, MAY choose to send a CANCEL to 1092 destinations that have not yet returned a final response after it has 1093 received a 2xx or 6xx response for one or more of the parallel-search 1094 requests. A proxy that receives a CANCEL request forwards the request 1095 to all destinations with pending requests. 1097 The Call-ID, To, the numeric part of CSeq and From headers in the 1098 CANCEL request are identical to those in the original request. This 1099 allows a CANCEL request to be matched with the request it cancels. 1100 However, to allow the client to distinguish responses to the CANCEL 1101 from those to the original request, the CSeq Method component is set 1102 to CANCEL. The Via header field is initialized to the proxy issuing 1103 the CANCEL request. (Thus, responses to this CANCEL request only 1104 reach the issuing proxy.) 1106 Once a user agent server has received a CANCEL, it MUST NOT issue a 1107 2xx response for the cancelled original request. 1109 A redirect or user agent server receiving a CANCEL request responds 1110 with a status of 200 (OK) if the transaction exists and a status of 1111 481 (Transaction Does Not Exist) if not, but takes no further action. 1112 In particular, any existing call is unaffected. 1114 The BYE request cannot be used to cancel branches of a 1115 parallel search, since several branches may, through 1116 intermediate proxies, find the same user agent server and 1117 then terminate the call. To terminate a call instead of 1118 just pending searches, the UAC must use BYE instead of or 1119 in addition to CANCEL. While CANCEL can terminate any 1120 pending request other than ACK or CANCEL, it is typically 1121 useful only for INVITE. 200 responses to INVITE and 200 1122 responses to CANCEL are distinguished by the method in the 1123 Cseq header field, so there is no ambiguity. 1125 This method MUST be supported by proxy servers and SHOULD be 1126 supported by all other SIP server types. 1128 4.2.6 REGISTER 1130 A client uses the REGISTER method to register the address listed in 1131 the To header field with a SIP server. 1133 A user agent MAY register with a local server on startup by sending a 1134 REGISTER request to the well-known "all SIP servers" multicast 1135 address "sip.mcast.net" (224.0.1.75), with a time-to-live value of 1. 1136 SIP user agents on the same subnet MAY listen to that address and use 1137 it to become aware of the location of other local users [17]; 1138 however, they do not respond to the request. A user agent MAY also 1139 be configured with the address of a registrar server to which it 1140 sends a REGISTER request upon startup. 1142 The meaning of the REGISTER request-header fields is defined as 1143 follows. We define "address-of-record" as the SIP address that the 1144 registry knows the registrand, typically of the form "user@domain" 1145 rather than "user@host". In third-party registration, the entity 1146 issuing the request is different from the entity being registered. 1148 To: The To header field contains the address-of-record whose 1149 registration is to be created or updated. 1151 From: The From header field contains the address-of-record of the 1152 person responsible for the registration. For first-party 1153 registration, it is identical to the To header field value. 1155 Request-URI: The Request-URI names the destination of the 1156 registration request, i.e., the domain of the registrar. The 1157 user name MUST be empty. Generally, the domains in the Request- 1158 URI and the To header field have the same value; however, it is 1159 possible to register as a "visitor", while maintaining one's 1160 name. For example, a traveller sip:alice@acme.com (To) might 1161 register under the Request-URI sip:@atlanta.ayh.org , with the 1162 former as the To header field and the latter as the Request-URI. 1163 The request is no longer forwarded once it reached the server 1164 whose authoritative domain is the one listed in the Request-URI. 1166 Contact: The request MAY contain a Contact header field; future non- 1167 REGISTER requests for the URI given in the To header field will 1168 be directed to the address(es) given in the Contact header. 1170 If the request does not contain a Contact header, the registration 1171 remains unchanged. Registrations using SIP URIs that differ in one or 1172 more of host, port, transport-param or maddr-param from an existing 1173 registration are added to the list of registrations. Other URI types 1174 are compared according to the standard URI equivalency rules for the 1175 URI schema. If the URIs are equivalent to that of an existing 1176 registration, the new registration replaces the old one if it has a 1177 higher q value or, for the same value of q, if the ttl value is 1178 higher. All current registrations MUST share the same action value. 1179 Registrations that have a different action than current registrations 1180 for the same user are rejected with status of 409 (Conflict). 1182 A proxy server ignores the q parameter when processing non-REGISTER 1183 requests, while a redirect server simply returns that parameter in 1184 its Contact response header field. 1186 Having the proxy server interpret the q parameter is not 1187 sufficient to guide proxy behavior, as it is not clear, for 1188 example, how long it is supposed to wait between trying 1189 addresses. 1191 If the registration is changed while a user agent or proxy server 1192 processes an invitation, the new information SHOULD be used. 1194 This allows a service known as "directed pick-up". 1196 A server SHOULD silently drop the registration after one hour, unless 1197 refreshed by the client. A client MAY request a lower or higher 1198 refresh interval through the Expires header (Section 6.20). Based on 1199 this request and its configuration, the server chooses the expiration 1200 interval and indicates it through the Expires header field in the 1201 response. A single address (if host-independent) MAY be registered 1202 from several different clients. 1204 A client cancels an existing registration by sending a REGISTER 1205 request with an expiration time (Expires) of zero seconds for a 1206 particular Contact or the wildcard Contact designated by a "*" for 1207 all registrations. Registrations are matched based on the user, host, 1208 port and maddr parameters. 1210 The server SHOULD return the current list of registrations in the 200 1211 response as Contact header fields. 1213 It is particularly important that REGISTER requests are authenticated 1214 since they allow to redirect future requests. 1216 Beyond its use as a simple location service, this method is 1217 needed if there are several SIP servers on a single host. 1218 In that case, only one of the servers can use the default 1219 port number. Each server that cannot registers with a 1220 server for the administrative domain. Since clients do not 1221 always have easy access to the host address or port number, 1222 using the source address and port from the request itself 1223 seems simpler. 1225 Support of this method is RECOMMENDED. 1227 4.3 Request-URI 1229 The Request-URI is a SIP URL as described in Section 2 or a general 1230 URI. It indicates the user or service to which this request is being 1231 addressed. Unlike the To field, the Request-URI MAY be re-written by 1232 proxies. 1234 When used as a Request-URI, a SIP-URL MUST NOT contain the 1235 transport-param, maddr-param, ttl-param, or headers elements. A 1236 server that receives a SIP-URL with these elements removes them 1237 before further processing. 1239 Typically, the UAC sets the Request-URI and To to the same 1240 SIP URL, presumed to remain unchanged over long time 1241 periods. However, if the UAC has cached a more direct path 1242 to the callee, e.g., from the Contact header field of a 1243 response to a previous request, the To would still contain 1244 the long-term, "public" address, while the Request-URI 1245 would be set to the cached address. 1247 Proxy and redirect servers MAY use the information in the Request-URI 1248 and request header fields to handle the request and possibly rewrite 1249 the Request-URI. For example, a request addressed to the generic 1250 address sip:sales@acme.com is proxied to the particular person, e.g., 1251 sip:bob@ny.acme.com , with the To remaining as sales@acme.com 1252 ny.acme.com , Bob then designates Alice as the temporary substitute. 1254 The host part of the Request-URI typically agrees with one of the 1255 host names of the server. If it does not, the server SHOULD proxy the 1256 request to the address indicated or return a 404 (Not Found) response 1257 if it is unwilling or unable to do so. For example, the Request-URI 1258 and server host name can disagree in the case of a firewall proxy 1259 that handles outgoing calls. This mode of operation similar to that 1260 of HTTP proxies. 1262 If a SIP server receives a request with a URI indicating a scheme 1263 other than SIP which that server does not understand, the server MUST 1264 return a 400 (Bad Request) response. It MUST do this even if the To 1265 header field contains a scheme it does understand. 1267 4.3.1 SIP Version 1269 Both request and response messages include the version of SIP in use, 1270 and basically follow [H3.1], with HTTP replaced by SIP. To be 1271 conditionally compliant with this specification, applications sending 1272 SIP messages MUST include a SIP-Version of "SIP/2.0". 1274 4.4 Option Tags 1276 Option tags are unique identifiers used to designate new options in 1277 SIP. These tags are used in Require (Section 6.30) and Unsupported 1278 (Section 6.38) fields. 1280 Syntax: 1282 option-tag ___ 1*uric 1284 The creator of a new SIP option MUST either prefix the option with a 1285 reverse domain name or register the new option with the Internet 1286 Assigned Numbers Authority (IANA). For example, 1287 "com.foo.mynewfeature" is an apt name for a feature whose inventor 1288 can be reached at "foo.com". Options registered with IANA have the 1289 prefix "org.ietf.sip.", options described in RFCs have the prefix 1290 "org.ietf.rfc.N", where N is the RFC number. Option tags are case- 1291 insensitive. 1293 4.4.1 Registering New Option Tags with IANA 1295 When registering a new SIP option, the following information MUST be 1296 provided: 1298 o Name and description of option. The name MAY be of any length, 1299 but SHOULD be no more than twenty characters long. The name 1300 MUST NOT contain any spaces, control characters or periods. 1302 o Indication of who has change control over the option (for 1303 example, IETF, ISO, ITU-T, other international standardization 1304 bodies, a consortium or a particular company or group of 1305 companies); 1307 o A reference to a further description, if available, for 1308 example (in order of preference) an RFC, a published paper, a 1309 patent filing, a technical report, documented source code or a 1310 computer manual; 1312 o For proprietary options, contact information (postal and email 1313 address); 1315 Borrowed from RTSP and the RTP AVP. 1317 5 Response 1319 After receiving and interpreting a request message, the recipient 1320 responds with a SIP response message. The response message format is 1321 shown below: 1323 Response = Status-Line ; Section 5.1 1324 *( general-header 1325 | response-header 1326 | entity-header ) 1327 CRLF 1328 [ message-body ] ; Section 8 1330 [H6] applies except that HTTP-Version is replaced by SIP-Version. 1331 Also, SIP defines additional response codes and does not use some 1332 HTTP codes. 1334 5.1 Status-Line 1336 The first line of a Response message is the Status-Line, consisting 1337 of the protocol version (Section 4.3.1) followed by a numeric 1338 Status-Code and its associated textual phrase, with each element 1339 separated by SP characters. No CR or LF is allowed except in the 1340 final CRLF sequence. 1342 Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF 1344 5.1.1 Status Codes and Reason Phrases 1346 The Status-Code is a 3-digit integer result code that indicates the 1347 outcome of the attempt to understand and satisfy the request. The 1348 Reason-Phrase is intended to give a short textual description of the 1349 Status-Code. The Status-Code is intended for use by automata, whereas 1350 the Reason-Phrase is intended for the human user. The client is not 1351 required to examine or display the Reason-Phrase. 1353 Status-Code = Informational Fig. 5 1354 | Success Fig. 5 1355 | Redirection Fig. 6 1356 | Client-Error Fig. 7 1357 | Server-Error Fig. 8 1358 | Global-Failure Fig. 9 1359 | extension-code 1360 extension-code = 3DIGIT 1361 Reason-Phrase = * 1363 We provide an overview of the Status-Code below, and provide full 1364 definitions in Section 7. The first digit of the Status-Code defines 1365 the class of response. The last two digits do not have any 1366 categorization role. SIP/2.0 allows 6 values for the first digit: 1368 1xx: Informational -- request received, continuing to process the 1369 request; 1371 2xx: Success -- the action was successfully received, understood, and 1372 accepted; 1374 3xx: Redirection -- further action needs to be taken in order to 1375 complete the request; 1377 4xx: Client Error -- the request contains bad syntax or cannot be 1378 fulfilled at this server; 1380 5xx: Server Error -- the server failed to fulfill an apparently valid 1381 request; 1383 6xx: Global Failure -- the request is invalid at any server. 1385 Figures 5 through 9 present the individual values of the numeric 1386 response codes, and an example set of corresponding reason phrases 1387 for SIP/2.0. These reason phrases are only recommended; they may be 1388 replaced by local equivalents without affecting the protocol. Note 1389 that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response 1390 codes in the range starting at x80 to avoid conflicts with newly 1391 defined HTTP response codes, and adds a new class, 6xx, of response 1392 codes. 1394 SIP response codes are extensible. SIP applications are not required 1395 to understand the meaning of all registered response codes, though 1396 such understanding is obviously desirable. However, applications MUST 1397 understand the class of any response code, as indicated by the first 1398 digit, and treat any unrecognized response as being equivalent to the 1399 x00 response code of that class, with the exception that an 1400 unrecognized response MUST NOT be cached. For example, if a client 1401 receives an unrecognized response code of 431, it can safely assume 1402 that there was something wrong with its request and treat the 1403 response as if it had received a 400 (Bad Request) response code. In 1404 such cases, user agents SHOULD present to the user the message body 1405 returned with the response, since that message body is likely to 1406 include human-readable information which will explain the unusual 1407 status. 1409 6 Header Field Definitions 1411 SIP header fields are similar to HTTP header fields in both syntax 1412 and semantics [H4.2, H14]. In general, the ordering of the header 1413 fields is not of importance (with the exception of Via fields, see 1414 below). The only requirement is that header fields which are hop-by- 1415 Informational = "100" ; Trying 1416 | "180" ; Ringing 1417 | "181" ; Call Is Being Forwarded 1418 | "182" ; Queued 1419 Success = "200" ; OK 1421 Figure 5: Informational and success status codes 1423 Redirection = "300" ; Multiple Choices 1424 | "301" ; Moved Permanently 1425 | "302" ; Moved Temporarily 1426 | "303" ; See Other 1427 | "305" ; Use Proxy 1428 | "380" ; Alternative Service 1430 Figure 6: Redirection status codes 1432 hop MUST appear before any header fields which are end-to-end. 1433 Proxies MUST NOT reorder or otherwise modify header fields other than 1434 by adding a new Via or other hop-by-hop field. Proxies MUST NOT, for 1435 example, change how header fields are broken across lines. This 1436 allows an authentication field to be added after the Via header 1437 fields that will not be invalidated by proxies. 1439 The header fields required, optional and not applicable for each 1440 method are listed in Table 4 and Table 5. The table uses "o" to 1441 indicate optional, "m" mandatory and "-" for not applicable. A "*" 1442 indicates that the header fields are needed only if message body is 1443 not empty: The Content-Type and Content-Length header fields are 1444 required when there is a valid message body (of non-zero length) 1445 associated with the message (Section 8). 1447 The "where" column describes the request and response types with 1448 which the header field can be used. "R" refers to header fields that 1449 can be used in requests (that is, request and general header fields). 1450 "r" designates a response or general-header field as applicable to 1451 all responses, while a list of numeric values indicates the status 1452 codes with which the header field can be used. "g" and "e" designate 1453 general (Section 6.1) and entity header (Section 6.2) fields, 1454 respectively. If a header field is marked "c", it is copied from the 1455 Client-Error = "400" ; Bad Request 1456 | "401" ; Unauthorized 1457 | "402" ; Payment Required 1458 | "403" ; Forbidden 1459 | "404" ; Not Found 1460 | "405" ; Method Not Allowed 1461 | "406" ; Not Acceptable 1462 | "407" ; Proxy Authentication Required 1463 | "408" ; Request Timeout 1464 | "409" ; Conflict 1465 | "410" ; Gone 1466 | "411" ; Length Required 1467 | "413" ; Request Message Body Too Large 1468 | "414" ; Request-URI Too Large 1469 | "415" ; Unsupported Media Type 1470 | "420" ; Bad Extension 1471 | "480" ; Temporarily not available 1472 | "481" ; Call Leg/Transaction Does Not Exist 1473 | "482" ; Loop Detected 1474 | "483" ; Too Many Hops 1475 | "484" ; Address Incomplete 1476 | "485" ; Ambiguous 1477 | "486" ; Busy Here 1479 Figure 7: Client error status codes 1481 Server-Error = "500" ; Internal Server Error 1482 | "501" ; Not Implemented 1483 | "502" ; Bad Gateway 1484 | "503" ; Service Unavailable 1485 | "504" ; Gateway Timeout 1486 | "505" ; SIP Version not supported 1488 Figure 8: Server error status codes 1490 request to the response. 1492 The "enc." column describes whether this message header field MAY be 1493 encrypted end-to-end. A "n" designates fields that MUST NOT be 1494 encrypted, while "c" designates fields that SHOULD be encrypted if 1495 Global-Failure | "600" ; Busy Everywhere 1496 | "603" ; Decline 1497 | "604" ; Does not exist anywhere 1498 | "606" ; Not Acceptable 1500 Figure 9: Global failure status codes 1502 encryption is used. 1504 The "e-e" column has a value of "e" for end-to-end and a value of "h" 1505 for hop-by-hop header fields. 1507 where enc. e-e ACK BYE CAN INV OPT REG 1508 ____________________________________________________________________________ 1509 Accept R e - - - o o o 1510 Accept-Encoding R e - - - o o o 1511 Accept-Language R n e - o o o o o 1512 Allow 200 e - - - - m - 1513 Allow 405 e o o o o o o 1514 Authorization R e o o o o o o 1515 Call-ID gc n e m m m m m m 1516 Contact R e o - - o o o 1517 Contact 1xx e - - - o o - 1518 Contact 2xx e - - - o o o 1519 Contact 3xx e - o - o o o 1520 Contact 485 e - o - o o o 1521 Content-Encoding e e * - - * * * 1522 Content-Length e e o - - o o o 1523 Content-Type e e * - - * * * 1524 CSeq gc n e m m m m m m 1525 Date g e o o o o o o 1526 Encryption g n e o o o o o o 1527 Expires g e - - - o - o 1528 From gc n e m m m m m m 1529 Hide R n h o o o o o o 1530 Max-Forwards R n e o o o o o o 1531 Organization g c h - - - o o o 1533 Table 4: Summary of header fields, A--O 1534 where enc. e-e ACK BYE CAN INV OPT REG 1535 _____________________________________________________________________________________ 1536 Proxy-Authenticate 407 n h o o o o o o 1537 Proxy-Authorization R n h o o o o o o 1538 Proxy-Require R n h o o o o o o 1539 Priority R c e - - - o - - 1540 Require R e o o o o o o 1541 Retry-After R c e - - - - - o 1542 Retry-After 404,480,486 c e o o o o o o 1543 503 c e o o o o o o 1544 600,603 c e o o o o o o 1545 Response-Key R c e - o o o o o 1546 Record-Route R h o o o o o o 1547 Record-Route 2xx h o o o o o o 1548 Route R h - o o o o o 1549 Server r c e o o o o o o 1550 Subject R c e - - - o - - 1551 Timestamp g e o o o o o o 1552 To gc(1) n e m m m m m m 1553 Unsupported 420 e o o o o o o 1554 User-Agent g c e o o o o o o 1555 Via gc(2) n e m m m m m m 1556 Warning r e o o o o o o 1557 WWW-Authenticate 401 c e o o o o o o 1559 Table 5: Summary of header fields, P--Z; (1): copied with possible 1560 addition of tag; (2): UAS removes first Via header field 1562 Other header fields can be added as required; a server MAY ignore 1563 optional header fields that it does not understand. A compact form of 1564 these header fields is also defined in Section 9 for use over UDP 1565 when the request has to fit into a single packet and size is an 1566 issue. 1568 Table 6 in Appendix A lists those header fields that different client 1569 and server types MUST be able to parse. 1571 6.1 General Header Fields 1573 General header fields apply to both request and response messages. 1574 The general-header field names can be extended reliably only in 1575 combination with a change in the protocol version. However, new or 1576 experimental header fields may be given the semantics of general 1577 header fields if all parties in the communication recognize them to 1578 be general-header fields. Unrecognized header fields are treated as 1579 entity-header fields. 1581 6.2 Entity Header Fields 1583 The entity-header fields define meta-information about the message- 1584 body or, if no body is present, about the resource identified by the 1585 request. The term "entity header" is an HTTP 1.1 term where the 1586 response body can contain a transformed version of the message body. 1587 The original message body is referred to as the "entity". We retain 1588 the same terminology for header fields but usually refer to the 1589 "message body" rather then the entity as the two are the same in SIP. 1591 6.3 Request Header Fields 1593 The request-header fields allow the client to pass additional 1594 information about the request, and about the client itself, to the 1595 server. These fields act as request modifiers, with semantics 1596 equivalent to the parameters of a programming language method 1597 invocation. 1599 The request-header field names can be extended reliably only in 1600 combination with a change in the protocol version. However, new or 1601 experimental header fields MAY be given the semantics of request- 1602 header fields if all parties in the communication recognize them to 1603 be request-header fields. Unrecognized header fields are treated as 1604 entity-header fields. 1606 6.4 Response Header Fields 1608 The response-header fields allow the server to pass additional 1609 information about the response which cannot be placed in the Status- 1610 Line. These header fields give information about the server and about 1611 further access to the resource identified by the Request-URI. 1613 Response-header field names can be extended reliably only in 1614 combination with a change in the protocol version. However, new or 1615 experimental header fields MAY be given the semantics of response- 1616 header fields if all parties in the communication recognize them to 1617 be response-header fields. Unrecognized header fields are treated as 1618 entity-header fields. 1620 6.5 End-to-end and Hop-by-hop Headers 1622 End-to-end headers MUST be transmitted unmodified across all proxies, 1623 while hop-by-hop headers MAY be modified or added by proxies. 1625 6.6 Header Field Format 1627 Header fields (general-header, request-header, response-header, and 1628 entity-header) follow the same generic header format as that given in 1629 Section 3.1 of RFC 822 [24]. Each header field consists of a name 1630 followed by a colon (":") and the field value. Field names are case- 1631 insensitive. The field value MAY be preceded by any amount of leading 1632 white space (LWS), though a single space (SP) is preferred. Header 1633 fields can be extended over multiple lines by preceding each extra 1634 line with at least one SP or horizontal tab (HT). Applications SHOULD 1635 follow HTTP "common form" when generating these constructs, since 1636 there might exist some implementations that fail to accept anything 1637 beyond the common forms. 1639 message-header = field-name ":" [ field-value ] CRLF 1640 field-name = token 1641 field-value = *( field-content | LWS ) 1642 field-content = < the OCTETs making up the field-value 1643 and consisting of either *TEXT 1644 or combinations of token, 1645 tspecials, and quoted-string> 1647 The relative order of header fields with different field names is not 1648 significant. Multiple header fields with the same field-name may be 1649 present in a message if and only if the entire field-value for that 1650 header field is defined as a comma-separated list (i.e., #(values)). 1651 It MUST be possible to combine the multiple header fields into one 1652 "field-name: field-value" pair, without changing the semantics of the 1653 message, by appending each subsequent field-value to the first, each 1654 separated by a comma. The order in which header fields with the same 1655 field-name are received is therefore significant to the 1656 interpretation of the combined field value, and thus a proxy MUST NOT 1657 change the order of these field values when a message is forwarded. 1659 Field names are not case-sensitive, although their values may be. 1661 6.7 Accept 1663 See [H14.1] for syntax. This request-header field is used only with 1664 the INVITE, OPTIONS and REGISTER request methods to indicate what 1665 media types are acceptable in the response. 1667 Example: 1669 Accept: application/sdp;level=1, application/x-private, text/html 1671 6.8 Accept-Encoding 1673 The Accept-Encoding request-header field is similar to Accept, but 1674 restricts the content-codings [H3.4.1] that are acceptable in the 1675 response. See [H14.3]. 1677 6.9 Accept-Language 1679 See [H14.4] for syntax. The Accept-Language request-header field can 1680 be used to allow the client to indicate to the server in which 1681 language it would prefer to receive reason phrases, session 1682 descriptions or status responses carried as message bodies. A proxy 1683 MAY use this field to help select the destination for the call, for 1684 example, a human operator conversant in a language spoken by the 1685 caller. 1687 Example: 1689 Accept-Language: da, en-gb;q=0.8, en;q=0.7 1691 6.10 Allow 1693 See [H14.7]. The Allow entity-header field lists the set of methods 1694 supported by the resource identified by the Request-URI. The purpose 1695 of this field is strictly to inform the recipient of valid methods 1696 associated with the resource. An Allow header field MUST be present 1697 in a 405 (Method Not Allowed) response and SHOULD be present in an 1698 OPTIONS response. 1700 6.11 Authorization 1702 See [H14.8]. 1704 A user agent that wishes to authenticate itself with a server -- 1705 usually, but not necessarily, after receiving a 401 response -- MAY 1706 do so by including an Authorization request-header field with the 1707 request. The Authorization field value consists of credentials 1708 containing the authentication information of the user agent for the 1709 realm of the resource being requested. 1711 6.12 Call-ID 1713 The Call-ID general-header field uniquely identifies a particular 1714 invitation or all registrations of a particular client. Note that a 1715 single multimedia conference can give rise to several calls with 1716 different Call-IDs, e.g., if a user invites a single individual 1717 several times to the same (long-running) conference. 1719 For an INVITE request, a callee user agent server SHOULD NOT alert 1720 the user if the user has responded previously to the Call-ID in the 1721 INVITE request. If the user is already a member of the conference and 1722 the conference parameters contained in the session description have 1723 not changed, a callee user agent server MAY silently accept the call, 1724 regardless of the Call-ID. An invitation for an existing Call-ID or 1725 session can change the parameters of the conference. A client 1726 application MAY decide to simply indicate to the user that the 1727 conference parameters have been changed and accept the invitation 1728 automatically or it MAY require user confirmation. 1730 A user may be invited to the same conference or call using several 1731 different Call-IDs. If desired, the client MAY use identifiers within 1732 the session description to detect this duplication. For example, SDP 1733 contains a session id and version number in the origin (o) field. 1735 The REGISTER and OPTIONS methods use the Call-ID value to 1736 unambiguously match requests and responses. All REGISTER requests 1737 issued by a single client MUST use the same Call-ID. 1739 Since the Call-ID is generated by and for SIP, there is no 1740 reason to deal with the complexity of URL-encoding and 1741 case-ignoring string comparison. 1743 Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host 1744 local-id = *uric 1746 host MUST be either a fully qualified domain name or a globally 1747 routable IP address, while the local-id is a random identifier 1748 consisting of URI characters that is unique within host. It MUST NOT 1749 be reused for a different call. Call-IDs are case-sensitive. The use 1750 of a UUID as local-id is OPTIONAL. The UUID is a version-4 (random) 1751 UUID [19]. 1753 Using cryptographically random identifiers provides some 1754 protection against session hijacking. Call-ID, To and From 1755 are needed to identify a call leg call leg matters in calls 1756 with third-party control. 1758 Example: 1760 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 1762 6.13 Contact 1764 The Contact general-header field can appear in requests, 1xx, 2xx 1765 responses and 3xx responses. 1767 INVITE and ACK requests: INVITE and ACK requests MAY contain Contact 1768 headers indicating from which location the request is 1769 originating. 1771 This allows the callee to send a BYE directly to the caller 1772 instead of through a series of proxies. The Via header is 1773 not sufficient since the desired address may be that of a 1774 proxy. 1776 INVITE 2xx responses: A user agent server sending a definitive, 1777 positive response (2xx) MAY insert a Contact response header 1778 field indicating the SIP address under which it is reachable 1779 most directly for future SIP requests, such as ACK, within the 1780 same Call-ID. The Contact header field contains the address of 1781 the server itself or that of a proxy, e.g., if the host is 1782 behind a firewall. The value of this Contact header is copied 1783 into the Request-URI of subsequent requests for this call. 1785 The Contact value SHOULD NOT be cached across calls, as it 1786 may not represent the most desirable location for a 1787 particular destination address. 1789 INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY 1790 insert a Contact response header. It has the same semantics in a 1791 1xx response as a 2xx INVITE response. Note that CANCEL 1792 requests MUST NOT be sent to that address, but rather follow the 1793 same path as the original request. 1795 REGISTER requests: REGISTER requests MAY contain a Contact header 1796 field indicating at which locations the user is reachable. The 1797 REGISTER request defines a wildcard Contact field, "*", which 1798 MUST only be used with Expires: 0 to remove all registrations 1799 for a particular user. An optional expires parameter indicates 1800 the desired expiration time of the registration. If a Contact 1801 entry does not have an expires parameter, the Expires header 1802 field is used as the default value. If neither of these 1803 mechanisms is used, SIP URIs are assumed to expire after one 1804 hour. Other URI schemes have no expiration times. 1806 REGISTER 2xx responses: A REGISTER response MAY return all locations 1807 at which the user is currently reachable. An optional expires 1808 parameter indicates the expiration time of the registration. If 1809 a Contact entry does not have an expires parameter, the value of 1810 the Expires header field indicates the expiration time. If 1811 neither mechanism is used, the expiration time specified in the 1812 request, explicitly or by default, is used. 1814 3xx and 485 responses: The Contact response-header field can be used 1815 with a 3xx or 485 (Ambiguous) response codes to indicate one or 1816 more alternate addresses to try. It can appear in responses to 1817 BYE, INVITE and OPTIONS methods. The Contact header field 1818 contains URIs giving the new locations or user names to try, or 1819 may simply specify additional transport parameters. A 300 1820 (Multiple Choices), 301 (Moved Permanently), 302 (Moved 1821 Temporarily) or 485 (Ambiguous) response SHOULD contain a 1822 Contact field containing URIs of new addresses to be tried. A 1823 301 or 302 response may also give the same location and username 1824 that was being tried but specify additional transport parameters 1825 such as a different server or multicast address to try or a 1826 change of SIP transport from UDP to TCP or vice versa. The 1827 client copies the user, password, host, port and user-param 1828 elements of the Contact URI into the Request-URI of the 1829 redirected request and directs the request to the address 1830 specified by the maddr and port parameters, using the transport 1831 protocol given in the transport parameter. If maddr is a 1832 multicast address, the value of ttl is used as the time-to-live 1833 value. 1835 Note that the Contact header field MAY also refer to a different 1836 entity than the one originally called. For example, a SIP call 1837 connected to GSTN gateway may need to deliver a special information 1838 announcement such as "The number you have dialed has been changed." 1840 A Contact response header field can contain any suitable URI 1841 indicating where the called party can be reached, not limited to SIP 1842 URLs. For example, it can contain a phone or fax, 1844 mailto: (RFC 2368, [25]) or irc: URL. 1846 The following parameters are defined. Additional parameters may be 1847 defined in other specifications. 1849 q: The qvalue indicates the relative preference among the locations 1850 given. qvalue values are decimal numbers from 0.0 to 1.0, with 1851 higher values indicating higher preference. 1853 action: The action parameter is only used when registering with the 1854 REGISTER request. It indicates whether the client wishes that 1855 the server proxy or redirect future requests intended for the 1856 client. If this parameter is not specified the action taken 1857 depends on server configuration. In its response, the registrar 1858 SHOULD indicate the mode used. This parameter is ignored for 1859 other requests. 1861 expires: The expires parameter indicates how long the URI is valid. 1862 The parameter is either a number indicating seconds or a quoted 1863 string containing an HTTP-date. If this parameter is not 1864 provided, the value of the Expires header field determines how 1865 long the URI is valid. 1867 Contact = ( "Contact" | "m" ) ":" ("*" | (1# ( address-spec 1868 [ *( ";" contact-params ) ] [ comment ] )) 1870 contact-params = "q" "=" qvalue 1871 | "action" "=" "proxy" | "redirect" 1872 | "expires" "=" delta-seconds | <"> HTTP-date <"> 1873 | extension-attribute 1875 extension-attribute = extension-name [ "=" & extension-value ] 1877 The Contact header field fulfills functionality similar to 1878 the Location header field in HTTP. However, the HTTP header 1879 only allows one address, unquoted. Since URIs can contain 1880 commas and semicolons as reserved characters, they can be 1881 mistaken for header or parameter delimiters, respectively. 1882 The current syntax corresponds to that for the To and From 1883 header, which also allows the use of display names. 1885 Example: 1887 Contact: "Mr. Watson" 1888 ;q=0.7; expires=3600, 1889 "Mr. Watson" ;q=0.1 1891 6.14 Content-Encoding 1893 The Content-Encoding entity-header field is used as a modifier to the 1894 media-type. When present, its value indicates what additional content 1895 codings have been applied to the entity-body, and thus what decoding 1896 mechanisms MUST be applied in order to obtain the media-type 1897 referenced by the Content-Type header field. Content-Encoding is 1898 primarily used to allow a document to be compressed without losing 1899 the identity of its underlying media type. See [H14.12]. 1901 6.15 Content-Length 1903 The Content-Length entity-header field indicates the size of the 1904 message-body, in decimal number of octets, sent to the recipient. 1906 Content-Length = "Content-Length" ":" 1*DIGIT 1908 An example is 1910 Content-Length: 3495 1912 Applications SHOULD use this field to indicate the size of the 1913 message-body to be transferred, regardless of the media type of the 1914 entity. Any Content-Length greater than or equal to zero is a valid 1915 value. If no body is present in a message, then the Content-Length 1916 header field MUST be set to zero. If a server receives a UDP request 1917 without Content-Length, it MUST assume that the request encompasses 1918 the remainder of the packet. If a response does not contain a 1919 Content-Length, the client assumes that it encompasses the remainder 1920 of the UDP packet or the data until the TCP connection is closed, as 1921 applicable. Section 8 describes how to determine the length of the 1922 message body. 1924 6.16 Content-Type 1926 The Content-Type entity-header field indicates the media type of the 1927 message-body sent to the recipient. The media-type element is defined 1928 in [H3.7]. 1930 Content-Type = ( "Content-Type" ":" media-type 1932 Examples of this header field are 1934 Content-Type: application/sdp 1935 Content-Type: text/html; charset=ISO-8859-4 1937 6.17 CSeq 1939 Clients MUST add the CSeq (command sequence) general-header field to 1940 every request. A CSeq header field in a request contains the request 1941 method and a single decimal sequence number chosen by the requesting 1942 client, unique within a single value of Call-ID. The sequence number 1943 MUST be expressible as a 32-bit unsigned integer. The initial value 1944 of the sequence number is arbitrary, but MUST be less than 2**31. 1945 Consecutive requests that differ in request method, headers or body, 1946 but have the same Call-ID MUST contain strictly monotonically 1947 increasing and contiguous sequence numbers; sequence numbers do not 1948 wrap around. Retransmissions of the same request carry the same 1949 sequence number, but an INVITE with a different message body or 1950 different header fields (a "re-invitation") acquires a new, higher 1951 sequence number. A server MUST echo the CSeq value from the request 1952 in its response. If the Method value is missing, the server fills it 1953 in appropriately. 1955 The ACK and CANCEL requests MUST contain the same CSeq value as the 1956 INVITE request that it refers to, while a BYE request cancelling an 1957 invitation MUST have a higher sequence number. 1959 A user agent server MUST remember the highest sequence number for any 1960 INVITE request with the same Call-ID value. The server MUST respond 1961 to, but ignore any INVITE request with a lower sequence number. 1963 All requests spawned in a parallel search have the same CSeq value as 1964 the request triggering the parallel search. 1966 CSeq = "CSeq" ":" 1*DIGIT Method 1968 Strictly speaking, CSeq header fields are needed for any 1969 SIP request that can be cancelled by a BYE or CANCEL 1970 request or where a client can issue several requests for 1971 the same Call-ID in close succession. Without a sequence 1972 number, the response to an INVITE could be mistaken for the 1973 response to the cancellation (BYE or CANCEL). Also, if the 1974 network duplicates packets or if an ACK is delayed until 1975 the server has sent an additional response, the client 1976 could interpret an old response as the response to a re- 1977 invitation issued shortly thereafter. Using CSeq also makes 1978 it easy for the server to distinguish different versions of 1979 an invitation, without comparing the message body. 1981 The Method value allows the client to distinguish the response to an 1982 INVITE request from that of a CANCEL response. CANCEL requests can be 1983 generated by proxies; if they were to increase the sequence number, 1984 it might conflict with a later request issued by the user agent for 1985 the same call. 1987 With a length of 32 bits, a server could generate, within a single 1988 call, one request a second for about 136 years before needing to wrap 1989 around. The initial value of the sequence number is chosen so that 1990 subsequent requests within the same call will not wrap around. A 1991 non-zero initial value allows to use a time-based initial sequence 1992 number, which protects against ambiguities when clients are re- 1993 invited to the same call after rebooting. A client could, for 1994 example, choose the 31 most significant bits of a 32-bit second clock 1995 as an initial sequence number. 1997 Forked requests MUST have the same CSeq as there would be ambiguity 1998 otherwise between these forked requests and later BYE issued by the 1999 client user agent. 2001 Example: 2003 CSeq: 4711 INVITE 2005 6.18 Date 2007 General-header field. See [H14.19]. 2009 The Date header field reflects the time when the request or response 2010 is first sent. Thus, retransmissions have the same Date header field 2011 value as the original. 2013 The Date header field can be used by simple end systems 2014 without a battery-backed clock to acquire a notion of 2015 current time. 2017 6.19 Encryption 2019 The Encryption general-header field specifies that the content has 2020 been encrypted. Section 13 describes the overall SIP security 2021 architecture and algorithms. This header field is intended for end- 2022 to-end encryption of requests and responses. Requests are encrypted 2023 with a public key belonging to the entity named in the To header 2024 field. Responses are encrypted with the public key conveyed in the 2025 Response-Key header field. 2027 SIP chose not to adopt HTTP's Content-Transfer-Encoding 2028 header field because the encrypted body may contain 2029 additional SIP header fields as well as the body of the 2030 message. 2032 For any encrypted message, at least the message body and possibly 2033 other message header fields are encrypted. An application receiving a 2034 request or response containing an Encryption header field decrypts 2035 the body and then concatenates the plaintext to the request line and 2036 headers of the original message. Message headers in the decrypted 2037 part completely replace those with the same field name in the 2038 plaintext part. (Note: If only the body of the message is to be 2039 encrypted, the body has to be prefixed with CRLF to allow proper 2040 concatenation.) Note that the request method and Request-URI cannot 2041 be encrypted. 2043 Encryption only provides privacy; the recipient has no 2044 guarantee that the request or response came from the party 2045 listed in the From message header, only that the sender 2046 used the recipients public key. However, proxies will not 2047 be able to modify the request or response. 2049 Encryption = "Encryption" ":" encryption-scheme 1*SP 2050 #encryption-params 2051 encryption-scheme = token 2052 encryption-params = token "=" ( token | quoted-string ) 2054 The token indicates the form of encryption used; it is 2055 described in section 13. 2057 The following example for a message encrypted with ASCII-armored PGP 2058 was generated by applying "pgp -ea" to the payload to be encrypted. 2060 INVITE sip:watson@boston.bell-telephone.com SIP/2.0 2061 Via: SIP/2.0/UDP 169.130.12.5 2062 From: 2063 To: T. A. Watson 2064 Call-ID: 187602141351@worcester.bell-telephone.com 2065 Content-Length: 885 2066 Encryption: PGP version=2.6.2,encoding=ascii 2067 hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red 2068 h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs 2069 ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR 2070 RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA 2071 zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu 2072 X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 2073 IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ 2074 GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E 2075 WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed 2076 wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO 2077 z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+ 2078 6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2 2079 z8X9N4MhMyXEVuC9rt8/AUhmVQ== 2080 =bOW+ 2082 Since proxies can base their forwarding decision on any combination 2083 of SIP header fields, there is no guarantee that an encrypted request 2084 "hiding" header fields will reach the same destination as an 2085 otherwise identical un-encrypted request. 2087 6.20 Expires 2089 The Expires entity-header field gives the date and time after which 2090 the message content expires. 2092 This header field is currently defined only for the REGISTER and 2093 INVITE methods. For REGISTER, it is a request and response-header 2094 field. In a REGISTER request, the client indicates how long it wishes 2095 the registration to be valid. In the response, the server indicates 2096 the earliest expiration time of all registrations. The server MAY 2097 choose a shorter time interval than that requested by the client, but 2098 SHOULD NOT choose a longer one. 2100 For INVITE requests, it is a request and response-header field. In a 2101 request, the callee can limit the validity of an invitation, for 2102 example, if a client wants to limit the time duration of a search or 2103 a conference invitation. A user interface MAY take this as a hint to 2104 leave the invitation window on the screen even if the user is not 2105 currently at the workstation. This also limits the duration of a 2106 search. If the request expires before the search completes, the proxy 2107 returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily) 2108 response, a server can advise the client of the maximal duration of 2109 the redirection. 2111 The value of this field can be either an HTTP-date or an integer 2112 number of seconds (in decimal), measured from the receipt of the 2113 request. The latter approach is preferable for short durations, as it 2114 does not depend on clients and servers sharing a synchronized clock. 2116 Expires = "Expires" ":" ( HTTP-date | delta-seconds ) 2118 Two examples of its use are 2120 Expires: Thu, 01 Dec 1994 16:00:00 GMT 2121 Expires: 5 2123 6.21 From 2125 Requests and responses MUST contain a From general-header field, 2126 indicating the initiator of the request. The From field MAY contain 2127 the tag parameter. The server copies the From header field from the 2128 request to the response. The optional display-name is meant to be 2129 rendered by a human-user interface. 2131 The SIP-URL MUST NOT contain the transport-param, maddr-param, ttl- 2132 param, or headers elements. A server that receives a SIP-URL with 2133 these elements removes them before further processing. 2135 Even if the display-name is empty, the name-addr form MUST be used if 2136 the addr-spec contains a comma or semicolon. 2138 From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) 2139 *( ";" addr-params ) 2140 name-addr = [ display-name ] "<" addr-spec ">" 2141 addr-spec = SIP-URL | URI 2142 display-name = *token | quoted-string 2143 addr-params = tag-param 2144 tag-param = "tag=" UUID 2145 UUID = 1*( hex | "-" ) 2147 Examples: 2149 From: "A. G. Bell" 2150 From: sip:+12125551212@server.phone2net.com 2151 From: Anonymous 2153 The tag MAY appear in the From field of a request. It MUST be present 2154 when it is possible that two instances of a user sharing a SIP 2155 address can make call invitations with the same Call-ID. 2157 The use of version-1 (time based) or version-4 (random) UUID [19] is 2158 OPTIONAL. The tag value is designed to be globally unique and 2159 cryptographically random with at least 32 bits of randomness. A 2160 single user maintains the same tag throughout the call identified by 2161 the Call-ID. 2163 Call-ID, To and From are needed to identify a call leg leg 2164 matters in calls with multiple responses to a forked 2165 request. The format is similar to the equivalent RFC 822 2166 [24] header, but with a URI instead of just an email 2167 address. 2169 6.22 Hide 2171 A client uses the Hide request header field to indicate that it wants 2172 the path comprised of the Via header fields (Section 6.40) to be 2173 hidden from subsequent proxies and user agents. It can take two 2174 forms: Hide: route and Hide: hop. Hide header fields are typically 2175 added by the client user agent, but MAY be added by any proxy along 2176 the path. 2178 If a request contains the "Hide: route" header field, all following 2179 proxies SHOULD hide their previous hop. If a request contains the 2180 "Hide: hop" header field, only the next proxy SHOULD hide the 2181 previous hop and then remove the Hide option unless it also wants to 2182 remain anonymous. 2184 A server hides the previous hop by encrypting the host and port parts 2185 of the top-most Via header field with an algorithm of its choice. 2186 Servers SHOULD add additional "salt" to the host and port information 2187 prior to encryption to prevent malicious downstream proxies from 2188 guessing earlier parts of the path based on seeing identical 2189 encrypted Via headers. Hidden Via fields are marked with the hidden 2190 Via option, as described in Section 6.40. 2192 A server that is capable of hiding Via headers MUST attempt to 2193 decrypt all Via headers marked as "hidden" to perform loop detection. 2194 Servers that are not capable of hiding can ignore hidden Via fields 2195 in their loop detection algorithm. 2197 If hidden headers were not marked, a proxy would have to 2198 decrypt all headers to detect loops, just in case one was 2199 encrypted, as the Hide: Hop option may have been removed 2200 along the way. 2202 A host MUST NOT add such a "Hide: hop" header field unless it can 2203 guarantee it will only send a request for this destination to the 2204 same next hop. The reason for this is that it is possible that the 2205 request will loop back through this same hop from a downstream proxy. 2206 The loop will be detected by the next hop if the choice of next hop 2207 is fixed, but could loop an arbitrary number of times otherwise. 2209 A client requesting "Hide: route" can only rely on keeping the 2210 request path private if it sends the request to a trusted proxy. 2211 Hiding the route of a SIP request is of limited value if the request 2212 results in data packets being exchanged directly between the calling 2213 and called user agent. 2215 The use of Hide header fields is discouraged unless path privacy is 2216 truly needed; Hide fields impose extra processing costs and 2217 restrictions for proxies and can cause requests to generate 482 (Loop 2218 Detected) responses that could otherwise be avoided. 2220 The encryption of Via header fields is described in more detail in 2221 Section 13. 2223 The Hide header field has the following syntax: 2225 Hide = "Hide" ":" ( "route" | "hop" ) 2227 6.23 Max-Forwards 2229 The Max-Forwards request-header field may be used with any SIP method 2230 to limit the number of proxies or gateways that can forward the 2231 request to the next downstream server. This can also be useful when 2232 the client is attempting to trace a request chain which appears to be 2233 failing or looping in mid-chain. [H14.31] 2235 Max-Forwards = "Max-Forwards" ":" 1*DIGIT 2237 The Max-Forwards value is a decimal integer indicating the remaining 2238 number of times this request message is allowed to be forwarded. 2240 Each proxy or gateway recipient of a request containing a Max- 2241 Forwards header field MUST check and update its value prior to 2242 forwarding the request. If the received value is zero (0), the 2243 recipient MUST NOT forward the request. Instead, for the OPTIONS and 2244 REGISTER methods, it MUST respond as the final recipient. For all 2245 other methods, the server returns 483 (Too many hops). 2247 If the received Max-Forwards value is greater than zero, then the 2248 forwarded message MUST contain an updated Max-Forwards field with a 2249 value decremented by one (1). 2251 Example: 2253 Max-Forwards: 6 2255 6.24 Organization 2257 The Organization general-header field conveys the name of the 2258 organization to which the entity issuing the request or response 2259 belongs. It MAY also be inserted by proxies at the boundary of an 2260 organization. 2262 The field MAY be used by client software to filter calls. 2264 Organization = "Organization" ":" *text 2266 6.25 Priority 2268 The Priority request-header field indicates the urgency of the 2269 request as perceived by the client. 2271 Priority = "Priority" ":" priority-value 2272 priority-value = "emergency" | "urgent" | "normal" 2273 | "non-urgent" 2275 The value of "emergency" MUST only be used when life, limb or 2276 property are in imminent danger. 2278 Examples: 2280 Subject: A tornado is heading our way! 2281 Priority: emergency 2283 Subject: Weekend plans 2284 Priority: non-urgent 2286 These are the values of RFC 2076 [26], with the addition of 2287 "emergency". 2289 6.26 Proxy-Authenticate 2291 The Proxy-Authenticate response-header field MUST be included as part 2292 of a 407 (Proxy Authentication Required) response. The field value 2293 consists of a challenge that indicates the authentication scheme and 2294 parameters applicable to the proxy for this Request-URI. See [H14.33] 2295 for further details. 2297 A client SHOULD cache the credentials used for a particular proxy 2298 server and realm for the next request to that server. Credentials 2299 are, in general, valid for a specific value of the Request-URI at a 2300 particular proxy server. If a client contacts a proxy server that has 2301 required authentication in the past, but the client does not have 2302 credentials for the particular Request-URI, it MAY attempt to use the 2303 most-recently used credential. The server responds with 401 2304 (Unauthorized) if the client guessed wrong. 2306 This suggested caching behavior is motivated by proxies 2307 restricting phone calls to authenticated users. It seems 2308 likely that in most cases, all destinations require the 2309 same password. Note that end-to-end authentication is 2310 likely to be destination-specific. 2312 6.27 Proxy-Authorization 2314 The Proxy-Authorization request-header field allows the client to 2315 identify itself (or its user) to a proxy which requires 2316 authentication. The Proxy-Authorization field value consists of 2317 credentials containing the authentication information of the user 2318 agent for the proxy and/or realm of the resource being requested. See 2319 [H14.34] for further details. 2321 6.28 Proxy-Require 2323 The Proxy-Require header field is used to indicate proxy-sensitive 2324 features that MUST be supported by the proxy. Any Proxy-Require 2325 header field features that are not supported by the proxy MUST be 2326 negatively acknowledged by the proxy to the client if not supported. 2327 Servers treat this field identically to the Require field. 2329 See Section 6.30 for more details on the mechanics of this message 2330 and a usage example. 2332 6.29 Record-Route 2334 The Record-Route request and response header field is added to a 2335 request by any proxy that insists on being in the path of subsequent 2336 requests for the same call leg. It contains a globally reachable 2337 Request-URI that identifies the proxy server. Each proxy server adds 2338 its Request-URI to the beginning of the list. 2340 The server copies the Record-Route header field unchanged into the 2341 response. (Record-Route is only relevant for 2xx responses.) 2343 The calling user agent client copies the Record-Route header into a 2344 Route header field of subsequent requests within the same call leg, 2345 reversing the order of requests, so that the first entry is closest 2346 to the user agent client. If the response contained a Contact header 2347 field, the calling user agent adds its content as the last Route 2348 header. Unless this would cause a loop, any client MUST send any 2349 subsequent requests for this call leg to the first Request-URI in the 2350 Route request header field and remove that entry. 2352 The calling user agent MUST NOT use the Record-Route header field in 2353 requests that contain Route header fields. 2355 Some proxies, such as those controlling firewalls or in an 2356 automatic call distribution (ACD) system, need to maintain 2357 call state and thus need to receive any BYE and ACK packets 2358 for the call. 2360 The Record-Route header field has the following syntax: 2362 Record-Route = "Record-Route" ":" 1# name-addr 2364 Proxy servers SHOULD use the maddr URL parameter containing their 2365 address to ensure that subsequent requests are guaranteed to reach 2366 exactly the same server. 2368 Example for a request that has traversed the hosts ieee.org and 2369 bell-telephone.com , in that order: 2371 Record-Route: sip:a.g.bell@bell-telephone.com, sip:a.bell@ieee.org 2373 6.30 Require 2375 The Require request-header field is used by clients to tell user 2376 agent servers about options that the client expects the server to 2377 support in order to properly process the request. If a server does 2378 not understand the option, it MUST respond by returning status code 2379 420 (Bad Extension) and list those options it does not understand in 2380 the Unsupported header. 2382 Require = "Require" ":" 1#option-tag 2384 Example: 2386 C->S: INVITE sip:watson@bell-telephone.com SIP/2.0 2387 Require: com.example.billing 2388 Payment: sheep_skins, conch_shells 2390 S->C: SIP/2.0 420 Bad Extension 2391 Unsupported: com.example.billing 2393 This is to make sure that the client-server interaction 2394 will proceed without delay when all options are understood 2395 by both sides, and only slow down if options are not 2396 understood (as in the example above). For a well-matched 2397 client-server pair, the interaction proceeds quickly, 2398 saving a round-trip often required by negotiation 2399 mechanisms. In addition, it also removes ambiguity when the 2400 client requires features that the server does not 2401 understand. Some features, such as call handling fields, 2402 are only of interest to end systems. 2404 Proxy and redirect servers MUST ignore features that are not 2405 understood. If a particular extension requires that intermediate 2406 devices support it, the extension MUST be tagged in the Proxy-Require 2407 field instead (see Section 6.28). 2409 6.31 Response-Key 2411 The Response-Key request-header field can be used by a client to 2412 request the key that the called user agent SHOULD use to encrypt the 2413 response with. The syntax is: 2415 Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param 2416 key-scheme = token 2417 key-param = token "=" ( token | quoted-string ) 2419 The key-scheme gives the type of encryption to be used for the 2420 response. Section 13 describes security schemes. 2422 If the client insists that the server return an encrypted response, 2423 it includes a 2424 Require: org.ietf.sip.encrypt-response 2425 header field in its request. If the client cannot encrypt for 2426 whatever reason, it MUST follow normal Require header field 2427 procedures and return a 420 (Bad Extension) response. If this Require 2428 header field is not present, a client SHOULD still encrypt, but MAY 2429 return an unencrypted response if unable to. 2431 6.32 Retry-After 2433 The Retry-After general-header field can be used with a 503 (Service 2434 Unavailable) response to indicate how long the service is expected to 2435 be unavailable to the requesting client and with a 404 (Not Found), 2436 600 (Busy), or 603 (Decline) response to indicate when the called 2437 party anticipates being available again. The value of this field can 2438 be either an HTTP-date or an integer number of seconds (in decimal) 2439 after the time of the response. 2441 A REGISTER request MAY include this header field when deleting 2442 registrations with Contact: * ;expires: 0. The Retry-After value then 2443 indicates when the user might again be reachable. The registrar MAY 2444 then include this information in responses to future calls. 2446 An optional comment can be used to indicate additional information 2447 about the time of callback. An optional duration parameter indicates 2448 how long the called party will be reachable starting at the initial 2449 time of availability. If no duration parameter is given, the service 2450 is assumed to be available indefinitely. 2452 Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) 2453 [ comment ] [ ";duration" "=" delta-seconds ] 2455 Examples of its use are 2457 Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting) 2458 Retry-After: Mon, 1 Jan 9999 00:00:00 GMT 2459 (Dear John: Don't call me back, ever) 2460 Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600 2461 Retry-After: 120 2463 In the third example, the callee is reachable for one hour starting 2464 at 21:00 GMT. In the last example, the delay is 2 minutes. 2466 6.33 Route 2468 The Route request-header field determines the route taken by a 2469 request. Each host removes the first entry and then proxies the 2470 request to the host listed in that entry, also using it as the 2471 Request-URI. The operation is further described in Section 6.29. 2473 The Route header field has the following syntax: 2475 Route = "Route" ":" 1# addr-spec 2477 6.34 Server 2479 The Server response-header field contains information about the 2480 software used by the user agent server to handle the request. See 2481 [H14.39]. 2483 6.35 Subject 2485 This is intended to provide a summary, or to indicate the nature, of 2486 the call, allowing call filtering without having to parse the session 2487 description. (Also, the session description does not have to use the 2488 same subject indication as the invitation.) 2490 Subject = ( "Subject" | "s" ) ":" *text 2492 Example: 2494 Subject: Tune in - they are talking about your work! 2496 6.36 Timestamp 2498 The timestamp general-header field describes when the client sent the 2499 request to the server. The value of the timestamp is of significance 2500 only to the client and MAY use any timescale. The server MUST echo 2501 the exact same value and MAY, if it has accurate information about 2502 this, add a floating point number indicating the number of seconds 2503 that have elapsed since it has received the request. The timestamp is 2504 used by the client to compute the round-trip time to the server so 2505 that it can adjust the timeout value for retransmissions. 2507 Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] 2508 delay = *(DIGIT) [ "." *(DIGIT) ] 2510 6.37 To 2512 The To general-header field specifies recipient of the request, with 2513 the same SIP URL syntax as the From field. 2515 To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) addr-params 2517 Requests and responses MUST contain a To general-header field, 2518 indicating the desired recipient of the request. The optional 2519 display-name is meant to be rendered by a human-user interface. The 2520 UAS or redirect server copies the To header field into its response, 2521 and MUST add a tag parameter if the URL in the To header field is not 2522 a full qualified hostname. 2524 The SIP-URL MUST NOT contain the transport-param, maddr-param, ttl- 2525 param, or headers elements. A server that receives a SIP-URL with 2526 these elements removes them before further processing. 2528 The tag parameter serves as a general mechanism to distinguish 2529 multiple instances of a user identified by a single SIP URL. As 2530 proxies can fork requests, the same request can reach multiple 2531 instances of a user (mobile and home phones, for example). As each 2532 can respond, there needs to be a means to distinguish the responses 2533 from each at the caller. The situation also arises with multicast 2534 requests. The tag in the To header field serves to distinguish 2535 responses at the UAC. It MUST be placed in the To field of the 2536 response by each instance when there is a possibility that the 2537 request was forked at an intermediate proxy. This, in general, means 2538 that the tag MUST be inserted when the URL in the To does not refer 2539 to a fully qualified hostname. The tag MUST be added by UAS, 2540 registrars and redirect servers, but MUST NOT be inserted into 2541 responses forwarded upstream by proxies. The tag is added for all 2542 definitive responses for all methods, and MAY be added for 2543 informational responses from a UAS or redirect server. All subsequent 2544 transactions between two entities MUST include the tag parameter, as 2545 described in Section 11. 2547 The use of version-1 (time based) or version-4 (random) UUID [19] is 2548 OPTIONAL. The tag value is designed to be globally unique and 2549 cryptographically random with at least 32 bits of randomness. A 2550 single user maintains the same tag throughout the call identified by 2551 the Call-ID. 2553 The tag parameter in To headers is ignored when matching responses to 2554 requests that did not contain a tag in their To header. 2556 A SIP server returns a 400 (Bad Request) response if it receives a 2557 request with a To header field containing a URI with a scheme it does 2558 not recognize. 2560 Example: 2562 To: The Operator ;tag=287447 2563 To: sip:+12125551212@server.phone2net.com 2565 Call-ID, To and From are needed to identify a call leg leg 2566 matters in calls with multiple responses from a forked 2567 request. The tag is added to the To header field in the 2568 response to allow forking of future requests for the same 2569 call by proxies, while addressing only one of the possibly 2570 several responding user agent servers. It also allows 2571 several instances of the callee to send requests that can 2572 be distinguished. 2574 6.38 Unsupported 2575 The Unsupported response-header field lists the features not 2576 supported by the server. See Section 6.30 for a usage example and 2577 motivation. 2579 6.39 User-Agent 2581 The User-Agent general-header field contains information about the 2582 client user agent originating the request. See [H14.42]. 2584 6.40 Via 2586 The Via field indicates the path taken by the request so far. This 2587 prevents request looping and ensures replies take the same path as 2588 the requests, which assists in firewall traversal and other unusual 2589 routing situations. 2591 6.40.1 Requests 2593 The client originating the request MUST insert into the request a Via 2594 field containing its host name or network address and, if not the 2595 default port number, the port number at which it wishes to receive 2596 responses. (Note that this port number can differ from the UDP source 2597 port number of the request.) A fully-qualified domain name is 2598 RECOMMENDED. Each subsequent proxy server that sends the request 2599 onwards MUST add its own additional Via field before any existing Via 2600 fields. A proxy that receives a redirection (3xx) response and then 2601 searches recursively, MUST use the same Via headers as on the 2602 original request. 2604 A proxy SHOULD check the top-most Via header field to ensure that it 2605 contains the sender's correct network address, as seen from that 2606 proxy. If the sender's address is incorrect, the proxy MUST add an 2607 additional received attribute, as described 6.40.2. 2609 A host behind a network address translator (NAT) or 2610 firewall may not be able to insert a network address into 2611 the Via header that can be reached by the next hop beyond 2612 the NAT. Hosts behind NATs or NAPTs MUST insert the local 2613 port number of the outgoing socket, rather than the port 2614 number for incoming requests, as NAPTs assume that 2615 responses return with reversed source and destination 2616 ports. 2618 A proxy sending a request to a multicast address MUST add the maddr 2619 parameter to its Via header field, and SHOULD add the ttl parameter. 2620 If a server receives a request which contained an maddr parameter in 2621 the topmost Via field, it SHOULD send the response to the multicast 2622 address listed in the maddr parameter. 2624 If a proxy server receives a request which contains its own address, 2625 it MUST respond with a 482 (Loop Detected) status code. 2627 This prevents a malfunctioning proxy server from causing 2628 loops. Also, it cannot be guaranteed that a proxy server 2629 can always detect that the address returned by a location 2630 service refers to a host listed in the Via list, as a 2631 single host may have aliases or several network interfaces. 2633 6.40.2 Receiver-tagged Via Fields 2635 Normally, every host that sends or forwards a SIP message adds a Via 2636 field indicating the path traversed. However, it is possible that 2637 Network Address Translators (NAT) changes the source address of the 2638 request (e.g., from net-10 to a globally routable address), in which 2639 case the Via field cannot be relied on to route replies. To prevent 2640 this, a proxy SHOULD check the top-most Via header field to ensure 2641 that it contains the sender's correct network address, as seen from 2642 that proxy. If the sender's address is incorrect, the proxy MUST add 2643 a received tag to the Via field inserted by the previous hop. Such a 2644 modified Via field is known as a receiver-tagged Via field. An 2645 example is: 2647 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060 2648 Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3 2650 In this example, the message originated from 10.0.0.1 and traversed a 2651 NAT with the external address border.ieee.org (199.172.136.3) to 2652 reach erlang.bell-telephone.com and tagged the previous hop's Via 2653 field with the address that it actually came from. 2655 6.40.3 Responses 2657 In the return path, Via fields are processed by a proxy or client 2658 according to the following rules: 2660 1. The first Via field should indicate the proxy or client 2661 processing this response. If it does not, discard the 2662 message. Otherwise, remove this Via field. 2664 2. If the second Via field contains a maddr parameter, the 2665 response is sent to the address listed there, using the 2666 port indicated in sent-by, or 5060 if none is present. The 2667 response SHOULD be sent using the TTL indicated in the ttl 2668 parameter, or with a TTL of 1 if none is present. 2670 3. Otherwise, if the second Via field is a receiver-tagged 2671 field (Section 6.40.2), send the message to the address in 2672 the received tag, using the port present in sent-by, or 2673 port 5060 if none is present. 2675 4. Otherwise, send the message to the address indicated by 2676 sent-by in the second Via field. 2678 5. If there is no second Via field, this response is destined 2679 for this client. 2681 A user agent server or redirect server sends a response by pretending 2682 to insert the received tag into the topmost Via header field in the 2683 request, and treating this header field as the second Via in the 2684 above procedure. 2686 These rules ensure that a client only has to check the first Via 2687 field in a response to see if it needs processing. 2689 6.40.4 Syntax 2691 The format for a Via header field is shown in Fig. 10. 2693 The defaults for "protocol-name" and "transport" are "SIP" and "UDP", 2694 respectively. The "maddr" parameter, designating the multicast 2695 address, and the "ttl" parameter, designating the time-to-live (TTL) 2696 value, are included only if the request was sent via multicast. The 2697 "received" parameter is added only for receiver-added Via fields 2698 (Section 6.40.2). For reasons of privacy, a client or proxy may wish 2699 to hide its Via information by encrypting it (see Section 6.22). The 2700 "hidden" parameter is included if this header field was hidden by the 2701 upstream proxy (see 6.22). Note that privacy of the proxy relies on 2702 the cooperation of the next hop, as the next-hop proxy will, by 2703 necessity, know the IP address and port number of the source host. 2705 The "branch" parameter is included by every forking proxy. The token 2706 MUST be unique for each distinct request generated when a proxy 2707 forks. When a response arrives at the proxy it can use the branch 2708 value to figure out which branch the response corresponds to. A proxy 2709 which generates a single request (non-forking) MAY also insert the 2710 "branch" parameter. The identifier has to be unique only within a set 2711 of isomorphic requests. 2713 Via = ( "Via" $|$ "v") ":" 1#( sent-protocol sent-by 2714 *( ";" via-params ) [ comment ] ) 2715 via-params = via-hidden | via-ttl | via-maddr 2716 | via-received | via-branch 2717 via-hidden = "hidden" 2718 via-ttl = "ttl" "=" ttl 2719 via-maddr = "maddr" "=" maddr 2720 via-received = "received" "=" host 2721 via-branch = "branch" "=" token 2722 sent-protocol = protocol-name "/" protocol-version "/" transport 2723 protocol-name = "SIP" $|$ token 2724 protocol-version = token 2725 transport = "UDP" $|$ "TCP" $|$ token 2726 sent-by = ( host [ ":" port ] ) $|$ ( concealed-host ) 2727 concealed-host = token 2728 ttl = 1*3DIGIT ; 0 to 255 2730 Figure 10: Syntax of Via header field 2732 Via: SIP/2.0/UDP first.example.com:4000;ttl=16 2733 ;maddr=224.2.0.1 (Example) 2734 Via: SIP/2.0/UDP adk8 2736 6.41 Warning 2738 The Warning response-header field is used to carry additional 2739 information about the status of a response. Warning headers are sent 2740 with responses and have the following format: 2742 Warning = "Warning" ":" 1#warning-value 2743 warning-value = warn-code SP warn-agent SP warn-text 2744 warn-code = 3DIGIT 2745 warn-agent = ( host [ ":" port ] ) | pseudonym 2746 ; the name or pseudonym of the server adding 2747 ; the Warning header, for use in debugging 2748 warn-text = quoted-string 2750 A response MAY carry more than one Warning header. 2752 The warn-text should be in a natural language that is most likely to 2753 be intelligible to the human user receiving the response. This 2754 decision can be based on any available knowledge, such as the 2755 location of the cache or user, the Accept-Language field in a 2756 request, or the Content-Language field in a response. The default 2757 language is English. 2759 Any server MAY add Warning headers to a response. Proxy servers MUST 2760 place additional Warning headers before any Authorization headers. 2761 Within that constraint, Warning headers MUST be added after any 2762 existing Warning headers not covered by a signature. A proxy server 2763 MUST NOT delete any Warning header field that it received with a 2764 response. 2766 When multiple Warning headers are attached to a response, the user 2767 agent SHOULD display as many of them as possible, in the order that 2768 they appear in the response. If it is not possible to display all of 2769 the warnings, the user agent first displays warnings that appear 2770 early in the response. 2772 The warn-code consists of three digits. A first digit of "3" 2773 indicates warnings specific to SIP. 2775 This is a list of the currently-defined warn-codes, each with a 2776 recommended warn-text in English, and a description of its meaning. 2777 Note that these warnings describe failures induced by the session 2778 description. 2780 Warnings 300 through 329 are reserved for indicating problems with 2781 keywords in the session description, 330 through 339 are warnings 2782 related to basic network services requested in the session 2783 description, 370 through 379 are warnings related to quantitative QoS 2784 parameters requested in the session description, and 390 through 399 2785 are miscellaneous warnings that do not fall into one of the above 2786 categories. 2788 300 Incompatible network protocol: One or more network protocols 2789 contained in the session description are not available. 2791 301 Incompatible network address formats: One or more network address 2792 formats contained in the session description are not available. 2794 302 Incompatible transport protocol: One or more transport protocols 2795 described in the session description are not available. 2797 303 Incompatible bandwidth units: One or more bandwidth measurement 2798 units contained in the session description were not understood. 2800 304 Media type not available: One or more media types contained in 2801 the session description are not available. 2803 305 Incompatible media format: One or more media formats contained in 2804 the session description available. 2806 306 Attribute not understood: One or more of the media attributes in 2807 the session description are not supported. 2809 307 Session description parameter not understood: A parameter other 2810 than those listed above was not understood. 2812 330 Multicast not available: The site where the user is located does 2813 not support multicast. 2815 331 Unicast not available: The site where the user is located does 2816 not support unicast communication (usually due to the presence 2817 of a firewall). 2819 370 Insufficient bandwidth: The bandwidth specified in the session 2820 description or defined by the media exceeds that known to be 2821 available. 2823 399 Miscellaneous warning: The warning text can include arbitrary 2824 information to be presented to a human user, or logged. A system 2825 receiving this warning MUST NOT take any automated action. 2827 1xx and 2xx have been taken by HTTP/1.1. 2829 Additional warn-codes, as in the example below, can be defined 2830 through IANA. 2832 Examples: 2834 Warning: 307 isi.edu "Session parameter 'foo' not understood" 2835 Warning: 301 isi.edu "Incompatible network address type 'E.164'" 2837 6.42 WWW-Authenticate 2839 The WWW-Authenticate response-header field MUST be included in 401 2840 (Unauthorized) response messages. The field value consists of at 2841 least one challenge that indicates the authentication scheme(s) and 2842 parameters applicable to the Request-URI. See [H14.46] and [27]. 2844 The content of the realm parameter SHOULD be displayed to the user. A 2845 user agent SHOULD cache the authorization credentials for a given 2846 value of the destination (To header) and realm and attempt to re-use 2847 these values on the next request for that destination. 2849 In addition to the "basic" and "digest" authentication schemes 2850 defined in the specifications cited above, SIP defines a new scheme, 2851 PGP (RFC 2015, [28]), Section 14. Other schemes, such as S-MIME, are 2852 for further study. 2854 7 Status Code Definitions 2856 The response codes are consistent with, and extend, HTTP/1.1 response 2857 codes. Not all HTTP/1.1 response codes are appropriate, and only 2858 those that are appropriate are given here. Other HTTP/1.1 response 2859 codes SHOULD NOT be used. Response codes not defined by HTTP/1.1 have 2860 codes x80 upwards to avoid clashes with future HTTP response codes. 2861 Also, SIP defines a new class, 6xx. The default behavior for unknown 2862 response codes is given for each category of codes. 2864 7.1 Informational 1xx 2866 Informational responses indicate that the server or proxy contacted 2867 is performing some further action and does not yet have a definitive 2868 response. The client SHOULD wait for a further response from the 2869 server, and the server SHOULD send such a response without further 2870 prompting. A server SHOULD send a 1xx response if it expects to take 2871 more than 200 ms to obtain a final response. A server MAY issue zero 2872 or more 1xx responses, with no restriction on their ordering or 2873 uniqueness. Note that 1xx responses are not transmitted reliably, 2874 that is, they do not cause the client to send an ACK. Servers are 2875 free to retransmit informational responses and clients can inquire 2876 about the current state of call processing by re-sending the request. 2878 7.1.1 100 Trying 2880 Some unspecified action is being taken on behalf of this call (e.g., 2881 a database is being consulted), but the user has not yet been 2882 located. 2884 7.1.2 180 Ringing 2886 The called user agent has located a possible location where the user 2887 has registered recently and is trying to alert the user. 2889 7.1.3 181 Call Is Being Forwarded 2891 A proxy server MAY use this status code to indicate that the call is 2892 being forwarded to a different set of destinations. The new 2893 destinations are listed in Contact headers. Proxies SHOULD be 2894 configurable not to reveal this information. 2896 7.1.4 182 Queued 2898 The called party is temporarily unavailable, but the callee has 2899 decided to queue the call rather than reject it. When the callee 2900 becomes available, it will return the appropriate final status 2901 response. The reason phrase MAY give further details about the status 2902 of the call, e.g., "5 calls queued; expected waiting time is 15 2903 minutes". The server MAY issue several 182 responses to update the 2904 caller about the status of the queued call. 2906 7.2 Successful 2xx 2908 The request was successful and MUST terminate a search. 2910 7.2.1 200 OK 2912 The request has succeeded. The information returned with the response 2913 depends on the method used in the request, for example: 2915 BYE: The call has been terminated. The message body is empty. 2917 CANCEL: The search has been cancelled. The message body is empty. 2919 INVITE: The callee has agreed to participate; the message body 2920 indicates the callee's capabilities. 2922 OPTIONS: The callee has agreed to share its capabilities, included in 2923 the message body. 2925 REGISTER: The registration has succeeded. The client treats the 2926 message body according to its Content-Type. 2928 7.3 Redirection 3xx 2930 3xx responses give information about the user's new location, or 2931 about alternative services that might be able to satisfy the call. 2932 They SHOULD terminate an existing search, and MAY cause the initiator 2933 to begin a new search if appropriate. 2935 Any redirection (3xx) response MUST NOT suggest any of the addresses 2936 in the Via (Section 6.40) path of the request in the Contact header 2937 field. (Addresses match if their host and port number match.) 2939 To avoid forwarding loops, a user agent client or proxy MUST check 2940 whether the address returned by a redirect server equals an address 2941 tried earlier. 2943 7.3.1 300 Multiple Choices 2945 The address in the request resolved to several choices, each with its 2946 own specific location, and the user (or user agent) can select a 2947 preferred communication end point and redirect its request to that 2948 location. 2950 The response SHOULD include an entity containing a list of resource 2951 characteristics and location(s) from which the user or user agent can 2952 choose the one most appropriate, if allowed by the Accept request 2953 header. The entity format is specified by the media type given in the 2954 Content-Type header field. The choices SHOULD also be listed as 2955 Contact fields (Section 6.13). Unlike HTTP, the SIP response MAY 2956 contain several Contact fields or a list of addresses in a Contact 2957 field. User agents MAY use the Contact header field value for 2958 automatic redirection or MAY ask the user to confirm a choice. 2959 However, this specification does not define any standard for such 2960 automatic selection. 2962 This status response is appropriate if the callee can be 2963 reached at several different locations and the server 2964 cannot or prefers not to proxy the request. 2966 7.3.2 301 Moved Permanently 2968 The user can no longer be found at the address in the Request-URI and 2969 the requesting client SHOULD retry at the new address given by the 2970 Contact header field (Section 6.13). The caller SHOULD update any 2971 local directories, address books and user location caches with this 2972 new value and redirect future requests to the address(es) listed. 2974 7.3.3 302 Moved Temporarily 2976 The requesting client SHOULD retry the request at the new address(es) 2977 given by the Contact header field (Section 6.13). The duration of the 2978 redirection can be indicated through an Expires (Section 6.20) 2979 header. 2981 7.3.4 380 Alternative Service 2983 The call was not successful, but alternative services are possible. 2984 The alternative services are described in the message body of the 2985 response. 2987 7.4 Request Failure 4xx 2988 4xx responses are definite failure responses from a particular 2989 server. The client SHOULD NOT retry the same request without 2990 modification (e.g., adding appropriate authorization). However, the 2991 same request to a different server might be successful. 2993 7.4.1 400 Bad Request 2995 The request could not be understood due to malformed syntax. 2997 7.4.2 401 Unauthorized 2999 The request requires user authentication. 3001 7.4.3 402 Payment Required 3003 Reserved for future use. 3005 7.4.4 403 Forbidden 3007 The server understood the request, but is refusing to fulfill it. 3008 Authorization will not help, and the request SHOULD not be repeated. 3010 7.4.5 404 Not Found 3012 The server has definitive information that the user does not exist at 3013 the domain specified in the Request-URI. This status is also returned 3014 if the domain in the Request-URI does not match any of the domains 3015 handled by the recipient of the request. 3017 7.4.6 405 Method Not Allowed 3019 The method specified in the Request-Line is not allowed for the 3020 address identified by the Request-URI. The response MUST include an 3021 Allow header field containing a list of valid methods for the 3022 indicated address. 3024 7.4.7 406 Not Acceptable 3026 The resource identified by the request is only capable of generating 3027 response entities which have content characteristics not acceptable 3028 according to the accept headers sent in the request. 3030 7.4.8 407 Proxy Authentication Required 3032 This code is similar to 401 (Unauthorized), but indicates that the 3033 client MUST first authenticate itself with the proxy. The proxy MUST 3034 return a Proxy-Authenticate header field (section 6.26) containing a 3035 challenge applicable to the proxy for the requested resource. The 3036 client MAY repeat the request with a suitable Proxy-Authorization 3037 header field (section 6.27). SIP access authentication is explained 3038 in section 13.2 and [H11]. 3040 This status code is used for applications where access to the 3041 communication channel (e.g., a telephony gateway) rather than the 3042 callee herself requires authentication. 3044 7.4.9 408 Request Timeout 3046 The server could not produce a response, e.g., a user location, 3047 within the time indicated in the Expires request-header field. The 3048 client MAY repeat the request without modifications at any later 3049 time. 3051 7.4.10 409 Conflict 3053 The request could not be completed due to a conflict with the current 3054 state of the resource. This response is returned is the action 3055 parameter in a REGISTER request conflicts with existing 3056 registrations. 3058 7.4.11 410 Gone 3060 The requested resource is no longer available at the server and no 3061 forwarding address is known. This condition is expected to be 3062 considered permanent. If the server does not know, or has no facility 3063 to determine, whether or not the condition is permanent, the status 3064 code 404 (Not Found) SHOULD be used instead. 3066 7.4.12 411 Length Required 3068 The server refuses to accept the request without a defined Content- 3069 Length. The client MAY repeat the request if it adds a valid 3070 Content-Length header field containing the length of the message-body 3071 in the request message. 3073 7.4.13 413 Request Entity Too Large 3075 The server is refusing to process a request because the request 3076 entity is larger than the server is willing or able to process. The 3077 server MAY close the connection to prevent the client from continuing 3078 the request. 3080 If the condition is temporary, the server SHOULD include a Retry- 3081 After header field to indicate that it is temporary and after what 3082 time the client MAY try again. 3084 7.4.14 414 Request-URI Too Long 3086 The server is refusing to service the request because the Request-URI 3087 is longer than the server is willing to interpret. 3089 7.4.15 415 Unsupported Media Type 3091 The server is refusing to service the request because the message 3092 body of the request is in a format not supported by the requested 3093 resource for the requested method. 3095 7.4.16 420 Bad Extension 3097 The server did not understand the protocol extension specified in a 3098 Require (Section 6.30) header field. 3100 7.4.17 480 Temporarily Unavailable 3102 The callee's end system was contacted successfully but the callee is 3103 currently unavailable (e.g., not logged in or logged in in such a 3104 manner as to preclude communication with the callee). The response 3105 MAY indicate a better time to call in the Retry-After header. The 3106 user could also be available elsewhere (unbeknownst to this host), 3107 thus, this response does not terminate any searches. The reason 3108 phrase SHOULD indicate a more precise cause as to why the callee is 3109 unavailable. This value SHOULD be setable by the user agent. Status 3110 486 (Busy Here) MAY be used to more precisely indicate a particular 3111 reason for the call failure. 3113 7.4.18 481 Call Leg/Transaction Does Not Exist 3115 This status is returned under two conditions: The server received a 3116 BYE request that does not match any existing call leg or the server 3117 received a CANCEL request that does not match any existing 3118 transaction. (A server simply discards an ACK referring to an unknown 3119 transaction.) 3121 7.4.19 482 Loop Detected 3123 The server received a request with a Via (Section 6.40) path 3124 containing itself. 3126 7.4.20 483 Too Many Hops 3128 The server received a request that contains more Via entries (hops) 3129 (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header 3130 field. 3132 7.4.21 484 Address Incomplete 3134 The server received a request with a To (Section 6.37) address or 3135 Request-URI that was incomplete. Additional information SHOULD be 3136 provided. 3138 This status code allows overlapped dialing. With overlapped 3139 dialing, the client does not know the length of the dialing 3140 string. It sends strings of increasing lengths, prompting 3141 the user for more input, until it no longer receives a 484 3142 status response. 3144 7.4.22 485 Ambiguous 3146 The callee address provided in the request was ambiguous. The 3147 response MAY contain a listing of possible unambiguous addresses in 3148 Contact headers. 3150 Revealing alternatives can infringe on privacy concerns of the user 3151 or the organization. It MUST be possible to configure a server to 3152 respond with status 404 (Not Found) or to suppress the listing of 3153 possible choices if the request address was ambiguous. 3155 Example response to a request with the URL lee@example.com : 3157 485 Ambiguous SIP/2.0 3158 Contact: Carol Lee 3159 Contact: Ping Lee 3160 Contact: Lee M. Foote 3162 Some email and voice mail systems provide this 3163 functionality. A status code separate from 3xx is used 3164 since the semantics are different: for 300, it is assumed 3165 that the same person or service will be reached by the 3166 choices provided. While an automated choice or sequential 3167 search makes sense for a 3xx response, user intervention is 3168 required for a 485 response. 3170 7.4.23 486 Busy Here 3172 The callee's end system was contacted successfully but the callee is 3173 currently not willing or able to take additional calls. The response 3174 MAY indicate a better time to call in the Retry-After header. The 3175 user could also be available elsewhere, such as through a voice mail 3176 service, thus, this response does not terminate any searches. Status 3177 600 (Busy Everywhere) SHOULD be used if the client knows that no 3178 other end system will be able to accept this call. 3180 7.5 Server Failure 5xx 3182 5xx responses are failure responses given when a server itself has 3183 erred. They are not definitive failures, and MUST NOT terminate a 3184 search if other possible locations remain untried. 3186 7.5.1 500 Server Internal Error 3188 The server encountered an unexpected condition that prevented it from 3189 fulfilling the request. 3191 7.5.2 501 Not Implemented 3193 The server does not support the functionality required to fulfill the 3194 request. This is the appropriate response when the server does not 3195 recognize the request method and is not capable of supporting it for 3196 any user. 3198 7.5.3 502 Bad Gateway 3200 The server, while acting as a gateway or proxy, received an invalid 3201 response from the downstream server it accessed in attempting to 3202 fulfill the request. 3204 7.5.4 503 Service Unavailable 3206 The server is currently unable to handle the request due to a 3207 temporary overloading or maintenance of the server. The implication 3208 is that this is a temporary condition which will be alleviated after 3209 some delay. If known, the length of the delay MAY be indicated in a 3210 Retry-After header. If no Retry-After is given, the client MUST 3211 handle the response as it would for a 500 response. 3213 Note: The existence of the 503 status code does not imply that a 3214 server has to use it when becoming overloaded. Some servers MAY wish 3215 to simply refuse the connection. 3217 7.5.5 504 Gateway Timeout 3219 The server, while acting as a gateway, did not receive a timely 3220 response from the server (e.g., a location server) it accessed in 3221 attempting to complete the request. 3223 7.5.6 505 Version Not Supported 3224 The server does not support, or refuses to support, the SIP protocol 3225 version that was used in the request message. The server is 3226 indicating that it is unable or unwilling to complete the request 3227 using the same major version as the client, other than with this 3228 error message. The response SHOULD contain an entity describing why 3229 that version is not supported and what other protocols are supported 3230 by that server. 3232 7.6 Global Failures 6xx 3234 6xx responses indicate that a server has definitive information about 3235 a particular user, not just the particular instance indicated in the 3236 Request-URI. All further searches for this user are doomed to failure 3237 and pending searches SHOULD be terminated. 3239 7.6.1 600 Busy Everywhere 3241 The callee's end system was contacted successfully but the callee is 3242 busy and does not wish to take the call at this time. The response 3243 MAY indicate a better time to call in the Retry-After header. If the 3244 callee does not wish to reveal the reason for declining the call, the 3245 callee uses status code 603 (Decline) instead. This status response 3246 is returned only if the client knows that no other end point (such as 3247 a voice mail system) will answer the request. Otherwise, 486 (Busy 3248 Here) should be returned. 3250 7.6.2 603 Decline 3252 The callee's machine was successfully contacted but the user 3253 explicitly does not wish to or cannot participate. The response MAY 3254 indicate a better time to call in the Retry-After header. 3256 7.6.3 604 Does Not Exist Anywhere 3258 The server has authoritative information that the user indicated in 3259 the To request field does not exist anywhere. Searching for the user 3260 elsewhere will not yield any results. 3262 7.6.4 606 Not Acceptable 3264 The user's agent was contacted successfully but some aspects of the 3265 session description such as the requested media, bandwidth, or 3266 addressing style were not acceptable. 3268 A 606 (Not Acceptable) response means that the user wishes to 3269 communicate, but cannot adequately support the session described. The 3270 606 (Not Acceptable) response MAY contain a list of reasons in a 3271 Warning header field describing why the session described cannot be 3272 supported. Reasons are listed in Section 6.41. It is hoped that 3273 negotiation will not frequently be needed, and when a new user is 3274 being invited to join an already existing conference, negotiation may 3275 not be possible. It is up to the invitation initiator to decide 3276 whether or not to act on a 606 (Not Acceptable) response. 3278 8 SIP Message Body 3280 8.1 Body Inclusion 3282 Requests MAY contain message bodies unless otherwise noted. Within 3283 this specification, the BYE request MUST NOT contain a message body. 3284 For ACK, INVITE and OPTIONS, the message body is always a session 3285 description. The use of message bodies for REGISTER requests is for 3286 further study. 3288 For response messages, the request method and the response status 3289 code determine the type and interpretation of any message body. All 3290 responses MAY include a body. Message bodies for 1xx responses 3291 contain advisory information about the progress of the request. 2xx 3292 responses to INVITE requests contain session descriptions. In 3xx 3293 respones, the message body MAY contain the description of alternative 3294 destinations or services, as described in Section 7.3. For responses 3295 with status 400 or greater, the message body MAY contain additional, 3296 human-readable information about the reasons for failure. It is 3297 RECOMMENDED that information in 1xx and 300 and greater responses be 3298 of type text/plain or text/html 3300 8.2 Message Body Type 3302 The Internet media type of the message body MUST be given by the 3303 Content-Type header field, If the body has undergone any encoding 3304 (such as compression) then this MUST be indicated by the Content- 3305 Encoding header field, otherwise Content-Encoding MUST be omitted. If 3306 applicable, the character set of the message body is indicated as 3307 part of the Content-Type header-field value. 3309 8.3 Message Body Length 3311 The body length in bytes SHOULD be given by the Content-Length header 3312 field. Section 6.15 describes the behavior in detail. 3314 The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. 3315 (Note: The chunked encoding modifies the body of a message in order 3316 to transfer it as a series of chunks, each with its own size 3317 indicator.) 3319 9 Compact Form 3320 When SIP is carried over UDP with authentication and a complex 3321 session description, it may be possible that the size of a request or 3322 response is larger than the MTU. To reduce this problem, a more 3323 compact form of SIP is also defined by using alternative names for 3324 common header fields. These short forms are NOT abbreviations, they 3325 are field names. No other header field abbreviations are allowed. 3327 short field name long field name note 3328 c Content-Type 3329 e Content-Encoding 3330 f From 3331 i Call-ID 3332 m Contact from "moved" 3333 l Content-Length 3334 s Subject 3335 t To 3336 v Via 3338 Thus, the header in section 15.2 could also be written: 3340 INVITE sip:schooler@vlsi.caltech.edu SIP/2.0 3341 v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16 3342 v:SIP/2.0/UDP 128.16.64.19 3343 f:sip:mjh@isi.edu 3344 t:sip:schooler@cs.caltech.edu 3345 i:62729-27@128.16.64.19 3346 c:application/sdp 3347 CSeq: 4711 INVITE 3348 l:187 3350 v=0 3351 o=user1 53655765 2353687637 IN IP4 128.3.4.5 3352 s=Mbone Audio 3353 i=Discussion of Mbone Engineering Issues 3354 e=mbone@somewhere.com 3355 c=IN IP4 224.2.0.1/127 3356 t=0 0 3357 m=audio 3456 RTP/AVP 0 3359 Mixing short field names and long field names is allowed, but not 3360 recommended. Servers MUST accept both short and long field names for 3361 requests. Proxies MUST NOT translate a request between short and long 3362 forms. 3364 10 Behavior of SIP Clients and Servers 3366 10.1 General Remarks 3368 SIP is defined so it can use either UDP (unicast or multicast) or TCP 3369 as a transport protocol; it provides its own reliability mechanism. 3371 10.1.1 Requests 3373 Servers ignore isomorphic requests, but retransmit the appropriate 3374 response. (SIP requests are said to be idempotent , i.e., receiving 3375 more than one copy of a request does not change the server state.) 3377 After receiving a CANCEL request from an upstream client, a stateful 3378 proxy server MAY send a CANCEL on all branches where it has not yet 3379 received a final response. 3381 When a user agent receives a request, it checks the Call-ID against 3382 those of in-progress calls. If the Call-ID was found, it compares the 3383 tag value of To with the user's tag and rejects the request if the 3384 two do not match. If the From header, including any tag value, 3385 matches the value for an existing call leg, the server compares the 3386 CSeq header field value. If less than or equal to the current 3387 sequence number, the request is a retransmission. Otherwise, it is a 3388 new request. If the From header does not match an existing call leg, 3389 a new call leg is created. 3391 If the Call-ID was not found, a new call leg is created, with entries 3392 for the To, From and Call-ID headers. In this case, the To header 3393 field should not have contained a tag. The server returns a response 3394 containing the same To value, but with a unique tag added. The tag 3395 MAY be omitted if the To refers to a fully qualified host name. 3397 10.1.2 Responses 3399 A server MAY issue one or more provisional responses at any time 3400 before sending a final response. If a stateful proxy, user agent 3401 server, redirect server or registrar cannot respond to a request with 3402 a final response within 200 ms, it MUST issue a provisional (1xx) 3403 response as soon as possible. Stateless proxies MUST NOT issue 3404 provisional responses on their own. 3406 Responses are mapped to requests by the matching To, From, Call-ID, 3407 CSeq headers and the branch parameter of the first Via header. 3408 Responses terminate request retransmissions even if they have Via 3409 headers that cause them to be delivered to an upstream client. 3411 A stateful proxy may receive a response that it does not have state 3412 for, that is, where it has no a record of an isomorphic request. If 3413 the Via header field indicates that the upstream server used TCP, the 3414 proxy actively opens a TCP connection to that address. Thus, proxies 3415 have to be prepared to receive responses on the incoming side of 3416 passive TCP connections, even though most responses will arrive on 3417 the incoming side of an active connection. (An active connection is a 3418 TCP connection initiated by the proxy, a passive connection is one 3419 accepted by the proxy, but initiated by another entity.) 3421 100 responses are not forwarded, other 1xx responses MAY be 3422 forwarded, possibly after the server eliminates responses with status 3423 codes that had already been sent earlier. 2xx responses are forwarded 3424 according to the Via header. Once a stateful proxy has received a 2xx 3425 response, it MUST NOT forward non-2xx final responses. Responses 3426 with status 300 and higher are retransmitted by each stateful proxy 3427 until the next upstream proxy sends an ACK (see below for timing 3428 details) or CANCEL. 3430 A stateful proxy can remove state for a call attempt and close any 3431 connections 20 seconds after receiving the first final response. 3433 The 20 second window is given by the maximum retransmission 3434 duration of 200 responses (10 times T4), in case the ACK is 3435 lost somewhere on the way to the called user agent or the 3436 next stateful proxy. 3438 10.2 Source Addresses, Destination Addresses and Connections 3440 10.2.1 Unicast UDP 3442 Responses are returned to the address listed in the Via header field 3443 (Section 6.40), not the source address of the request. 3445 10.2.2 Multicast UDP 3447 Requests MAY be multicast; multicast requests likely feature a host- 3448 independent Request-URI. Multicast requests SHOULD have a time-to- 3449 live value of no greater than one, i.e., be restricted to the local 3450 network. 3452 A client receiving a multicast query does not have to check whether 3453 the host part of the Request-URI matches its own host or domain name. 3454 If the request was received via multicast, the response is also 3455 returned via multicast. Responses to multicast requests are multicast 3456 with the same TTL as the request, where the TTL is derived from the 3457 ttl parameter in the Via header (Section 6.40). 3459 To avoid response implosion, servers MUST NOT answer multicast 3460 requests with a status code other than 2xx or 6xx. Servers only 3461 return 6xx responses if the To represents a single individual rather 3462 than a group of people. The server delays its response by a random 3463 interval between zero and one second. Servers MAY suppress responses 3464 if they hear a lower-numbered or 6xx response from another group 3465 member prior to sending. Servers do not respond to CANCEL requests 3466 received via multicast to avoid request implosion. A proxy or UAC 3467 SHOULD send a CANCEL on receiving the first 2xx or 6xx response to a 3468 multicast request. 3470 Server response suppression is a MAY since it requires a 3471 server to violate some basic message processing rules. Lets 3472 say A sends a multicast request, and it is received by B,C, 3473 and D. B sends a 200 response. The topmost Via field in the 3474 response will contain the address of A. C will also receive 3475 this response, and could use it to suppress its own 3476 response. However, C would normally not examine this 3477 response, as the topmost Via is not its own. Normally, a 3478 response received with an incorrect topmost Via MUST be 3479 dropped, but not in this case. To distinguish this packet 3480 from a misrouted or multicast looped packet is fairly 3481 complex, and for this reason the procedure is a MAY. The 3482 CANCEL, instead, provides a simpler and more standard way 3483 to perform response suppression. It is for this reason that 3484 the use of CANCEL here is a SHOULD 3486 10.3 TCP 3488 A single TCP connection can serve one or more SIP transactions. A 3489 transaction contains zero or more provisional responses followed by 3490 one or more final responses. (Typically, transactions contain exactly 3491 one final response, but there are exceptional circumstances, where, 3492 for example, multiple 200 responses can be generated.) 3494 The client MAY close the connection at any time, but SHOULD keep the 3495 connection open at least until the first final response arrives. The 3496 server SHOULD NOT close the TCP connection until it has sent its 3497 final response, at which point it MAY close the TCP connection if it 3498 wishes to. However, normally it is the client's responsibility to 3499 close the connection. 3501 If the server leaves the connection open, and if the client so 3502 desires it MAY re-use the connection for further SIP requests or for 3503 requests from the same family of protocols (such as HTTP or stream 3504 control commands). 3506 If a client closes a connection or the connection is reset (e.g., 3507 because the client has crashed and rebooted), the server treats this 3508 as equivalent to having received a CANCEL request for all pending 3509 transactions. 3511 If a server needs to return a response to a client and no longer has 3512 a connection open to that client, it MAY open a connection to the 3513 address listed in the Via header. Thus, a proxy or user agent MUST be 3514 prepared to receive both requests and responses on a "passive" 3515 connection. 3517 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER Requests 3519 10.4.1 UDP 3521 A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or 3522 REGISTER request periodically with timer T1 until it receives a 3523 response, or until it has reached a set limit on the number of 3524 retransmissions. If the response is provisional, the client continues 3525 to retransmit the request, albeit less frequently, using timer T2. 3526 The default values of timer T1 and T2 are 1 and 5 seconds, 3527 respectively. The default retransmit limit is 20 times. After the 3528 server sends a final response, it cannot be sure the client has 3529 received the response, and thus SHOULD cache the results for at least 3530 100 seconds to avoid having to, for example, contact the user or 3531 location server again upon receiving a retransmission. 3533 Each server in a proxy chain generates its own final response to a 3534 CANCEL request. The server responds immediately upon receipt of the 3535 CANCEL request rather than not waiting until it has received final 3536 responses from the CANCEL requests it generates. 3538 BYE and OPTIONS final responses are generated by redirect and user 3539 agent servers; REGISTER final responses are generated by registrars. 3540 Note that in contrast to the reliability mechanism described in 3541 Section 10.5, responses to these requests are not retransmitted and 3542 not acknowledged via ACK. 3544 The value of the initial retransmission timer is smaller 3545 than that that for TCP since it is expected that network 3546 paths suitable for interactive communications have round- 3547 trip times smaller than 1 second. To avoid flooding the 3548 network with packets every second even if the destination 3549 network is unreachable, the retransmission count has to be 3550 bounded. Given that most transactions are expected to 3551 consist of one request and a few responses, round-trip time 3552 estimation is not likely to be very useful. If RTT 3553 estimation is desired to more quickly discover a missing 3554 final response, each request retransmission needs to be 3555 labeled with its own Timestamp (Section 6.36), returned in 3556 the response. The server caches the result until it can be 3557 sure that the client will not retransmit the same request 3558 again. 3560 10.4.2 TCP 3562 Clients using TCP do not need to retransmit requests. 3564 10.5 Reliability for INVITE Requests 3566 Special considerations apply for the INVITE method. 3568 1. After receiving an invitation, considerable time can elapse 3569 before the server can determine the outcome. For example, 3570 if the called party is "rung" or extensive searches are 3571 performed, delays between the request and a definitive 3572 response can reach several tens of seconds. If either 3573 caller or callee are automated servers not directly 3574 controlled by a human being, a call attempt could be 3575 unbounded in time. 3577 2. If a telephony user interface is modeled or if we need to 3578 interface to the PSTN, the caller's user interface will 3579 provide "ringback", a signal that the callee is being 3580 alerted. (The status response 180 (Ringing) MAY be used to 3581 initiate ringback.) Once the callee picks up, the caller 3582 needs to know so that it can enable the voice path and stop 3583 ringback. The callee's response to the invitation could get 3584 lost. Unless the response is transmitted reliably, the 3585 caller will continue to hear ringback while the callee 3586 assumes that the call exists. 3588 3. The client has to be able to terminate an on-going request, 3589 e.g., because it is no longer willing to wait for the 3590 connection or search to succeed. The server will have to 3591 wait several round-trip times to interpret the lack of 3592 request retransmissions as the end of a call. If the call 3593 succeeds shortly after the caller has given up, the callee 3594 will "pick up the phone" and not be "connected". 3596 10.5.1 UDP 3598 For UDP, A SIP client SHOULD retransmit a SIP INVITE request 3599 periodically with timer T1 until it receives a response. If the 3600 client receives no response, it ceases retransmission after 20 3601 attempts. If the response is provisional, the client continues to 3602 retransmit the request, albeit less frequently, using timer T3. The 3603 default values of timer T1 and T3 are 1 and 30 seconds, respectively. 3605 The value of T3 was chosen so that for most normal phone 3606 calls, only one INVITE request will be issued. Typically, a 3607 phone switches to an answering machine or voice mail after 3608 about 20--22 seconds. The number of retransmissions after 3609 receiving a provisional response is unlimited to allow call 3610 queueing. Clients MAY limit the number of invitations sent 3611 for each call attempt. 3613 Only the user agent client generates an ACK for 2xx final responses, 3614 If the response contained a Contact header field, the ACK MAY be sent 3615 to the address listed in that Contact header field. If the response 3616 did not contain a Contact header, the client uses the same To header 3617 field and Request-URI as for the INVITE request and sends the ACK to 3618 the same destination as the original INVITE request. ACKs for final 3619 responses other than 2xx are sent to the same server that the 3620 original request was sent to, using the same Request-URI as the 3621 original request. Note, however, that the To header field in the ACK 3622 is copied from the response being acknowledged, not the request, and 3623 thus MAY additionally contain the tag parameter. Also note than 3624 unlike 2xx final responses, a proxy generates an ACK for non-2xx 3625 final responses. 3627 The server retransmits the final response at intervals of T4 (default 3628 value of T4 = 2 seconds) until one of the following conditions is 3629 true: 3631 1. An ACK request for the same transaction is received; 3633 2. a BYE request for the same call leg is received; 3635 3. a CANCEL request for the same call leg is received and the 3636 final response status was equal or greater to 300; 3638 4. the response has been retransmitted 10 times. 3640 The ACK request MUST NOT be acknowledged to prevent a response-ACK 3641 feedback loop. Fig. 11 and 12 show the client and server state 3642 diagram for invitations. 3644 The mechanism in Sec. 10.4 would not work well for INVITE 3645 because of the long delays between INVITE and a final 3646 +===========+ 3647 * * 3648 ...........>* Initial *<;;;;;;;;;; 3649 : 20*T1 * * ; 3650 : +===========+ ; 3651 : | ; 3652 : | - ; 3653 : | INVITE ; 3654 : | ; 3655 : v ; 3656 : ************* ; 3657 : T1 <--* * ; 3658 : INVITE -->* Calling *--------+ ; 3659 : * * | ; 3660 : ************* | ; 3661 : : | | ; 3662 :.............: | 1xx xxx | ; 3663 | - ACK | ; 3664 | | ; 3665 v | ; 3666 ************* | ; 3667 T3 <--* * | ; 3668 INVITE -->* Ringing *<->1xx | ; 3669 * * | ; 3670 ************* | ; 3671 | | ; 3672 |<-------------+ ; 3673 | ; 3674 v ; 3675 ************* ; 3676 xxx <--* * ; 3677 ACK -->* Completed * ; 3678 * * ; 3679 ************* ; 3680 ; 10*T4 ; 3681 ;;;;;;;;;;;;;;;;;; 3683 event (xxx=status) 3684 message 3686 Figure 11: State transition diagram of client for INVITE method 3688 response. If the 200 response were to get lost, the callee 3689 would believe the call to exist, but the voice path would 3690 be dead since the caller does not know that the callee has 3692 10*T4 +===============+ 3693 +-------------->* * 3694 | * Initial *<............... 3695 |;;;;;;;;;;;;;;>* * 3696 |; +===============+ : 3697 |; CANCEL ! : 3698 |; 200 ! : 3699 |; ! INVITE : 3700 |; ! 1xx : 3701 |; ! : 3702 |; v : 3703 |; ***************** BYE : 3704 |; INVITE -->* * 200 : 3705 |; 1xx <--* Call proceed. *..............>: 3706 |; * * : 3707 |;;;;;;;;;;;;;;;***************** : 3708 |; ! ! : 3709 |: ! ! : 3710 |; failure ! ! picks up : 3711 |; >= 300 ! ! 200 : 3712 |; +-------+ +-------+ : 3713 |; v v : 3714 |; *********** *********** : 3715 |;INVITE<* *< T4 ->* *>INVITE : 3716 |;status>* failure *>status<-* success *: 3723 ! ! BYE : 3724 +---------+---------+ 200 : 3725 ! ACK : 3726 ! : 3727 v : 3728 ***************** : 3729 V---* * : 3730 ACK * Confirmed * : 3731 |-->* * : 3732 ***************** . 3733 : : 3734 :......................>: 3735 event 3736 message sent 3738 Figure 12: State transition diagram of server for INVITE method 3739 picked up. Thus, the INVITE retransmission interval would 3740 have to be on the order of a second or two to limit the 3741 duration of this state confusion. Retransmitting the 3742 response a fixed number of times increases the probability 3743 of success, but at the cost of significantly higher 3744 processing and network load. 3746 10.5.2 TCP 3748 A client using TCP MUST NOT retransmit requests, but uses the same 3749 algorithm as for UDP (Section 10.5.1) to retransmit responses until 3750 it receives an ACK. (An implementation can simply set T1 and T3 to 3751 infinity and otherwise maintain the same state diagram.) 3753 It is necessary to retransmit 2xx responses as their 3754 reliability is assured end-to-end only. If the chain of 3755 proxies has a UDP link in the middle, it could lose the 3756 response, with no possibility of recovery. For simplicity, 3757 we also retransmit non-2xx responses, although that is not 3758 strictly necessary. 3760 10.6 Reliability for ACK Requests 3762 The ACK request does not generate responses. It is only generated 3763 when a response to an INVITE request arrives (see Section 10.5). This 3764 behavior is independent of the transport protocol. Note that the ACK 3765 request MAY take a different path than the original INVITE request, 3766 and MAY even cause a new TCP connection to be opened in order to send 3767 it. 3769 11 Behavior of SIP User Agents 3771 This section describes the rules for user agent client and servers 3772 for generating and processing requests and responses. 3774 11.1 Caller Issues Initial INVITE Request 3776 When a user agent client desires to initiate a call, it formulates an 3777 INVITE request. The To field in the request contains the address of 3778 the callee. The Request-URI contains the same address. The From field 3779 contains the address of the caller. If the From address can appear 3780 in requests generated by other user agent clients for the same call, 3781 the caller MUST insert the tag parameter in the From field. A UAC MAY 3782 optionally add a Contact header containing an address where it would 3783 like to be contacted for transactions from the callee back to the 3784 caller. 3786 11.2 Callee Issues Response 3788 When the initial INVITE request is received at the callee, the callee 3789 can accept, redirect, or reject the call. In all of these cases, it 3790 formulates a response. The response MUST copy the To, From, Call-ID, 3791 CSeq and Via fields from the request. Additionally, the responding 3792 UAS MUST add the tag parameter to the To field in the response if the 3793 To field in the request was not the fully-qualified hostname of the 3794 UAS. Since a request from a UAC may fork and arrive at multiple 3795 hosts, the tag parameter serves to distinguish, at the UAC, multiple 3796 responses from different UAS's. The UAS MAY add a Contact header 3797 field in the response. It contains an address where the callee would 3798 like to be contacted for subsequent transactions, including the ACK 3799 for the current INVITE. The UAS stores the values of the To and From 3800 field, including any tags. These become the local and remote 3801 addresses of the call leg, respectively. 3803 11.3 Caller Receives Response to Initial Request 3805 Multiple responses may arrive at the UAC for a single INVITE request, 3806 due to a forking proxy. Each response is distinguished by the "tag" 3807 parameter in the To header field, and each represents a distinct call 3808 leg. The caller MAY choose to acknowledge or terminate the call with 3809 each responding UAS. To acknowledge, it sends an ACK request, and to 3810 terminate it sends a BYE request. The To header field in the ACK or 3811 BYE MUST be the same as the To field in the 200 response, including 3812 any tag. The From header field MUST be the same as the From header 3813 field in the 200 (OK) response, including any tag. The Request-URI of 3814 the ACK or BYE request MAY be set to whatever address was found in 3815 the Contact header field in the 200 (OK) response, if present. 3816 Alternately, a UAC may copy the address from the To header field into 3817 the Request-URI. The UAC also notes the value of the To and From 3818 header fields in each response. For each call leg, the To header 3819 field becomes the remote address, and the From header field becomes 3820 the local address. 3822 11.4 Caller or Callee Generate Subsequent Requests 3824 Once the call has been established, either the caller or callee MAY 3825 generate INVITE or BYE requests to change or terminate the call. 3826 Regardless of whether the caller or callee is generating the new 3827 request, the header fields in the request are set as follows. For the 3828 desired call leg, the To header field is set to the remote address, 3829 and the From header field is set to the local address (both including 3830 any tags). The Contact header field MAY be different than the Contact 3831 header field sent in a previous response or request. The Request-URI 3832 MAY be set to the value of the Contact header field received in a 3833 previous request or response from the remote party, or to the value 3834 of the remote address. 3836 11.5 Receiving Subsequent Requests 3838 When a request is received subsequently, the following checks are 3839 made: 3841 1. If the Call-ID is new, the request is for a new call, 3842 regardless of the values of the To and From header fields. 3844 2. If the Call-ID exists, the request is for an existing call. 3845 If the To, From, Call-ID, and CSeq values exactly match 3846 (including tags) those of any requests received previously, 3847 the request is a retransmission. 3849 3. If there was no match to the previous step, the To and From 3850 fields are compared against existing call leg local and 3851 remote addresses. If there is a match, and the CSeq in the 3852 request is higher than the last CSeq received on that leg, 3853 the request is a new transaction for an existing call leg. 3855 12 Behavior of SIP Proxy and Redirect Servers 3857 This section describes behavior of SIP redirect and proxy servers in 3858 detail. Proxy servers can "fork" connections, i.e., a single incoming 3859 request spawns several outgoing (client) requests. 3861 12.1 Redirect Server 3863 A redirect server does not issue any SIP requests of its own. After 3864 receiving a request, the server gathers the list of alternative 3865 locations and returns a final response of class 3xx or it refuses the 3866 request. For CANCEL requests, it SHOULD also return a 2xx response. 3867 This response ends the SIP transaction. The redirect server maintains 3868 transaction state for the whole SIP transaction. It is up to the 3869 client to detect forwarding loops between redirect servers. 3871 12.2 User Agent Server 3873 User agent servers behave similarly to redirect servers, except that 3874 they also accept requests and can return a response of class 2xx. 3876 12.3 Proxy Server 3878 This section outlines processing rules for proxy servers. A proxy 3879 server can either be stateful or stateless. When stateful, a proxy 3880 remembers the incoming request which generated outgoing requests, and 3881 the outgoing requests. A stateless proxy forgets all information once 3882 an outgoing request is generated. A forking proxy SHOULD be stateful. 3883 A stateful proxy MAY become stateless at any time, but SHOULD remain 3884 stateful until it sends a definitive response upstream. 3886 A stateful proxy acts as a virtual UAS/UAC. It implements the server 3887 state machine when receiving requests, and the client state machine 3888 for generating outgoing requests, with the exception of receiving a 3889 2xx response to an INVITE. Instead of generating an ACK, the 2xx 3890 response is always forwarded upstream towards the caller. 3891 Furthermore, ACK's for 200 responses to INVITE's are always proxied 3892 downstream towards the UAS, as they would be for a stateless proxy. 3894 A stateless proxy does not act as a virtual UAS/UAC (as this would 3895 require state). Rather, a stateless proxy forwards every request it 3896 receives downstream, and every response it receives upstream. 3898 12.3.1 Proxying Requests 3900 To prevent loops, a server MUST check if its own address is already 3901 contained in the Via header field of the incoming request. 3903 The To, From, Call-ID, and Contact tags are copied exactly from the 3904 original request. The proxy SHOULD change the Request-URI to indicate 3905 the server where it intends to send the request. 3907 A proxy server always inserts a Via header field containing its own 3908 address into those requests that are caused by an incoming request. 3909 Each proxy MUST insert a "branch" parameter (Section 6.40). 3911 12.3.2 Proxying Responses 3913 A proxy only processes a response if the topmost Via field matches 3914 one of its addresses. A response with a non-matching top Via field 3915 MUST be dropped. 3917 12.3.3 Stateless Proxy: Proxying Responses 3919 A stateless proxy removes its own Via field, and checks the address 3920 in the next Via field. If the field indicates TCP as the transport 3921 protocol, the proxy checks to see if it has a connection currently 3922 open to that address. If so, the response is sent on that connection. 3923 Otherwise, a new TCP connection is opened to the address and port in 3924 the Via field, and the response is sent there. In the case of UDP, 3925 the response is sent to the address listed in the "maddr" tag if 3926 present, otherwise to the "received" tag if present, and finally to 3927 the address in the "sent-by" field. Note that this implies that a UAC 3928 or proxy MUST be prepared to receive responses on the incoming side 3929 of a TCP connection. 3931 A stateless proxy MUST NOT generate its own provisional responses. 3933 12.3.4 Stateful Proxy: Receiving Requests 3935 When a stateful proxy receives a request, it checks the To, From 3936 (including tags), Call-ID and CSeq against existing request records. 3937 If the tuple exists, the request is a retransmission. The provisional 3938 or final response sent previously is retransmitted, as per the server 3939 state machine. If the tuple does not exist, the request corresponds 3940 to a new transaction, and the request should be proxied. 3942 A stateful proxy server MAY generate its own provisional (1xx) 3943 responses. 3945 12.3.5 Stateful Proxy: Receiving ACKs 3947 When an ACK request is received, it is either processed locally or 3948 proxied. To make this determination, the To, From, CSeq and Call-ID 3949 fields are compared against those in previous requests. If there is 3950 no match, the ACK request is proxied as if it were an INVITE request. 3951 If there is a match, and if the server had ever sent a 200 response 3952 upstream, the ACK is proxied. If the server had never sent any 3953 responses upstream, the ACK is also proxied. If the server had sent a 3954 3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is 3955 processed locally, as it is acknowledging the response generated by 3956 the proxy. 3958 12.3.6 Stateful Proxy: Receiving Responses 3960 When a proxy server receives a response that has passed the Via 3961 checks, the proxy server checks the To (without the tag), From 3962 (including the tag), Call-ID and CSeq against values seen in previous 3963 requests. If there is no match, the response is forwarded upstream to 3964 the address listed in the Via field. If there is a match, the 3965 "branch" tag in the Via field is examined. If it matches a known 3966 branch identifier, the response is for the given branch, and 3967 processed by the virtual client for the given branch. Otherwise, the 3968 response is dropped. 3970 A stateful proxy should obey the rules in Section 12.4 to determine 3971 if the response should be proxied upstream. If it is to be proxied, 3972 the same rules for stateless proxies above are followed. 3974 12.3.7 Stateless, Non-Forking Proxy 3976 Proxies in this category issue at most a single unicast request for 3977 each incoming SIP request, that is, they do not "fork" requests. 3978 However, servers MAY choose to always operate in a mode that allows 3979 issuing of several requests, as described in Section 12.4. 3981 The server can forward the request and any responses. It does not 3982 have to maintain any state for the SIP transaction. Reliability is 3983 assured by the next redirect or stateful proxy server in the server 3984 chain. 3986 A proxy server SHOULD cache the result of any address translations 3987 and the response to speed forwarding of retransmissions. After the 3988 cache entry has been expired, the server cannot tell whether an 3989 incoming request is actually a retransmission of an older request. 3990 The server will treat it as a new request and commence another 3991 search. 3993 12.4 Forking Proxy 3995 The server MUST respond to the request immediately with a 100 3996 (Trying) response. 3998 Successful responses to an INVITE request SHOULD contain a Contact 3999 header field so that the following ACK or BYE bypasses the proxy 4000 search mechanism. If the proxy requires future requests to be routed 4001 through it, it adds a Record-Route header to the request (Section 4002 6.29). 4004 The following pseudo-code describes the behavior of a proxy server 4005 issuing several requests in response to an incoming INVITE request. 4006 The function request(r, a, b) sends a SIP request of type r to 4007 address a, with branch id b. await_response() waits until a response 4008 is received and returns the response. close(a) closes the TCP 4009 connection to client with address a. response(r) sends a response to 4010 the client. ismulticast() returns 1 if the location is a multicast 4011 address and zero otherwise. The variable timeleft indicates the 4012 amount of time left until the maximum response time has expired. The 4013 variable recurse indicates whether the server will recursively try 4014 addresses returned through a 3xx response. A server MAY decide to 4015 recursively try only certain addresses, e.g., those which are within 4016 the same domain as the proxy server. Thus, an initial multicast 4017 request can trigger additional unicast requests. 4019 /* request type */ 4020 typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method; 4022 process_request(Method R, int N, address_t address[]) 4023 { 4024 struct { 4025 address_t address; /* address */ 4026 int branch; /* branch id */ 4027 int done; /* has responded */ 4028 } outgoing[]; 4029 int done[]; /* address has responded */ 4030 char *location[]; /* list of locations */ 4031 int heard = 0; /* number of sites heard from */ 4032 int class; /* class of status code */ 4033 int timeleft = 120; /* sample timeout value */ 4034 int loc = 0; /* number of locations */ 4035 struct { /* response */ 4036 int status; /* response: CANCEL=-1 */ 4037 int locations; /* number of redirect locations */ 4038 char *location[]; /* redirect locations */ 4039 address_t a; /* address of respondent */ 4040 int branch; /* branch identifier */ 4041 } r, best; /* response, best response */ 4042 int i; 4044 best.status = 1000; 4045 for (i = 0; i < N; i++) { 4046 request(R, address[i], i); 4047 outgoing[i].done = 0; 4048 outgoing[i].branch = i; 4049 } 4051 while (timeleft > 0 && heard < N) { 4052 r = await_response(); 4053 class = r.status / 100; 4055 /* If final response, mark branch as done. */ 4056 if (class >= 2) { 4057 heard++; 4058 for (i = 0; i < N; i++) { 4059 if (r.branch == outgoing[i].branch) { 4060 outgoing[i].done = 1; 4061 break; 4062 } 4063 } 4064 } 4065 /* CANCEL: respond, fork and wait for responses */ 4066 else if (class < 0) { 4067 best.status = 200; 4068 response(best); 4069 for (i = 0; i < N; i++) { 4070 request(CANCEL, address[i], outgoing[i].branch); 4071 } 4072 best.status = -1; 4073 } 4074 if (class == 2) { 4075 if (r.status < best) best = r; 4076 break; 4077 } 4078 else if (class == 3) { 4079 /* A server MAY optionally recurse. The server MUST check 4080 * whether it has tried this location before and whether the 4081 * location is part of the Via path of the incoming request. 4082 * This check is omitted here for brevity. Multicast locations 4083 * MUST NOT be returned to the client if the server is not 4084 * recursing. 4085 */ 4086 if (recurse) { 4087 multicast = 0; 4088 N += r.locations; 4089 for (i = 0; i < r.locations; i++) { 4090 request(R, r.location[i]); 4091 } 4092 } else if (!ismulticast(r.location)) { 4093 best = r; 4094 } 4095 if (R == INVITE) request(ACK, r.a, r.branch); 4096 } 4097 else if (class == 4) { 4098 if (R == INVITE) request(ACK, r.a, r.branch); 4099 if (best.status >= 400) best = r; 4100 } 4101 else if (class == 5) { 4102 if (R == INVITE) request(ACK, r.a, r.branch); 4103 if (best.status >= 500) best = r; 4104 } 4105 else if (class == 6) { 4106 if (R == INVITE) request(ACK, r.a, r.branch); 4107 best = r; 4108 break; 4109 } 4110 } 4112 /* We haven't heard anything useful from anybody. */ 4113 if (best.status == 1000) { 4114 best.status = 404; 4115 } 4116 if (best.status/100 != 3) loc = 0; 4117 response(best); 4118 } 4120 Responses are processed as follows. The process completes (and state 4121 can be freed) when all requests have been answered by final status 4122 responses (for unicast) or 60 seconds have elapsed (for multicast). A 4123 proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to 4124 the client after 60 seconds or more. 4126 1xx: The proxy MAY forward the response upstream towards the client. 4128 2xx: The proxy MUST forward the response upstream towards the client, 4129 without sending an ACK downstream. After receiving a 2xx, the 4130 server MAY terminate all other pending requests by sending a 4131 CANCEL request and closing the TCP connection, if applicable. 4132 (Terminating pending requests is advisable as searches consume 4133 resources. Also, INVITE requests could "ring" on a number of 4134 workstations if the callee is currently logged in more than 4135 once.) 4137 3xx: The proxy MUST send an ACK and MAY recurse on the listed Contact 4138 addresses. Otherwise, the lowest-numbered response is returned 4139 if there were no 2xx responses. 4141 Location lists are not merged as that would prevent 4142 forwarding of authenticated responses. Also, responses can 4143 have message bodies, so that merging is not feasible. 4145 4xx, 5xx: The proxy MUST send an ACK and remember the response if it 4146 has a lower status code than any previous 4xx and 5xx responses. 4147 On completion, the lowest-numbered response is returned if there 4148 were no 2xx or 3xx responses. 4150 6xx: The proxy MUST forward the response to the client and send an 4151 ACK. Other pending requests MAY be terminated with CANCEL as 4152 described for 2xx responses. 4154 A proxy server forwards any response for Call-IDs for which it does 4155 not have a pending transaction according to the response's Via 4156 header. User agent servers respond to BYE requests for unknown call 4157 legs with status code 481 (Transaction Does Not Exist); they drop ACK 4158 requests with unknown call legs silently. 4160 Special considerations apply for choosing forwarding destinations for 4161 ACK and BYE requests. In most cases, these requests will bypass 4162 proxies and reach the desired party directly, keeping proxies from 4163 having to make forwarding decisions. 4165 A proxy MAY maintain call state for a period of its choosing. If a 4166 proxy still has list of destinations that it forwarded the last 4167 INVITE to, it SHOULD direct ACK requests only to those downstream 4168 servers. 4170 13 Security Considerations 4172 13.1 Confidentiality and Privacy: Encryption 4174 13.1.1 End-to-End Encryption 4176 SIP requests and responses can contain sensitive information about 4177 the communication patterns and communication content of individuals. 4178 The SIP message body MAY also contain encryption keys for the session 4179 itself. SIP supports three complementary forms of encryption to 4180 protect privacy: 4182 o End-to-end encryption of the SIP message body and certain 4183 sensitive header fields; 4185 o hop-by-hop encryption to prevent eavesdropping that tracks who 4186 is calling whom; 4188 o hop-by-hop encryption of Via fields to hide the route a 4189 request has taken. 4191 Not all of the SIP request or response can be encrypted end-to-end 4192 because header fields such as To and Via need to be visible to 4193 proxies so that the SIP request can be routed correctly. Hop-by-hop 4194 encryption encrypts the entire SIP request or response on the wire so 4195 that packet sniffers or other eavesdroppers cannot see who is calling 4196 whom. Hop-by-hop encryption can also encrypt requests and responses 4197 that have been end-to-end encrypted. Note that proxies can still see 4198 who is calling whom, and this information is also deducible by 4199 performing a network traffic analysis, so this provides a very 4200 limited but still worthwhile degree of protection. 4202 SIP Via fields are used to route a response back along the path taken 4203 by the request and to prevent infinite request loops. However, the 4204 information given by them can also provide useful information to an 4205 attacker. Section 6.22 describes how a sender can request that Via 4206 fields be encrypted by cooperating proxies without compromising the 4207 purpose of the Via field. 4209 End-to-end encryption relies on keys shared by the two user agents 4210 involved in the request. Typically, the message is sent encrypted 4211 with the public key of the recipient, so that only that recipient can 4212 read the message. All implementations SHOULD support PGP-based 4213 encryption and MAY implement other schemes. 4215 A SIP request (or response) is end-to-end encrypted by splitting the 4216 message to be sent into a part to be encrypted and a short header 4217 that will remain in the clear. Some parts of the SIP message, namely 4218 the request line, the response line and certain header fields marked 4219 with "n" in the "enc." column in Table 4 and 5 need to be read and 4220 returned by proxies and thus MUST NOT be encrypted end-to-end. 4221 Possibly sensitive information that needs to be made available as 4222 plaintext include destination address (To) and the forwarding path 4223 (Via) of the call. The Authorization header field MUST remain in the 4224 clear if it contains a digital signature as the signature is 4225 generated after encryption, but MAY be encrypted if it contains 4226 "basic" or "digest" authentication. The From header field SHOULD 4227 normally remain in the clear, but MAY be encrypted if required, in 4228 which case some proxies MAY return a 401 (Unauthorized) status if 4229 they require a From field. 4231 Other header fields MAY be encrypted or MAY travel in the clear as 4232 desired by the sender. The Subject, Allow, Call-ID, and Content-Type 4233 header fields will typically be encrypted. The Accept, Accept- 4234 Language, Date, Expires, Priority, Require, Cseq, and Timestamp 4235 header fields will remain in the clear. 4237 All fields that will remain in the clear MUST precede those that will 4238 be encrypted. The message is encrypted starting with the first 4239 character of the first header field that will be encrypted and 4240 continuing through to the end of the message body. If no header 4241 fields are to be encrypted, encrypting starts with the second CRLF 4242 pair after the last header field, as shown below. Carriage return and 4243 line feed characters have been made visible as "$", and the encrypted 4244 part of the message is outlined. 4246 INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ 4247 Via: SIP/2.0/UDP 169.130.12.5$ 4248 To: T. A. Watson $ 4249 From: A. Bell $ 4250 Encryption: PGP version=5.0$ 4251 Content-Length: 224$ 4252 CSeq: 488$ 4253 $ 4254 ******************************************************* 4255 * Call-ID: 187602141351@worcester.bell-telephone.com$ * 4256 * Subject: Mr. Watson, come here.$ * 4257 * Content-Type: application/sdp$ * 4258 * $ * 4259 * v=0$ * 4260 * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * 4261 * c=IN IP4 135.180.144.94$ * 4262 * m=audio 3456 RTP/AVP 0 3 4 5$ * 4263 ******************************************************* 4265 An Encryption header field MUST be added to indicate the encryption 4266 mechanism used. A Content-Length field is added that indicates the 4267 length of the encrypted body. The encrypted body is preceded by a 4268 blank line as a normal SIP message body would be. 4270 Upon receipt by the called user agent possessing the correct 4271 decryption key, the message body as indicated by the Content-Length 4272 field is decrypted, and the now-decrypted body is appended to the 4273 clear-text header fields. There is no need for an additional 4274 Content-Length header field within the encrypted body because the 4275 length of the actual message body is unambiguous after decryption. 4277 Had no SIP header fields required encryption, the message would have 4278 been as below. Note that the encrypted body MUST then include a blank 4279 line (start with CRLF) to disambiguate between any possible SIP 4280 header fields that might have been present and the SIP message body. 4282 INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ 4283 Via: SIP/2.0/UDP 169.130.12.5$ 4284 To: T. A. Watson $ 4285 From: A. Bell $ 4286 Encryption: PGP version=5.0$ 4287 Content-Type: application/sdp$ 4288 Content-Length: 107$ 4289 $ 4290 ************************************************* 4291 * $ * 4292 * v=0$ * 4293 * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * 4294 * c=IN IP4 135.180.144.94$ * 4295 * m=audio 3456 RTP/AVP 0 3 4 5$ * 4296 ************************************************* 4298 13.1.2 Privacy of SIP Responses 4300 SIP requests can be sent securely using end-to-end encryption and 4301 authentication to a called user agent that sends an insecure 4302 response. This is allowed by the SIP security model, but is not a 4303 good idea. However, unless the correct behaviour is explicit, it 4304 would not always be possible for the called user agent to infer what 4305 a reasonable behaviour was. Thus when end-to-end encryption is used 4306 by the request originator, the encryption key to be used for the 4307 response SHOULD be specified in the request. If this were not done, 4308 it might be possible for the called user agent to incorrectly infer 4309 an appropriate key to use in the response. Thus, to prevent key- 4310 guessing becoming an acceptable strategy, we specify that a called 4311 user agent receiving a request that does not specify a key to be used 4312 for the response SHOULD send that response unencrypted. 4314 Any SIP header fields that were encrypted in a request SHOULD also be 4315 encrypted in an encrypted response. Contact response fields MAY be 4316 encrypted if the information they contain is sensitive, or MAY be 4317 left in the clear to permit proxies more scope for localized 4318 searches. 4320 13.1.3 Encryption by Proxies 4322 Normally, proxies are not allowed to alter end-to-end header fields 4323 and message bodies. Proxies MAY, however, encrypt an unsigned request 4324 or response with the key of the call recipient. 4326 Proxies need to encrypt a SIP request if the end system 4327 cannot perform encryption or to enforce organizational 4328 security policies. 4330 13.1.4 Hop-by-Hop Encryption 4332 It is RECOMMENDED that SIP requests and responses are also protected 4333 by security mechanisms at the transport and network layer. 4335 13.1.5 Via field encryption 4337 When Via fields are to be hidden, a proxy that receives a request 4338 containing an appropriate "Hide: hop" header field (as specified in 4339 section 6.22) SHOULD encrypt the header field. As only the proxy that 4340 encrypts the field will decrypt it, the algorithm chosen is entirely 4341 up to the proxy implementor. Two methods satisfy these requirements: 4343 o The server keeps a cache of Via fields and the associated To 4344 field, and replaces the Via field with an index into the 4345 cache. On the reverse path, take the Via field from the cache 4346 rather than the message. 4348 This is insufficient to prevent message looping, and so an 4349 additional ID MUST be added so that the proxy can detect loops. 4350 This SHOULD NOT normally be the address of the proxy as the goal 4351 is to hide the route, so instead a sufficiently large random 4352 number SHOULD be used by the proxy and maintained in the cache. 4354 It is possible for replies to get directed to the wrong 4355 originator if the cache entry gets reused, so great care needs 4356 to be taken to ensure this does not happen. 4358 o The server MAY use a secret key to encrypt the Via field, a 4359 timestamp and an appropriate checksum in any such message with 4360 the same secret key. The checksum is needed to detect whether 4361 successful decoding has occurred, and the timestamp is 4362 required to prevent possible response attacks and to ensure 4363 that no two requests from the same previous hop have the same 4364 encrypted Via field. This is the preferred solution. 4366 13.2 Message Integrity and Access Control: Authentication 4368 Protective measures need to be taken to prevent an active attacker 4369 from modifying and replaying SIP requests and responses. The same 4370 cryptographic measures that are used to ensure the authenticity of 4371 the SIP message also serve to authenticate the originator of the 4372 message. However, the "basic" and "digest" authentication mechanism 4373 offer authentication only, without message integrity. 4375 Transport-layer or network-layer authentication MAY be used for hop- 4376 by-hop authentication. SIP also extends the HTTP WWW-Authenticate 4377 (Section 6.42) and Authorization (Section 6.11) header field and 4378 their Proxy counterparts to include cryptographically strong 4379 signatures. SIP also supports the HTTP "basic" and "digest" schemes 4380 and other HTTP authentication schemes to be defined that offer a 4381 rudimentary mechanism of ascertaining the identity of the caller. 4383 Since SIP requests are often sent to parties with which no 4384 prior communication relationship has existed, we do not 4385 specify authentication based on shared secrets. 4387 SIP requests MAY be authenticated using the Authorization header 4388 field to include a digital signature of certain header fields, the 4389 request method and version number and the payload, none of which are 4390 modified between client and called user agent. The Authorization 4391 header field is used in requests to authenticate the request 4392 originator end-to-end to proxies and the called user agent, and in 4393 responses to authenticate the called user agent or proxies returning 4394 their own failure codes. If required, hop-by-hop authentication can 4395 be provided, for example, by the IPSEC Authentication Header. 4397 SIP does not dictate which digital signature scheme is used for 4398 authentication, but does define how to provide authentication using 4399 PGP in Section 14. As indicated above, SIP implementations MAY also 4400 use "basic" and "digest" authentication and other authentication 4401 mechanisms defined for HTTP. Note that "basic" authentication has 4402 severe security limitations. The following does not apply to these 4403 schemes. 4405 To cryptographically sign a SIP request, the order of the SIP header 4406 fields is important. When an Authorization header field is present, 4407 it indicates that all header fields following the Authorization 4408 header field have been included in the signature. Therefore, hop- 4409 by-hop header fields which MUST or SHOULD be modified by proxies MUST 4410 precede the Authorization header field as they will generally be 4411 modified or added-to by proxy servers. Hop-by-hop header fields 4412 which MAY be modified by a proxy MAY appear before or after the 4413 Authorization header. When the appear before, the MAY be modified by 4414 a proxy. When they appear after, they MUST NOT be modified by a 4415 proxy. To sign a request, a client constructs a message from the 4416 request method (in upper case) followed, without LWS, by the SIP 4417 version number, followed, again without LWS, by the request headers 4418 to be signed and the message body. The message thus constructed is 4419 then signed. 4421 For example, if the SIP request is to be: 4423 INVITE sip:watson@boston.bell-telephone.com SIP/2.0 4424 Via: SIP/2.0/UDP 169.130.12.5 4425 Authorization: PGP version=5.0, signature=... 4426 From: A. Bell 4427 To: T. A. Watson 4428 Call-ID: 187602141351@worcester.bell-telephone.com 4429 Subject: Mr. Watson, come here. 4430 Content-Type: application/sdp 4431 Content-Length: ... 4433 v=0 4434 o=bell 53655765 2353687637 IN IP4 128.3.4.5 4435 c=IN IP4 135.180.144.94 4436 m=audio 3456 RTP/AVP 0 3 4 5 4438 Then the data block that is signed is: 4440 INVITESIP/2.0From: A. Bell 4441 To: T. A. Watson 4442 Call-ID: 187602141351@worcester.bell-telephone.com 4443 Subject: Mr. Watson, come here. 4444 Content-Type: application/sdp 4445 Content-Length: ... 4447 v=0 4448 o=bell 53655765 2353687637 IN IP4 128.3.4.5 4449 c=IN IP4 135.180.144.94 4450 m=audio 3456 RTP/AVP 0 3 4 5 4452 Note that if a message is encrypted and authenticated using a digital 4453 signature, when the message is generated encryption is performed 4454 before the digital signature is generated. On receipt, the digital 4455 signature is checked before decryption. 4457 A client MAY require that a server sign its response by including a 4458 Require: org.ietf.sip.signed-response request header field. The 4459 client indicates the desired authentication method via the WWW- 4460 Authenticate header. 4462 The correct behaviour in handling unauthenticated responses to a 4463 request that requires authenticated responses is described in section 4464 13.2.1. 4466 13.2.1 Trusting responses 4468 There is the possibility that an eavesdropper listens to requests and 4469 then injects unauthenticated responses that terminate, redirect or 4470 otherwise interfere with a call. (Even encrypted requests contain 4471 enough information to fake a response.) 4473 Client need to be particularly careful with 3xx redirection 4474 responses. Thus a client receiving, for example, a 301 (Moved 4475 Permanently) which was not authenticated when the public key of the 4476 called user agent is known to the client, and authentication was 4477 requested in the request SHOULD be treated as suspicious. The correct 4478 behaviour in such a case would be for the called-user to form a dated 4479 response containing the Contact field to be used, to sign it, and 4480 give this signed stub response to the proxy that will provide the 4481 redirection. Thus the response can be authenticated correctly. A 4482 client SHOULD NOT automatically redirect such a request to the new 4483 location without alerting the user to the authentication failure 4484 before doing so. 4486 Another problem might be responses such as 6xx failure responses 4487 which would simply terminate a search, or "4xx" and "5xx" response 4488 failures. 4490 If TCP is being used, a proxy SHOULD treat 4xx and 5xx responses as 4491 valid, as they will not terminate a search. However, fake 6xx 4492 responses from a rogue proxy terminate a search incorrectly. 6xx 4493 responses SHOULD be authenticated if requested by the client, and 4494 failure to do so SHOULD cause such a client to ignore the 6xx 4495 response and continue a search. 4497 With UDP, the same problem with 6xx responses exists, but also an 4498 active eavesdropper can generate 4xx and 5xx responses that might 4499 cause a proxy or client to believe a failure occurred when in fact it 4500 did not. Typically 4xx and 5xx responses will not be signed by the 4501 called user agent, and so there is no simple way to detect these 4502 rogue responses. This problem is best prevented by using hop-by-hop 4503 encryption of the SIP request, which removes any additional problems 4504 that UDP might have over TCP. 4506 These attacks are prevented by having the client require response 4507 authentication and dropping unauthenticated responses. A server user 4508 agent that cannot perform response authentication responds using the 4509 normal Require response of 420 (Bad Extension). 4511 13.3 Callee Privacy 4513 User location and SIP-initiated calls can violate a callee's privacy. 4514 An implementation SHOULD be able to restrict, on a per-user basis, 4515 what kind of location and availability information is given out to 4516 certain classes of callers. 4518 13.4 Known Security Problems 4520 With either TCP or UDP, a denial of service attack exists by a rogue 4521 proxy sending 6xx responses. Although a client SHOULD choose to 4522 ignore such responses if it requested authentication, a proxy cannot 4523 do so. It is obliged to forward the 6xx response back to the client. 4524 The client can then ignore the response, but if it repeats the 4525 request it will probably reach the same rogue proxy again, and the 4526 process will repeat. 4528 14 SIP Security Using PGP 4530 14.1 PGP Authentication Scheme 4532 The "pgp" authentication scheme is based on the model that the client 4533 authenticates itself with a request signed with the client's private 4534 key. The server can then ascertain the origin of the request if it 4535 has access to the public key, preferably signed by a trusted third 4536 party. 4538 14.1.1 The WWW-Authenticate Response Header 4539 WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge 4540 pgp-challenge = * (";" pgp-params ) 4541 pgp-params = realm | pgp-version | pgp-algorithm 4542 realm = "realm" "=" realm-value 4543 realm-value = quoted-string 4544 pgp-version = "version" "=" digit *( "." digit ) *letter 4545 pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token ) 4547 The meanings of the values of the parameters used above are as 4548 follows: 4550 realm: A string to be displayed to users so they know which identity 4551 to use. This string SHOULD contain at least the name of the host 4552 performing the authentication and MAY additionally indicate the 4553 collection of users who might have access. An example might be " 4554 Users with call-out privileges ". 4556 pgp-algorithm: A string indicating the PGP message integrity check 4557 (MIC) to be used to produce the signature. If this not present 4558 it is assumed to be "md5". The currently defined values are 4559 "md5" for the MD5 checksum, and "sha1" for the SHA.1 algorithm. 4561 pgp-version: The version of PGP that the client MUST use. Common 4562 values are "2.6.2" and "5.0". The default is 5.0. 4564 Example: 4566 WWW-Authenticate: pgp ;version="5.0" 4567 ;realm="Your Startrek identity, please" ;algorithm="md5" 4569 14.1.2 The Authorization Request Header 4571 The client is expected to retry the request, passing an Authorization 4572 header line, which is defined as follows. 4574 Authorization ___ "Authorization" ":" "pgp" *( ";" pgp-response ) 4575 pgp-response ___ realm | pgp-version | pgp-signature | signed-by 4576 pgp-signature ___ "signature" "=" quoted-string 4577 signed-by ___ "signed-by" "=" URI 4579 The signature MUST correspond to the From header of the request 4580 unless the signed-by parameter is provided. 4582 pgp-signature: The PGP ASCII-armored signature, as it appears between 4583 the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" delimiters, 4584 without the version indication. The signature is included 4585 without any linebreaks. 4587 The signature is computed across the request method, request version 4588 and header fields following the Authorization header and the message 4589 body, in the same order as they appear in the message. The request 4590 method and version are prepended to the header fields without any 4591 white space. The signature is computed across the headers as sent, 4592 including any folding and the terminating CRLF. The CRLF following 4593 the Authorization header is NOT included in the signature. 4595 Using the ASCII-armored version is about 25% less space- 4596 efficient than including the binary signature, but it is 4597 significantly easier for the receiver to piece together. 4598 Versions of the PGP program always include the full 4599 (compressed) signed text in their output unless ASCII- 4600 armored mode ( -sta ) is specified. Typical signatures are 4601 about 200 bytes long. -- The PGP signature mechanism allows 4602 the client to simply pass the request to an external PGP 4603 program. This relies on the requirement that proxy servers 4604 are not allowed to reorder or change header fields. 4606 realm: The realm is copied from the corresponding WWW-Authenticate 4607 header field parameter. 4609 signed-by: If and only if the request was not signed by the entity 4610 listed in the From header, the signed-by header indicates the 4611 name of the signing entity, expressed as a URI. 4613 Receivers of signed SIP messages SHOULD discard any end-to-end header 4614 fields above the Authorization header, as they may have been 4615 maliciously added en route by a proxy. 4617 Example: 4619 Authorization: pgp version="5.0" 4620 ;realm="Your Startrek identity, please" 4621 ;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf 4622 VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt 4623 SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX 4624 =aIrx" 4626 14.2 PGP Encryption Scheme 4627 The PGP encryption scheme uses the following syntax: 4629 Encryption ___ "Encryption" ":" "pgp" pgp-eparams 4630 pgp-eparams ___ 1# ( pgp-version | pgp-encoding ) 4631 pgp-encoding ___ "encoding" "=" "ascii" | token 4633 encoding: Describes the encoding or "armor" used by PGP. The value 4634 "ascii" refers to the standard PGP ASCII armor, without the 4635 lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and 4636 without the version identifier. By default, the encrypted part 4637 is included as binary. 4639 Example: 4641 Encryption: pgp version="2.6.2", encoding="ascii" 4643 14.3 Response-Key Header Field for PGP 4645 Response-Key ___ "Response-Key" ":" "pgp" pgp-eparams 4646 pgp-eparams ___ 1# ( pgp-version | pgp-encoding | pgp-key) 4647 pgp-key ___ "key" "=" quoted-string 4649 If ASCII encoding has been requested via the encoding parameter, the 4650 key parameter contains the user's public key as extracted with the 4651 "pgp -kxa user ". 4653 Example: 4655 Response-Key: pgp version="2.6.2", encoding="ascii", 4656 key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk 4657 mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx 4658 sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu 4659 bmVAY3MuY29sdW1iaWEuZWR1Pg== 4660 =+y19" 4662 15 Examples 4664 In the following examples, we often omit the message body and the 4665 corresponding Content-Length and Content-Type headers for brevity. 4667 15.1 Registration 4669 A user at host saturn.bell-tel.com registers on start-up, via 4670 multicast, with the local SIP server named sip.bell-tel.com the 4671 example, the user agent on saturn expects to receive SIP requests on 4672 UDP port 3890. 4674 C->S: REGISTER sip:sip.bell-tel.com SIP/2.0 4675 Via: SIP/2.0/UDP 128.16.64.19 4676 From: sip:watson@bell-tel.com 4677 To: sip:watson@bell-tel.com 4678 Call-ID: 4236500900@saturn.bell-tel.com 4679 CSeq: 1 REGISTER 4680 Contact: 4681 Expires: 7200 4683 The registration expires after two hours. Any future invitations for 4684 watson@bell-tel.com arriving at sip.bell-tel.com will now be 4685 redirected to watson@saturn.bell-tel.com , UDP port 3890. 4687 If Watson wants to be reached elsewhere, say, an on-line service he 4688 uses while traveling, he updates his reservation after first 4689 cancelling any existing locations: 4691 C->S: REGISTER sip:bell-tel.com SIP/2.0 4692 Via: SIP/2.0/UDP 128.16.64.19 4693 From: sip:watson@bell-tel.com 4694 To: sip:watson@bell-tel.com 4695 Call-ID: 1345441868@saturn.bell-tel.com 4696 CSeq: 1 REGISTER 4697 Contact: * 4698 Expires: 0 4700 C->S: REGISTER sip:bell-tel.com SIP/2.0 4701 Via: SIP/2.0/UDP 128.16.64.19 4702 From: sip:watson@bell-tel.com 4703 To: sip:watson@bell-tel.com 4704 Call-ID: 81791800@saturn.bell-tel.com 4705 CSeq: 1 REGISTER 4706 Contact: sip:tawatson@example.com 4708 Now, the server will forward any request for Watson to the server at 4709 example.com , using the Request-URI tawatson@example.com 4711 It is possible to use third-party registration. Here, the secretary 4712 jon.diligent registers his boss: 4714 C->S: REGISTER sip:bell-tel.com SIP/2.0 4715 Via: SIP/2.0/UDP 128.16.64.19 4716 From: sip:jon.diligent@bell-tel.com 4717 To: sip:watson@bell-tel.com 4718 Call-ID: 1212759220@saturn.bell-tel.com 4719 CSeq: 1 REGISTER 4720 Contact: sip:tawatson@example.com 4722 The request could be send to either the registrar at bell-tel.com or 4723 the server at example.com example.com would proxy the request to the 4724 address indicated in the Request-URI. Then, Max-Forwards header could 4725 be used to restrict the registration to that server. 4727 15.2 Invitation to a Multicast Conference 4729 The first example invites schooler@vlsi.cs.caltech.edu to a multicast 4730 session. All examples use the Session Description Protocol (SDP) (RFC 4731 2327 [5]) as the session description format. 4733 15.2.1 Request 4735 C->S: INVITE sip:schooler@vlsi.cs.caltech.edu SIP/2.0 4736 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 4737 ;maddr=239.128.16.254;ttl=16 4738 Via: SIP/2.0/UDP north.east.isi.edu 4739 From: Mark Handley 4740 To: Eve Schooler 4741 Call-ID: 2963313058@oregon.isi.edu 4742 CSeq: 1 INVITE 4743 Subject: SIP will be discussed, too 4744 Content-Type: application/sdp 4745 Content-Length: 187 4747 v=0 4748 o=user1 53655765 2353687637 IN IP4 128.3.4.5 4749 s=Mbone Audio 4750 i=Discussion of Mbone Engineering Issues 4751 e=mbone@somewhere.com 4752 c=IN IP4 224.2.0.1/127 4753 t=0 0 4754 m=audio 3456 RTP/AVP 0 4756 The Via fields list the hosts along the path from invitation 4757 initiator (the last element of the list) towards the invitee. In the 4758 example above, the message was last multicast to the administratively 4759 scoped group 239.128.16.254 with a ttl of 16 from the host 4760 131.215.131.131 4762 The request header above states that the request was initiated by 4763 mjh@isi.edu from the host 128.16.64.19 schooler@caltech.edu is being 4764 invited; the message is currently being routed to 4765 schooler@vlsi.cs.caltech.edu 4767 In this case, the session description is using the Session 4768 Description Protocol (SDP), as stated in the Content-Type header. 4770 The header is terminated by an empty line and is followed by a 4771 message body containing the session description. 4773 15.2.2 Response 4775 The called user agent, directly or indirectly through proxy servers, 4776 indicates that it is alerting ("ringing") the called party: 4778 S->C: SIP/2.0 180 Ringing 4779 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 4780 ;maddr=239.128.16.254;ttl=16 4781 Via: SIP/2.0/UDP north.east.isi.edu 4782 From: Mark Handley 4783 To: Eve Schooler ;tag=9883472 4784 Call-ID: 2963313058@oregon.isi.edu 4785 CSeq: 1 INVITE 4787 A sample response to the invitation is given below. The first line of 4788 the response states the SIP version number, that it is a 200 (OK) 4789 response, which means the request was successful. The Via headers are 4790 taken from the request, and entries are removed hop by hop as the 4791 response retraces the path of the request. A new authentication field 4792 MAY be added by the invited user's agent if required. The Call-ID is 4793 taken directly from the original request, along with the remaining 4794 fields of the request message. The original sense of From field is 4795 preserved (i.e., it is the session initiator). 4797 In addition, the Contact header gives details of the host where the 4798 user was located, or alternatively the relevant proxy contact point 4799 which should be reachable from the caller's host. 4801 S->C: SIP/2.0 200 OK 4802 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 4803 ;maddr=239.128.16.254;ttl=16 4804 Via: SIP/2.0/UDP north.east.isi.edu 4805 From: Mark Handley 4806 To: Eve Schooler ;tag=9883472 4807 Call-ID: 2963313058@oregon.isi.edu 4808 CSeq: 1 INVITE 4809 Contact: sip:es@jove.cs.caltech.edu 4811 The caller confirms the invitation by sending a request to the 4812 location named in the Contact header: 4814 C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0 4815 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 4816 ;maddr=239.128.16.254;ttl=16 4817 From: Mark Handley 4818 To: Eve Schooler ;tag=9883472 4819 Call-ID: 2963313058@oregon.isi.edu 4820 CSeq: 1 ACK 4822 15.3 Two-party Call 4824 For two-party Internet phone calls, the response must contain a 4825 description of where to send the data. In the example below, Bell 4826 calls Watson. Bell indicates that he can receive RTP audio codings 0 4827 (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4). 4829 C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 4830 Via: SIP/2.0/UDP 169.130.12.5 4831 From: A. Bell 4832 To: T. Watson 4833 Call-ID: 3298420296@kton.bell-tel.com 4834 CSeq: 1 INVITE 4835 Subject: Mr. Watson, come here. 4836 Content-Type: application/sdp 4837 Content-Length: ... 4839 v=0 4840 o=bell 53655765 2353687637 IN IP4 128.3.4.5 4841 s=Mr. Watson, come here. 4842 c=IN IP4 135.180.144.94 4843 m=audio 3456 RTP/AVP 0 3 4 5 4845 S->C: SIP/2.0 100 Trying 4846 Via: SIP/2.0/UDP 169.130.12.5 4847 From: A. Bell 4848 To: T. Watson ;tag=37462311 4849 Call-ID: 3298420296@kton.bell-tel.com 4850 CSeq: 1 INVITE 4851 Content-Length: 0 4853 S->C: SIP/2.0 180 Ringing 4854 Via: SIP/2.0/UDP 169.130.12.5 4855 From: A. Bell 4856 To: T. Watson ;tag=37462311 4857 Call-ID: 3298420296@kton.bell-tel.com 4858 CSeq: 1 INVITE 4859 Content-Length: 0 4861 S->C: SIP/2.0 182 Queued, 2 callers ahead 4862 Via: SIP/2.0/UDP 169.130.12.5 4863 From: A. Bell 4864 To: T. Watson ;tag=37462311 4865 Call-ID: 3298420296@kton.bell-tel.com 4866 CSeq: 1 INVITE 4867 Content-Length: 0 4869 S->C: SIP/2.0 182 Queued, 1 caller ahead 4870 Via: SIP/2.0/UDP 169.130.12.5 4871 From: A. Bell 4872 To: T. Watson ;tag=37462311 4873 Call-ID: 3298420296@kton.bell-tel.com 4874 CSeq: 1 INVITE 4875 Content-Length: 0 4877 S->C: SIP/2.0 200 OK 4878 Via: SIP/2.0/UDP 169.130.12.5 4879 From: A. Bell 4880 To: ;tag=37462311 4881 Call-ID: 3298420296@kton.bell-tel.com 4882 CSeq: 1 INVITE 4883 Contact: sip:watson@boston.bell-tel.com 4884 Content-Length: ... 4886 v=0 4887 o=watson 4858949 4858949 IN IP4 192.1.2.3 4888 s=I'm on my way 4889 c=IN IP4 135.180.161.25 4890 m=audio 5004 RTP/AVP 0 3 4892 The example illustrates the use of informational status responses. 4893 Here, the reception of the call is confirmed immediately (100), then, 4894 possibly after some database mapping delay, the call rings (180) and 4895 is then queued, with periodic status updates. 4897 Watson can only receive PCMU and GSM. Note that Watson's list of 4898 codecs may or may not be a subset of the one offered by Bell, as each 4899 party indicates the data types it is willing to receive. Watson will 4900 send audio data to port 3456 at 135.180.144.94, Bell will send to 4901 port 5004 at 135.180.161.25. 4903 By default, the media session is one RTP session. Watson will receive 4904 RTCP packets on port 5005, while Bell will receive them on port 3457. 4906 Since the two sides have agreed on the set of media, Watson confirms 4907 the call without enclosing another session description: 4909 C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0 4910 Via: SIP/2.0/UDP 169.130.12.5 4911 From: A. Bell 4912 To: T. Watson ;tag=37462311 4913 Call-ID: 3298420296@kton.bell-tel.com 4914 CSeq: 1 ACK 4916 15.4 Terminating a Call 4918 To terminate a call, caller or callee can send a BYE request: 4920 C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0 4921 Via: SIP/2.0/UDP 169.130.12.5 4922 From: A. Bell 4923 To: T. A. Watson ;tag=37462311 4924 Call-ID: 3298420296@kton.bell-tel.com 4925 CSeq: 2 BYE 4927 If the callee wants to abort the call, it simply reverses the To and 4928 From fields. Note that it is unlikely that an BYE from the callee 4929 will traverse the same proxies as the original INVITE. 4931 15.5 Forking Proxy 4933 In this example, Bell ( a.g.bell@bell-tel.com ) (C), currently seated 4934 at host c.bell-tel.com wants to call Watson ( t.watson@ieee.org ). At 4935 the time of the call, Watson is logged in at two workstations, 4936 watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has 4937 registered with the IEEE proxy server (P) called sip.ieee.org 4938 registration for the home machine of Watson, at watson@h.bell-tel.com 4939 (H), as well as a permanent registration at watson@acm.org (A). For 4940 brevity, the examples omit the session description. 4942 Watson's user agent sends the invitation to the SIP server for the 4943 ieee.org domain: 4945 C->P: INVITE sip:watson@ieee.org SIP/2.0 4946 Via: SIP/2.0/UDP c.bell-tel.com 4947 From: A. Bell 4948 To: T. Watson 4949 Call-ID: 31415@kton.bell-tel.com 4950 CSeq: 1 INVITE 4952 The SIP server at ieee.org tries the four addresses in parallel. It 4953 sends the following message to the home machine: 4955 P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0 4956 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 4957 Via: SIP/2.0/UDP c.bell-tel.com 4958 From: A. Bell 4959 To: T. Watson 4960 Call-ID: 31415@kton.bell-tel.com 4961 CSeq: 1 INVITE 4963 This request immediately yields a 404 (Not Found) response, since 4964 Watson is not currently logged in at home: 4966 H->P: SIP/2.0 404 Not Found 4967 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 4968 Via: SIP/2.0/UDP c.bell-tel.com 4969 From: A. Bell 4970 To: T. Watson ;tag=87454273 4971 Call-ID: 31415@kton.bell-tel.com 4972 CSeq: 1 INVITE 4974 The proxy ACKs the response so that host H can stop retransmitting 4975 it: 4977 P->H: ACK sip:watson@h.bell-tel.com SIP/2.0 4978 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 4979 From: A. Bell 4980 To: T. Watson ;tag=37462311 4981 Call-ID: 31415@kton.bell-tel.com 4982 CSeq: 1 ACK 4984 Also, P attempts to reach Watson through the ACM server: 4986 P->A: INVITE sip:watson@acm.org SIP/2.0 4987 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 4988 Via: SIP/2.0/UDP c.bell-tel.com 4989 From: A. Bell 4990 To: T. Watson 4991 Call-ID: 31415@kton.bell-tel.com 4992 CSeq: 1 INVITE 4994 In parallel, the next attempt proceeds, with an INVITE to X and Y: 4996 P->X: INVITE sip:watson@x.bell-tel.com SIP/2.0 4997 Via: SIP/2.0/UDP sip.ieee.org ;branch=3 4998 Via: SIP/2.0/UDP c.bell-tel.com 4999 From: A. Bell 5000 To: T. Watson 5001 Call-ID: 31415@kton.bell-tel.com 5002 CSeq: 1 INVITE 5004 P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0 5005 Via: SIP/2.0/UDP sip.ieee.org ;branch=4 5006 Via: SIP/2.0/UDP c.bell-tel.com 5007 From: A. Bell 5008 To: T. Watson 5009 Call-ID: 31415@kton.bell-tel.com 5010 CSeq: 1 INVITE 5012 As it happens, both Watson at X and a colleague in the other lab at 5013 host Y hear the phones ringing and pick up. Both X and Y return 200s 5014 via the proxy to Bell. 5016 X->P: SIP/2.0 200 OK 5017 Via: SIP/2.0/UDP sip.ieee.org ;branch=3 5018 Via: SIP/2.0/UDP c.bell-tel.com 5019 From: A. Bell 5020 To: T. Watson ;tag=192137601 5021 Call-ID: 31415@kton.bell-tel.com 5022 CSeq: 1 INVITE 5023 Contact: sip:t.watson@x.bell-tel.com 5025 Y->P: SIP/2.0 200 OK 5026 Via: SIP/2.0/UDP sip.ieee.org ;branch=4 5027 Via: SIP/2.0/UDP c.bell-tel.com 5028 Contact: sip:t.watson@y.bell-tel.com 5029 From: A. Bell 5030 To: T. Watson ;tag=35253448 5031 Call-ID: 31415@kton.bell-tel.com 5032 CSeq: 1 INVITE 5034 Both responses are forwarded to Bell, using the Via information. At 5035 this point, the ACM server is still searching its database. P can now 5036 cancel this attempt: 5038 P->A: CANCEL sip:watson@acm.org SIP/2.0 5039 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 5040 From: A. Bell 5041 To: T. Watson 5042 Call-ID: 31415@kton.bell-tel.com 5043 CSeq: 1 CANCEL 5045 The ACM server gladly stops its neural-network database search and 5046 responds with a 200. The 200 will not travel any further, since P is 5047 the last Via stop. 5049 A->P: SIP/2.0 200 OK 5050 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 5051 From: A. Bell 5052 To: T. Watson 5053 Call-ID: 31415@kton.bell-tel.com 5054 CSeq: 1 CANCEL 5056 Bell gets the two 200 responses from X and Y in short order. Bell's 5057 reaction now depends on his software. He can either send an ACK to 5058 both if human intelligence is needed to determine who he wants to 5059 talk to or he can automatically reject one of the two calls. Here, he 5060 acknowledges both, separately and directly to the final destination: 5062 C->X: ACK sip:watson@x.bell-tel.com SIP/2.0 5063 Via: SIP/2.0/UDP c.bell-tel.com 5064 From: A. Bell 5065 To: T. Watson ;tag=192137601 5066 Call-ID: 31415@c.bell-tel.com 5067 CSeq: 1 ACK 5069 C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0 5070 Via: SIP/2.0/UDP c.bell-tel.com 5071 From: A. Bell 5072 To: T. Watson ;tag=35253448 5073 Call-ID: 31415@c.bell-tel.com 5074 CSeq: 1 ACK 5076 After a brief discussion between the three, it becomes clear that 5077 Watson is at X, thus Bell sends a BYE to Y, which is replied to: 5079 C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0 5080 Via: SIP/2.0/UDP c.bell-tel.com 5081 From: A. Bell 5082 To: T. Watson ;tag=35253448 5083 Call-ID: 31415@c.bell-tel.com 5084 CSeq: 2 BYE 5086 Y->C: SIP/2.0 200 OK 5087 Via: SIP/2.0/UDP c.bell-tel.com 5088 From: A. Bell 5089 To: T. Watson ;tag=35253448 5090 Call-ID: 31415@c.bell-tel.com 5091 CSeq: 2 BYE 5093 15.6 Redirects 5095 Replies with status codes 301 (Moved Permanently) or 302 (Moved 5096 Temporarily) specify another location using the Contact field. 5097 Continuing our earlier example, the server at ieee.org decides to 5098 redirect rather than proxy the request: 5100 S->C: SIP/2.0 302 Moved temporarily 5101 Via: SIP/2.0/UDP sip.ieee.org 5102 From: A. Bell 5103 To: T. Watson ;tag=72538263 5104 Call-ID: 31415@kton.bell-tel.com 5105 CSeq: 1 INVITE 5106 Contact: sip:watson@h.bell-tel.com, 5107 sip:watson@acm.org, sip:watson@x.bell-tel.com, 5108 sip:watson@y.bell-tel.com 5109 CSeq: 1 INVITE 5111 As another example, assume Alice wants to delegate her calls to Bob 5112 while she is on vacation until July 29th. Any calls meant for her 5113 will reach Bob with Alice's To field, indicating to him what role he 5114 is to play. In the example below, Charlie calls Alice. 5116 S->C: SIP/2.0 302 Moved temporarily 5117 From: Charlie 5118 To: Alice ;tag=2332462 5119 Call-ID: 27182@caller.com 5120 Contact: sip:bob@anywhere.com 5121 Expires: Wed, 29 Jul 1998 9:00:00 GMT 5122 CSeq: 1 INVITE 5124 Charlie then sends the following request to the SIP server of the 5125 anywhere.com domain. 5127 C->S: INVITE sip:bob@anywhere.com SIP/2.0 5128 From: sip:charlie@caller.com 5129 To: sip:alice@anywhere.com 5130 Call-ID: 27182@caller.com 5131 CSeq: 2 INVITE 5133 In the third redirection example, we assume that all requests are 5134 directed through a local firewall at caller.com firewall happens to 5135 be overloaded and thus redirects the call from Charlie to a secondary 5136 server. 5138 S->C: SIP/2.0 302 Moved temporarily 5139 From: sip:charlie@caller.com 5140 To: Alice ;tag=273462236 5141 Call-ID: 27182@caller.com 5142 CSeq: 2 INVITE 5143 Contact: 5145 Charlie directs the invitation to the secondary server at port 5080, 5146 but maintains the same Request-URI as before. 5148 C->S: INVITE sip:alice@anywhere.com SIP/2.0 5149 From: sip:charlie@caller.com 5150 To: sip:alice@anywhere.com 5151 Call-ID: 27182@caller.com 5152 CSeq: 3 INVITE 5154 15.7 Alternative Services 5156 An example of a 380 (Alternative Service) response is: 5158 S->C: SIP/2.0 380 Alternative Service 5159 Via: SIP/2.0/UDP 131.215.131.131 5160 Via: SIP/2.0/UDP 128.16.64.19 5161 From: sip:mjh@isi.edu 5162 To: ;tag=11223647 5163 Call-ID: 14142@oregon.isi.edu 5164 CSeq: 1 INVITE 5165 Contact: sip:recorder@131.215.131.131 5166 Content-Type: application/sdp 5167 Content-Length: 146 5168 v=0 5169 o=mm-server 2523535 0 IN IP4 131.215.131.131 5170 s=Answering Machine 5171 i=Leave an audio message 5172 c=IN IP4 131.215.131.131 5173 t=0 0 5174 m=audio 12345 RTP/AVP 0 5176 In this case, the answering server provides a session description 5177 that describes an "answering machine". If the invitation initiator 5178 decides to take advantage of this service, it should send an 5179 invitation request to the answering machine at 131.215.131.131 with 5180 the session description provided (modified as appropriate for a 5181 unicast session to contain the appropriate local address and port for 5182 the invitation initiator). This request SHOULD contain a different 5183 Call-ID from the one in the original request. An example would be: 5185 C->S: INVITE sip:recorder@131.215.131.131 SIP/2.0 5186 Via: SIP/2.0/UDP 128.16.64.19 5187 From: sip:mjh@isi.edu 5188 To: sip:schooler@cs.caltech.edu 5189 Call-ID: 1732@oregon.isi.edu 5190 CSeq: 1 INVITE 5191 Content-Type: application/sdp 5192 Content-Length: 146 5194 v=0 5195 o=mm-server 2523535 0 IN IP4 131.215.131.131 5196 s=Answering Machine 5197 i=Leave an audio message 5198 c=IN IP4 128.16.64.19 5199 t=0 0 5200 m=audio 26472 RTP/AVP 0 5202 Invitation initiators MAY choose to treat a 350 (Alternative Service) 5203 response as a failure if they wish to do so. 5205 15.8 Negotiation 5207 An example of a 606 (Not Acceptable) response is: 5209 S->C: SIP/2.0 606 Not Acceptable 5210 From: sip:mjh@isi.edu 5211 To: ;tag=7434264 5212 Call-ID: 14142@oregon.isi.edu 5213 CSeq: 1 INVITE 5214 Contact: sip:mjh@131.215.131.131 5215 Warning: 370 "Insufficient bandwidth (only have ISDN)", 5216 305 "Incompatible media format", 5217 330 "Multicast not available" 5218 Content-Type: application/sdp 5219 Content-Length: 50 5221 v=0 5222 s=Lets talk 5223 b=CT:128 5224 c=IN IP4 131.215.131.131 5225 m=audio 3456 RTP/AVP 7 0 13 5226 m=video 2232 RTP/AVP 31 5228 In this example, the original request specified 256 kb/s total 5229 bandwidth, and the response states that only 128 kb/s is available. 5230 The original request specified GSM audio, H.261 video, and WB 5231 whiteboard. The audio coding and whiteboard are not available, but 5232 the response states that DVI, PCM or LPC audio could be supported in 5233 order of preference. The response also states that multicast is not 5234 available. In such a case, it might be appropriate to set up a 5235 transcoding gateway and re-invite the user. 5237 15.9 OPTIONS Request 5239 A caller Alice can use an OPTIONS request to find out the 5240 capabilities of a potential callee Bob, without "ringing" the 5241 designated address. Bob returns a description indicating that he is 5242 capable of receiving audio and video, with a list of supported 5243 encodings. 5245 C->S: OPTIONS sip:bob@example.com SIP/2.0 5246 From: Alice 5247 To: Bob 5248 Call-ID: 6378@host.anywhere.org 5249 CSeq: 1 OPTIONS 5250 Accept: application/sdp 5252 S->C: SIP/2.0 200 OK 5253 From: Alice 5254 To: Bob ;tag=376364382 5255 Call-ID: 6378@host.anywhere.org 5256 Content-Length: 81 5257 Content-Type: application/sdp 5259 v=0 5260 m=audio 0 RTP/AVP 0 1 3 99 5261 m=video 0 RTP/AVP 29 30 5262 a=rtpmap:99 SX7300/8000 5264 A Minimal Implementation 5266 A.1 Client 5268 All clients MUST be able to generate the INVITE and ACK requests. 5269 Clients MUST generate and parse the Call-ID, Content-Length, 5270 Content-Type, CSeq, From and To headers. Clients MUST also parse the 5271 Require header. A minimal implementation MUST understand SDP (RFC 5272 2327, [5]). It MUST be able to recognize the status code classes 1 5273 through 6 and act accordingly. 5275 The following capability sets build on top of the minimal 5276 implementation described in the previous paragraph: 5278 Basic: A basic implementation adds support for the BYE method to 5279 allow the interruption of a pending call attempt. It includes a 5280 User-Agent header in its requests and indicate its preferred 5281 language in the Accept-Language header. 5283 Redirection: To support call forwarding, a client needs to be able to 5284 understand the Contact header, but only the SIP-URL part, not 5285 the parameters. 5287 Negotiation: A client MUST be able to request the OPTIONS method and 5288 understand the 380 (Alternative Service) status and the Contact 5289 parameters to participate in terminal and media negotiation. It 5290 SHOULD be able to parse the Warning response header to provide 5291 useful feedback to the caller. 5293 Authentication: If a client wishes to invite callees that require 5294 caller authentication, it MUST be able to recognize the 401 5295 (Unauthorized) status code, MUST be able to generate the 5296 Authorization request header and MUST understand the WWW- 5297 Authenticate response header. 5299 If a client wishes to use proxies that require caller authentication, 5300 it MUST be able to recognize the 407 (Proxy Authentication Required) 5301 status code, MUST be able to generate the Proxy-Authorization request 5302 header and understand the Proxy-Authenticate response header. 5304 A.2 Server 5306 A minimally compliant server implementation MUST understand the 5307 INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also 5308 understand CANCEL. It MUST parse and generate, as appropriate, the 5309 Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max- 5310 Forwards, Require, To and Via headers. It MUST echo the CSeq and 5311 Timestamp headers in the response. It SHOULD include the Server 5312 header in its responses. 5314 A.3 Header Processing 5316 Table 6 lists the headers that different implementations support. UAC 5317 refers to a user-agent client (calling user agent), UAS to a user- 5318 agent server (called user-agent). 5320 B Usage of SDP 5322 By default, the nth media session in a unicast INVITE request will 5323 become a single RTP session with the nth media session in the 5324 response. Thus, the callee should be careful to order media 5325 descriptions appropriately. 5327 It is assumed that if caller or callee include a particular media 5328 type, they want to both send and receive media data. If the callee 5329 does not want to send a particular media type, it marks the media 5330 entry as recvonly receive a particular media type, it may mark it as 5331 sendonly wants to neither receive nor send a particular media type, 5332 it sets the port to zero. (RTCP ports are not needed in this case.) 5334 The caller includes all media types that it is willing to send so 5335 that the receiver can provide matching media descriptions. 5337 The callee sets the port to zero if callee and caller only want to 5338 receive a media type. 5340 Either party can set the "c" destination address to zero (0.0.0.0) if 5341 it wants to signal to the other party to stop sending media data. 5342 This implements a (far-side) "mute" or "hold" functionality. 5344 The SDP fields "s" and the SIP Subject header have 5345 different meanings when inviting to a multicast session. 5346 The SDP field describes the subject of the multicast 5347 type UAC proxy UAS 5348 __________________________________________________ 5349 Accept R - o o 5350 Accept-Language R - b b 5351 Allow 405 o - - 5352 Authorization R a o a 5353 Call-ID g m m m 5354 Content-Length g m m m 5355 Content-Type g m - m 5356 CSeq g m m m 5357 Encryption g e - e 5358 Expires g - o o 5359 From g m o m 5360 Contact R - - - 5361 Contact r r r - 5362 Max-Forwards R - b - 5363 Proxy-Authenticate 407 a - - 5364 Proxy-Authorization R - a - 5365 Proxy-Require R - m - 5366 Require R m - m 5367 Response-Key R - - e 5368 Timestamp g o o m 5369 To g m m m 5370 Unsupported r b b - 5371 Via g m m m 5372 WWW-Authenticate 401 a - - 5374 Table 6: This table indicates which systems parse which header 5375 fields. Type is as in Table 4 and 5. "-" indicates the field is not 5376 meaningful to this system (although it might be generated by it). "m" 5377 indicates the field MUST be understood. "b" indicates the field 5378 SHOULD be understood by a Basic implementation. "r" indicates the 5379 field SHOULD be understood if the system claims to understand 5380 redirection. "a" indicates the field SHOULD be understood if the 5381 system claims to support authentication. "e" indicates the field 5382 SHOULD be understood if the system claims to support encryption. "o" 5383 indicates support of the field is purely optional. Headers whose 5384 support is optional for all implementations are not shown. 5386 session, while the SIP Subject header describes the reason 5387 for the invitation. The example in Section 15.2 illustrates 5388 this point. For invitations to two-party sessions, the SDP 5389 "s" field MAY be left empty. The "o" field is not strictly 5390 necessary for two-party sessions, but MUST be present to 5391 allow re-use of SDP-based tools. 5393 C Summary of Augmented BNF 5395 In this specification we use the Augmented Backus-Naur Form notation 5396 described in RFC 2234 [21]. For quick reference, the following is a 5397 brief summary of the main features of this ABNF. 5399 "abc" 5400 The case-insensitive string of characters "abc" (or "Abc", 5401 "aBC", etc.); 5403 %d32 5404 The character with ASCII code decimal 32 (space); 5406 *term 5407 zero of more instances of term; 5409 3*term 5410 three or more instances of term; 5412 2*4term 5413 two, three or four instances of term; 5415 [ term ] 5416 term is optional; 5418 term1 term2 term3 5419 set notation: term1, term2 and term3 must all appear but 5420 their order is unimportant; 5422 term1 | term2 5423 either term1 or term2 may appear but not both; 5425 #term 5426 a comma separated list of term; 5428 2#term 5429 a comma separated list of term containing at least 2 items; 5431 2#4term 5432 a comma separated list of term containing 2 to 4 items. 5434 Common Tokens 5436 Certain tokens are used frequently in the BNF of this document, and 5437 not defined elsewhere. Their meaning is well understood but we 5438 include it here for completeness. 5440 CR = %d13 ; US-ASCII CR, carriage return character 5441 LF = %d10 ; US-ASCII LF, line feed character 5442 CRLF = CR LF ; typically the end of a line 5443 SP = %d32 ; US-ASCII SP, space character 5444 HT = %d09 ; US-ASCII HT, horizontal tab character 5445 LWS = [CRLF] 1*( SP | HT ) ; linear whitespace 5446 DIGIT = "0" .. "9" ; a single decimal digit 5447 CHAR = 5448 CTL = 5450 OCTET = 5451 TEXT = 5453 unreserved = alphanum | mark 5454 mark = "-" | "_" | "." | "!" | "~" | "*" | "'" 5455 | "(" | ")" 5456 separators = "(" | ")" | "<" | ">" | "@" | 5457 "," | ";" | ":" | "/" | <"> | 5458 "/" | "[" | "]" | "?" | "=" | 5459 "" | "" | SP | HT 5460 escaped = "%" hex hex 5461 hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | 5462 "a" | "b" | "c" | "d" | "e" | "f" 5463 alphanum = alpha | digit 5464 alpha = lowalpha | upalpha 5465 lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | 5466 "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | 5467 "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" 5468 upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | 5469 "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | 5470 "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" 5471 digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 5472 "8" | "9" 5473 token = 1*< any CHAR except CTL's or separators> 5474 comment = "(" *(ctext | quoted-pair | comment) ")" 5475 ctext = < any TEXT excluding "(" and ")"> 5477 D IANA Considerations 5479 Section 4.4 describes a name space and mechanism for registering SIP 5480 options. 5482 Section 6.41 describes the name space for registering SIP warn-codes. 5484 E Changes in Version -09 5486 Since version -08, the following changes have been made. 5488 o Checked and capitalized or rewrote "may", "should" and "must". 5490 o Consistent use of "header field" throughout the spec. 5492 o Warning messages updated. 5494 o Added method URL parameter that indicates request method. Now 5495 allows complete construction of SIP request from within a web 5496 page and a Location header. The latter is particularly useful 5497 for third-party call control. 5499 o Clarified use of SRV DNS records. TCP and UDP may have equal 5500 priority, but different weight. 5502 o Added 486 (Busy here) status hen there might be other 5503 branches, such as answering machines, ready to take the call. 5505 o Added expires parameter to Location header field to allow 5506 reporting of expiration times for each location. 5508 o Clarified 481 as referring to a mismatch in describing a call 5509 leg (BYE) or transaction (CANCEL). 5511 o Clarified that the CSeq method in the request is always the 5512 same as the request method, even for ACK. 5514 o Made the tag parameter a To or From parameter, not a URL 5515 parameter. Tags may be needed for some non-SIP URIs. 5517 o Location header field renamed to Contact, with syntax 5518 according to To and From. 5520 o Rules for defaults in Contact headers now simply point to URL 5521 rules. 5523 o Added wording to ACK section on how to process requests. 5525 o Made all elements in sent-protocol mandatory to avoid 5526 ambiguity of whether "SIP/2.0" referes to the default protocol 5527 of version "SIP" with transport "2.0" or the correct 5528 interpretation. 5530 o Filled in descriptions of status codes 410, 411 and 413, 5531 basically unchanged from HTTP. 5533 o Made Record-Route and Route header fields consistent with 5534 From, To, Contact. As long as the URI doesn't contain 5535 parameters or commas, this is no change, but it avoids the 5536 same problems that lead to the change in Contact syntax. 5538 o Added remark to SDP section to use a zero address to 5539 temporarily disable media transmission ("put call on hold"). 5541 o Changed wording for Record-Route to apply to any subsequent 5542 request. 5544 F Acknowledgments 5546 We wish to thank the members of the IETF MMUSIC WG for their comments 5547 and suggestions. Detailed comments were provided by Jim Buller, Dave 5548 Devanathan, Yaron Goland, Christian Huitema, Gadi Karmi, Jonathan 5549 Lennox, Moshe J. Sambol, and Eric Tremblay. 5551 This work is based, inter alia, on [29,30]. 5553 G Authors' Addresses 5555 Mark Handley 5556 USC Information Sciences Institute 5557 c/o MIT Laboratory for Computer Science 5558 545 Technology Square 5559 Cambridge, MA 02139 5560 USA 5561 electronic mail: mjh@isi.edu 5563 Henning Schulzrinne 5564 Dept. of Computer Science 5565 Columbia University 5566 1214 Amsterdam Avenue 5567 New York, NY 10027 5568 USA 5569 electronic mail: schulzrinne@cs.columbia.edu 5571 Eve Schooler 5572 Computer Science Department 256-80 5573 California Institute of Technology 5574 Pasadena, CA 91125 5575 USA 5576 electronic mail: schooler@cs.caltech.edu 5578 Jonathan Rosenberg 5579 Lucent Technologies, Bell Laboratories 5580 Rm. 4C-526 5581 101 Crawfords Corner Road 5582 Holmdel, NJ 07733 5583 USA 5584 electronic mail: jdrosen@bell-labs.com 5586 H Bibliography 5588 [1] R. Pandya, "Emerging mobile and personal communication systems," 5589 IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995. 5591 [2] B. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 5592 "Resource ReSerVation protocol (RSVP) -- version 1 functional 5593 specification," RFC 2205, Internet Engineering Task Force, Oct. 1997. 5595 [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 5596 transport protocol for real-time applications," RFC 1889, Internet 5597 Engineering Task Force, Jan. 1996. 5599 [4] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming 5600 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 5601 1998. 5603 [5] M. Handley and V. Jacobson, "SDP: session description protocol," 5604 RFC 2327, Internet Engineering Task Force, Apr. 1998. 5606 [6] S. Bradner, "Key words for use in RFCs to indicate requirement 5607 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 5609 [7] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners-Lee, 5610 "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 5611 Engineering Task Force, Jan. 1997. 5613 [8] T. Berners-Lee, L. Masinter, and R. Fielding, "Uniform resource 5614 identifiers (URI): generic syntax," Internet Draft, Internet 5615 Engineering Task Force, Mar. 1998. Work in progress. 5617 [9] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource 5618 locators (URL)," RFC 1738, Internet Engineering Task Force, Dec. 5619 1994. 5621 [10] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the 5622 location of services (DNS SRV)," RFC 2052, Internet Engineering Task 5623 Force, Oct. 1996. 5625 [11] C. Partridge, "Mail routing and the domain system," RFC STD 14, 5626 974, Internet Engineering Task Force, Jan. 1986. 5628 [12] P. Mockapetris, "Domain names - implementation and 5629 specification," RFC STD 13, 1035, Internet Engineering Task Force, 5630 Nov. 1987. 5632 [13] B. Braden, "Requirements for internet hosts - application and 5633 support," RFC STD 3, 1123, Internet Engineering Task Force, Oct. 5634 1989. 5636 [14] D. Zimmerman, "The finger user information protocol," RFC 1288, 5637 Internet Engineering Task Force, Dec. 1991. 5639 [15] S. Williamson, M. Kosters, D. Blacka, J. Singh, and K. Zeilstra, 5640 "Referral whois (rwhois) protocol V1.5," RFC 2167, Internet 5641 Engineering Task Force, June 1997. 5643 [16] W. Yeong, T. Howes, and S. Kille, "Lightweight directory access 5644 protocol," RFC 1777, Internet Engineering Task Force, Mar. 1995. 5646 [17] E. M. Schooler, "A multicast user directory service for 5647 synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of 5648 Computer Science, California Institute of Technology, Pasadena, 5649 California, Aug. 1996. 5651 [18] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 5652 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 5653 Task Force, Aug. 1998. 5655 [19] P. Leach and R. Salz, "UUIDs and GUIDs," Internet Draft, 5656 Internet Engineering Task Force, Feb. 1998. Work in progress. 5658 [20] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 5659 2279, Internet Engineering Task Force, Jan. 1998. 5661 [21] D. Crocker and P. Overell, "Augmented BNF for syntax 5662 specifications: ABNF," RFC 2234, Internet Engineering Task Force, 5663 Nov. 1997. 5665 [22] W. R. Stevens, TCP/IP illustrated: the protocols , vol. 1. 5666 Reading, Massachusetts: Addison-Wesley, 1994. 5668 [23] J. Mogul and S. Deering, "Path MTU discovery," RFC 1191, 5669 Internet Engineering Task Force, Nov. 1990. 5671 [24] D. Crocker, "Standard for the format of ARPA internet text 5672 messages," RFC STD 11, 822, Internet Engineering Task Force, Aug. 5673 1982. 5675 [25] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL 5676 scheme," RFC 2368, Internet Engineering Task Force, July 1998. 5678 [26] J. Palme, "Common internet message headers," RFC 2076, Internet 5679 Engineering Task Force, Feb. 1997. 5681 [27] J. Mogul, T. Berners-Lee, L. Masinter, P. Leach, R. Fielding, H. 5682 Nielsen, and J. Gettys, "Hypertext transfer protocol -- HTTP/1.1," 5683 Internet Draft, Internet Engineering Task Force, Mar. 1998. Work in 5684 progress. 5686 [28] M. Elkins, "MIME security with pretty good privacy (PGP)," RFC 5687 2015, Internet Engineering Task Force, Oct. 1996. 5689 [29] E. M. Schooler, "Case study: multimedia conference control in a 5690 packet-switched teleconferencing system," Journal of Internetworking: 5691 Research and Experience , vol. 4, pp. 99--120, June 1993. ISI 5692 reprint series ISI/RS-93-359. 5694 [30] H. Schulzrinne, "Personal mobility for multimedia services in 5695 the Internet," in European Workshop on Interactive Distributed 5696 Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar. 5697 1996. 5699 Full Copyright Statement 5701 Copyright (c) The Internet Society (1998). All Rights Reserved. 5703 This document and translations of it may be copied and furnished to 5704 others, and derivative works that comment on or otherwise explain it 5705 or assist in its implementation may be prepared, copied, published 5706 and distributed, in whole or in part, without restriction of any 5707 kind, provided that the above copyright notice and this paragraph are 5708 included on all such copies and derivative works. However, this 5709 document itself may not be modified in any way, such as by removing 5710 the copyright notice or references to the Internet Society or other 5711 Internet organizations, except as needed for the purpose of 5712 developing Internet standards in which case the procedures for 5713 copyrights defined in the Internet Standards process must be 5714 followed, or as required to translate it into languages other than 5715 English. 5717 The limited permissions granted above are perpetual and will not be 5718 revoked by the Internet Society or its successors or assigns. 5720 This document and the information contained herein is provided on an 5721 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 5722 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 5723 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 5724 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 5725 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5727 Table of Contents 5729 1 Introduction ........................................ 2 5730 1.1 Overview of SIP Functionality ....................... 2 5731 1.2 Terminology ......................................... 4 5732 1.3 Definitions ......................................... 4 5733 1.4 Summary of SIP Operation ............................ 7 5734 1.4.1 SIP Addressing ...................................... 7 5735 1.4.2 Locating a SIP Server ............................... 8 5736 1.4.3 SIP Transaction ..................................... 9 5737 1.4.4 SIP Invitation ...................................... 10 5738 1.4.5 Locating a User ..................................... 12 5739 1.4.6 Changing an Existing Session ........................ 14 5740 1.4.7 Registration Services ............................... 14 5741 1.5 Protocol Properties ................................. 14 5742 1.5.1 Minimal State ....................................... 14 5743 1.5.2 Lower-Layer-Protocol Neutral ........................ 14 5744 1.5.3 Text-Based .......................................... 15 5745 2 SIP Uniform Resource Locators ....................... 15 5746 3 SIP Message Overview ................................ 19 5747 4 Request ............................................. 20 5748 4.1 Request-Line ........................................ 22 5749 4.2 Methods ............................................. 22 5750 4.2.1 INVITE .............................................. 22 5751 4.2.2 ACK ................................................. 23 5752 4.2.3 OPTIONS ............................................. 24 5753 4.2.4 BYE ................................................. 24 5754 4.2.5 CANCEL .............................................. 24 5755 4.2.6 REGISTER ............................................ 25 5756 4.3 Request-URI ......................................... 27 5757 4.3.1 SIP Version ......................................... 28 5758 4.4 Option Tags ......................................... 28 5759 4.4.1 Registering New Option Tags with IANA ............... 29 5760 5 Response ............................................ 29 5761 5.1 Status-Line ......................................... 30 5762 5.1.1 Status Codes and Reason Phrases ..................... 30 5763 6 Header Field Definitions ............................ 31 5764 6.1 General Header Fields ............................... 35 5765 6.2 Entity Header Fields ................................ 36 5766 6.3 Request Header Fields ............................... 36 5767 6.4 Response Header Fields .............................. 36 5768 6.5 End-to-end and Hop-by-hop Headers ................... 36 5769 6.6 Header Field Format ................................. 36 5770 6.7 Accept .............................................. 37 5771 6.8 Accept-Encoding ..................................... 38 5772 6.9 Accept-Language ..................................... 38 5773 6.10 Allow ............................................... 38 5774 6.11 Authorization ....................................... 38 5775 6.12 Call-ID ............................................. 38 5776 6.13 Contact ............................................. 40 5777 6.14 Content-Encoding .................................... 42 5778 6.15 Content-Length ...................................... 43 5779 6.16 Content-Type ........................................ 43 5780 6.17 CSeq ................................................ 44 5781 6.18 Date ................................................ 45 5782 6.19 Encryption .......................................... 45 5783 6.20 Expires ............................................. 47 5784 6.21 From ................................................ 48 5785 6.22 Hide ................................................ 49 5786 6.23 Max-Forwards ........................................ 50 5787 6.24 Organization ........................................ 51 5788 6.25 Priority ............................................ 51 5789 6.26 Proxy-Authenticate .................................. 52 5790 6.27 Proxy-Authorization ................................. 52 5791 6.28 Proxy-Require ....................................... 52 5792 6.29 Record-Route ........................................ 53 5793 6.30 Require ............................................. 54 5794 6.31 Response-Key ........................................ 55 5795 6.32 Retry-After ......................................... 55 5796 6.33 Route ............................................... 56 5797 6.34 Server .............................................. 56 5798 6.35 Subject ............................................. 56 5799 6.36 Timestamp ........................................... 57 5800 6.37 To .................................................. 57 5801 6.38 Unsupported ......................................... 58 5802 6.39 User-Agent .......................................... 59 5803 6.40 Via ................................................. 59 5804 6.40.1 Requests ............................................ 59 5805 6.40.2 Receiver-tagged Via Fields .......................... 60 5806 6.40.3 Responses ........................................... 60 5807 6.40.4 Syntax .............................................. 61 5808 6.41 Warning ............................................. 62 5809 6.42 WWW-Authenticate .................................... 64 5810 7 Status Code Definitions ............................. 65 5811 7.1 Informational 1xx ................................... 65 5812 7.1.1 100 Trying .......................................... 65 5813 7.1.2 180 Ringing ......................................... 65 5814 7.1.3 181 Call Is Being Forwarded ......................... 65 5815 7.1.4 182 Queued .......................................... 66 5816 7.2 Successful 2xx ...................................... 66 5817 7.2.1 200 OK .............................................. 66 5818 7.3 Redirection 3xx ..................................... 66 5819 7.3.1 300 Multiple Choices ................................ 67 5820 7.3.2 301 Moved Permanently ............................... 67 5821 7.3.3 302 Moved Temporarily ............................... 67 5822 7.3.4 380 Alternative Service ............................. 67 5823 7.4 Request Failure 4xx ................................. 67 5824 7.4.1 400 Bad Request ..................................... 68 5825 7.4.2 401 Unauthorized .................................... 68 5826 7.4.3 402 Payment Required ................................ 68 5827 7.4.4 403 Forbidden ....................................... 68 5828 7.4.5 404 Not Found ....................................... 68 5829 7.4.6 405 Method Not Allowed .............................. 68 5830 7.4.7 406 Not Acceptable .................................. 68 5831 7.4.8 407 Proxy Authentication Required ................... 68 5832 7.4.9 408 Request Timeout ................................. 69 5833 7.4.10 409 Conflict ........................................ 69 5834 7.4.11 410 Gone ............................................ 69 5835 7.4.12 411 Length Required ................................. 69 5836 7.4.13 413 Request Entity Too Large ........................ 69 5837 7.4.14 414 Request-URI Too Long ............................ 70 5838 7.4.15 415 Unsupported Media Type .......................... 70 5839 7.4.16 420 Bad Extension ................................... 70 5840 7.4.17 480 Temporarily Unavailable ......................... 70 5841 7.4.18 481 Call Leg/Transaction Does Not Exist ............. 70 5842 7.4.19 482 Loop Detected ................................... 70 5843 7.4.20 483 Too Many Hops ................................... 70 5844 7.4.21 484 Address Incomplete .............................. 71 5845 7.4.22 485 Ambiguous ....................................... 71 5846 7.4.23 486 Busy Here ....................................... 71 5847 7.5 Server Failure 5xx .................................. 72 5848 7.5.1 500 Server Internal Error ........................... 72 5849 7.5.2 501 Not Implemented ................................. 72 5850 7.5.3 502 Bad Gateway ..................................... 72 5851 7.5.4 503 Service Unavailable ............................. 72 5852 7.5.5 504 Gateway Timeout ................................. 72 5853 7.5.6 505 Version Not Supported ........................... 72 5854 7.6 Global Failures 6xx ................................. 73 5855 7.6.1 600 Busy Everywhere ................................. 73 5856 7.6.2 603 Decline ......................................... 73 5857 7.6.3 604 Does Not Exist Anywhere ......................... 73 5858 7.6.4 606 Not Acceptable .................................. 73 5859 8 SIP Message Body .................................... 74 5860 8.1 Body Inclusion ...................................... 74 5861 8.2 Message Body Type ................................... 74 5862 8.3 Message Body Length ................................. 74 5863 9 Compact Form ........................................ 74 5864 10 Behavior of SIP Clients and Servers ................. 76 5865 10.1 General Remarks ..................................... 76 5866 10.1.1 Requests ............................................ 76 5867 10.1.2 Responses ........................................... 76 5868 10.2 Source Addresses, Destination Addresses and 5869 Connections .................................................... 77 5870 10.2.1 Unicast UDP ......................................... 77 5871 10.2.2 Multicast UDP ....................................... 77 5872 10.3 TCP ................................................. 78 5873 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER 5874 Requests ....................................................... 79 5875 10.4.1 UDP ................................................. 79 5876 10.4.2 TCP ................................................. 80 5877 10.5 Reliability for INVITE Requests ..................... 80 5878 10.5.1 UDP ................................................. 80 5879 10.5.2 TCP ................................................. 84 5880 10.6 Reliability for ACK Requests ........................ 84 5881 11 Behavior of SIP User Agents ......................... 84 5882 11.1 Caller Issues Initial INVITE Request ................ 84 5883 11.2 Callee Issues Response .............................. 85 5884 11.3 Caller Receives Response to Initial Request ......... 85 5885 11.4 Caller or Callee Generate Subsequent Requests ....... 85 5886 11.5 Receiving Subsequent Requests ....................... 86 5887 12 Behavior of SIP Proxy and Redirect Servers .......... 86 5888 12.1 Redirect Server ..................................... 86 5889 12.2 User Agent Server ................................... 86 5890 12.3 Proxy Server ........................................ 86 5891 12.3.1 Proxying Requests ................................... 87 5892 12.3.2 Proxying Responses .................................. 87 5893 12.3.3 Stateless Proxy: Proxying Responses ................. 87 5894 12.3.4 Stateful Proxy: Receiving Requests .................. 88 5895 12.3.5 Stateful Proxy: Receiving ACKs ...................... 88 5896 12.3.6 Stateful Proxy: Receiving Responses ................. 88 5897 12.3.7 Stateless, Non-Forking Proxy ........................ 88 5898 12.4 Forking Proxy ....................................... 89 5899 13 Security Considerations ............................. 93 5900 13.1 Confidentiality and Privacy: Encryption ............. 93 5901 13.1.1 End-to-End Encryption ............................... 93 5902 13.1.2 Privacy of SIP Responses ............................ 95 5903 13.1.3 Encryption by Proxies ............................... 96 5904 13.1.4 Hop-by-Hop Encryption ............................... 96 5905 13.1.5 Via field encryption ................................ 96 5906 13.2 Message Integrity and Access Control: 5907 Authentication ................................................. 97 5908 13.2.1 Trusting responses .................................. 99 5909 13.3 Callee Privacy ...................................... 100 5910 13.4 Known Security Problems ............................. 100 5911 14 SIP Security Using PGP .............................. 100 5912 14.1 PGP Authentication Scheme ........................... 100 5913 14.1.1 The WWW-Authenticate Response Header ................ 100 5914 14.1.2 The Authorization Request Header .................... 101 5915 14.2 PGP Encryption Scheme ............................... 102 5916 14.3 Response-Key Header Field for PGP ................... 103 5917 15 Examples ............................................ 103 5918 15.1 Registration ........................................ 104 5919 15.2 Invitation to a Multicast Conference ................ 105 5920 15.2.1 Request ............................................. 105 5921 15.2.2 Response ............................................ 106 5922 15.3 Two-party Call ...................................... 107 5923 15.4 Terminating a Call .................................. 109 5924 15.5 Forking Proxy ....................................... 110 5925 15.6 Redirects ........................................... 114 5926 15.7 Alternative Services ................................ 115 5927 15.8 Negotiation ......................................... 116 5928 15.9 OPTIONS Request ..................................... 117 5929 A Minimal Implementation .............................. 118 5930 A.1 Client .............................................. 118 5931 A.2 Server .............................................. 119 5932 A.3 Header Processing ................................... 119 5933 B Usage of SDP ........................................ 119 5934 C Summary of Augmented BNF ............................ 121 5935 D IANA Considerations ................................. 122 5936 E Changes in Version -09 .............................. 123 5937 F Acknowledgments ..................................... 124 5938 G Authors' Addresses .................................. 124 5939 H Bibliography ........................................ 125