idnits 2.17.1 draft-ietf-mmusic-sip-12.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 82 instances of too long lines in the document, the longest one being 34 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 69 instances of lines with non-RFC2606-compliant FQDNs in the document. == There is 18 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 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 is 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 213: '...Location servers MAY be co-located wit...' RFC 2119 keyword, line 243: '... server and MAY offer location se...' RFC 2119 keyword, line 287: '...lication program MAY be capable of act...' RFC 2119 keyword, line 357: '...h to send the request. A client SHOULD...' RFC 2119 keyword, line 358: '...n this information, but MAY follow the...' (509 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 204 has weird spacing: '...ment if they...' == Line 262 has weird spacing: '...ss type and...' == Line 294 has weird spacing: '...edirect proxy...' == Line 295 has weird spacing: '... server serv...' == Line 837 has weird spacing: '...Contact exter...' == (24 more instances...) == 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 (January 15, 1999) is 9205 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? '1' on line 6282 looks like a reference -- Missing reference section? '2' on line 6285 looks like a reference -- Missing reference section? '3' on line 6289 looks like a reference -- Missing reference section? '4' on line 6293 looks like a reference -- Missing reference section? '5' on line 6297 looks like a reference -- Missing reference section? '6' on line 6300 looks like a reference -- Missing reference section? '7' on line 6303 looks like a reference -- Missing reference section? '8' on line 6308 looks like a reference -- Missing reference section? '9' on line 6312 looks like a reference -- Missing reference section? '10' on line 6317 looks like a reference -- Missing reference section? '11' on line 6320 looks like a reference -- Missing reference section? '12' on line 6324 looks like a reference -- Missing reference section? '13' on line 6328 looks like a reference -- Missing reference section? '16' on line 6340 looks like a reference -- Missing reference section? '15' on line 6336 looks like a reference -- Missing reference section? '17' on line 6343 looks like a reference -- Missing reference section? '18' on line 6346 looks like a reference -- Missing reference section? '19' on line 6350 looks like a reference -- Missing reference section? '20' on line 6353 looks like a reference -- Missing reference section? '21' on line 6358 looks like a reference -- Missing reference section? '22' on line 6361 looks like a reference -- Missing reference section? '23' on line 6364 looks like a reference -- Missing reference section? '24' on line 6367 looks like a reference -- Missing reference section? '25' on line 6371 looks like a reference -- Missing reference section? '26' on line 6374 looks like a reference -- Missing reference section? 'H6' on line 1392 looks like a reference -- Missing reference section? '27' on line 6378 looks like a reference -- Missing reference section? '28' on line 6382 looks like a reference -- Missing reference section? '29' on line 6385 looks like a reference -- Missing reference section? '30' on line 6389 looks like a reference -- Missing reference section? '31' on line 6392 looks like a reference -- Missing reference section? '32' on line 6395 looks like a reference -- Missing reference section? '33' on line 6398 looks like a reference -- Missing reference section? '34' on line 6402 looks like a reference -- Missing reference section? '35' on line 6405 looks like a reference -- Missing reference section? '36' on line 6408 looks like a reference -- Missing reference section? '14' on line 6332 looks like a reference -- Missing reference section? '37' on line 6413 looks like a reference -- Missing reference section? '38' on line 6418 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 41 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-12.txt ISI/Columbia U./Caltech/Bell Labs. 5 January 15, 1999 6 Expires: July 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. SIP 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 In the parlance of telecommunications intelligent network services, 81 this is defined as: "Personal mobility is the ability of end users to 82 originate and receive calls and access subscribed telecommunication 83 services on any terminal in any location, and the ability of the 84 network to identify end users as they move. Personal mobility is 85 based on the use of a unique personal identity (i.e., personal 86 number)." [1]. Personal mobility complements terminal mobility, i.e., 87 the ability to maintain communications when moving a single end 88 system from one subnet to another. 90 SIP supports five facets of establishing and terminating multimedia 91 communications: 93 User location: determination of the end system to be used for 94 communication; 96 User capabilities: determination of the media and media parameters to 97 be used; 99 User availability: determination of the willingness of the called 100 party to engage in communications; 102 Call setup: "ringing", establishment of call parameters at both 103 called and calling party; 105 Call handling: including transfer and termination of calls. 107 SIP can also initiate multi-party calls using a multipoint control 108 unit (MCU) or fully-meshed interconnection instead of multicast. 109 Internet telephony gateways that connect Public Switched Telephone 110 Network (PSTN) parties can also use SIP to set up calls between them. 112 SIP is designed as part of the overall IETF multimedia data and 113 control architecture currently incorporating protocols such as RSVP 114 (RFC 2205 [2]) for reserving network resources, the real-time 115 transport protocol (RTP) (RFC 1889 [3]) for transporting real-time 116 data and providing QOS feedback, the real-time streaming protocol 117 (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media, 118 the session announcement protocol (SAP) [5] for advertising 119 multimedia sessions via multicast and the session description 120 protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions. 121 However, the functionality and operation of SIP does not depend on 122 any of these protocols. 124 SIP can also be used in conjunction with other call setup and 125 signaling protocols. In that mode, an end system uses SIP exchanges 126 to determine the appropriate end system address and protocol from a 127 given address that is protocol-independent. For example, SIP could be 128 used to determine that the party can be reached via H.323 [7], obtain 129 the H.245 [8] gateway and user address and then use H.225.0 [9] to 130 establish the call. 132 In another example, SIP might be used to determine that the callee is 133 reachable via the PSTN and indicate the phone number to be called, 134 possibly suggesting an 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 [10] 150 and 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 [11]). The terms and generic 158 syntax of URI and URL are defined in RFC 2396 [12]. The following 159 terms have special significance for 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 167 multiparty conference unit (MCU) based call-in conference, each 168 participant uses a separate call 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 sends SIP requests. Clients may 174 or may not interact directly with a human user. User agents and 175 proxies contain clients (and servers). 177 Conference: A multimedia session (see below), identified by a common 178 session description. A conference can have zero or more members 179 and includes the cases of a multicast conference, a full-mesh 180 conference and a two-party "telephone call", as well as 181 combinations of these. Any number of calls can be used to 182 create a conference. 184 Downstream: Requests sent in the direction from the caller to the 185 callee (i.e., user agent client to user agent server). 187 Final response: A response that terminates a SIP transaction, as 188 opposed to a provisional response that does not. All 2xx, 3xx, 189 4xx, 5xx and 6xx responses are final. 191 Initiator, calling party, caller: The party initiating a conference 192 invitation. Note that the calling party does not have to be the 193 same as the one creating the conference. 195 Invitation: A request sent to a user (or service) requesting 196 participation in a session. A successful SIP invitation consists 197 of two transactions: an INVITE request followed by an ACK 198 request. 200 Invitee, invited user, called party, callee: The person or service 201 that the calling party is trying to invite to a conference. 203 Isomorphic request or response: Two requests or responses are defined 204 to be isomorphic for the purposes of this document if they have 205 the same values for the Call-ID, To, From and CSeq header 206 fields. In addition, requests have to have the same Request-URI. 208 Location server: See location service. 210 Location service: A location service is used by a SIP redirect or 211 proxy server to obtain information about a callee's possible 212 location(s). Location services are offered by location servers. 213 Location servers MAY be co-located with a SIP server, but the 214 manner in which a SIP server requests location services is 215 beyond the scope of this document. 217 Parallel search: In a parallel search, a proxy issues several 218 requests to possible user locations upon receiving an incoming 219 request. Rather than issuing one request and then waiting for 220 the final response before issuing the next request as in a 221 sequential search , a parallel search issues requests without 222 waiting for the result of previous requests. 224 Provisional response: A response used by the server to indicate 225 progress, but that does not terminate a SIP transaction. 1xx 226 responses are provisional, other responses are considered final. 228 Proxy, proxy server: An intermediary program that acts as both a 229 server and a client for the purpose of making requests on behalf 230 of other clients. Requests are serviced internally or by passing 231 them on, possibly after translation, to other servers. A proxy 232 interprets, and, if necessary, rewrites a request message before 233 forwarding it. 235 Redirect server: A redirect server is a server that accepts a SIP 236 request, maps the address into zero or more new addresses and 237 returns these addresses to the client. Unlike a proxy server , 238 it does not initiate its own SIP request. Unlike a user agent 239 server , it does not accept calls. 241 Registrar: A registrar is a server that accepts REGISTER requests. A 242 registrar is typically co-located with a proxy or redirect 243 server and MAY offer location services. 245 Ringback: Ringback is the signaling tone produced by the calling 246 client's application indicating that a called party is being 247 alerted (ringing). 249 Server: A server is an application program that accepts requests in 250 order to service requests and sends back responses to those 251 requests. Servers are either proxy, redirect or user agent 252 servers or registrars. 254 Session: From the SDP specification: "A multimedia session is a set 255 of multimedia senders and receivers and the data streams flowing 256 from senders to receivers. A multimedia conference is an example 257 of a multimedia session." (RFC 2327 [6]) (A session as defined 258 for SDP can comprise one or more RTP sessions.) As defined, a 259 callee can be invited several times, by different calls, to the 260 same session. If SDP is used, a session is defined by the 261 concatenation of the user name , session id , network type , 262 address type and address elements in the origin field. 264 (SIP) transaction: A SIP transaction occurs between a client and a 265 server and comprises all messages from the first request sent 266 from the client to the server up to a final (non-1xx) response 267 sent from the server to the client. A transaction is identified 268 by the CSeq sequence number (Section 6.17) within a single call 269 leg. The ACK request has the same CSeq number as the 270 corresponding INVITE request, but comprises a transaction of its 271 own. 273 Upstream: Responses sent in the direction from the user agent server 274 to the user agent client. 276 URL-encoded: A character string encoded according to RFC 1738, 277 Section 2.2 [13]. 279 User agent client (UAC), calling user agent: A user agent client is a 280 client application that initiates the SIP request. 282 User agent server (UAS), called user agent: A user agent server is a 283 server application that contacts the user when a SIP request is 284 received and that returns a response on behalf of the user. The 285 response accepts, rejects or redirects the request. 287 An application program MAY be capable of acting both as a client and 288 a server. For example, a typical multimedia conference control 289 application would act as a user agent client to initiate calls or to 290 invite others to conferences and as a user agent server to accept 291 invitations. The properties of the different SIP server types are 292 summarized in Table 1. 294 property redirect proxy user agent registrar 295 server server server 296 __________________________________________________________________ 297 also acts as a SIP client no yes no no 298 returns 1xx status yes yes yes yes 299 returns 2xx status no yes yes yes 300 returns 3xx status yes yes yes yes 301 returns 4xx status yes yes yes yes 302 returns 5xx status yes yes yes yes 303 returns 6xx status no yes yes no 304 inserts Via header no yes no no 305 accepts ACK yes yes yes no 307 Table 1: Properties of the different SIP server types 309 1.4 Overview of SIP Operation 311 This section explains the basic protocol functionality and operation. 312 Callers and callees are identified by SIP addresses, described in 313 Section 1.4.1. When making a SIP call, a caller first locates the 314 appropriate server (Section 1.4.2) and then sends a SIP request 315 (Section 1.4.3). The most common SIP operation is the invitation 316 (Section 1.4.4). Instead of directly reaching the intended callee, a 317 SIP request may be redirected or may trigger a chain of new SIP 318 requests by proxies (Section 1.4.5). Users can register their 319 location(s) with SIP servers (Section 4.2.6). 321 1.4.1 SIP Addressing 323 The "objects" addressed by SIP are users at hosts, identified by a 324 SIP URL. The SIP URL takes a form similar to a mailto or telnet URL, 325 i.e., user@host. The user part is a user name or a telephone number. 326 The host part is either a domain name or a numeric network address. 327 See section 2 for a detailed discussion of SIP URL's. 329 A user's SIP address can be obtained out-of-band, can be learned via 330 existing media agents, can be included in some mailers' message 331 headers, or can be recorded during previous invitation interactions. 332 In many cases, a user's SIP URL can be guessed from their email 333 address. 335 A SIP URL address can designate an individual (possibly located at 336 one of several end systems), the first available person from a group 337 of individuals or a whole group. The form of the address, for 338 example, sip:sales@example.com , is not sufficient, in general, to 339 determine the intent of the caller. 341 If a user or service chooses to be reachable at an address that is 342 guessable from the person's name and organizational affiliation, the 343 traditional method of ensuring privacy by having an unlisted "phone" 344 number is compromised. However, unlike traditional telephony, SIP 345 offers authentication and access control mechanisms and can avail 346 itself of lower-layer security mechanisms, so that client software 347 can reject unauthorized or undesired call attempts. 349 1.4.2 Locating a SIP Server 351 When a client wishes to send a request, the client either sends it to 352 a locally configured SIP proxy server (as in HTTP), independent of 353 the Request-URI, or sends it to the IP address and port corresponding 354 to the Request-URI. 356 For the latter case, the client must determine the protocol, port and 357 IP address of a server to which to send the request. A client SHOULD 358 follow the steps below to obtain this information, but MAY follow the 359 alternative, optional procedure defined in Appendix D. At each step, 360 unless stated otherwise, the client SHOULD try to contact a server at 361 the port number listed in the Request-URI. If no port number is 362 present in the Request-URI, the client uses port 5060. If the 363 Request-URI specifies a protocol (TCP or UDP), the client contacts 364 the server using that protocol. If no protocol is specified, the 365 client tries UDP (if UDP is supported). If the attempt fails, or if 366 the client doesn't support UDP but supports TCP, it then tries TCP. 368 A client SHOULD be able to interpret explicit network notifications 369 (such as ICMP messages) which indicate that a server is not 370 reachable, rather than relying solely on timeouts. (For socket-based 371 programs: For TCP, connect() returns ECONNREFUSED if the client could 372 not connect to a server at that address. For UDP, the socket needs to 373 be bound to the destination address using connect() rather than 374 sendto() or similar so that a second write() fails with ECONNREFUSED 375 if there is no server listening) If the client finds the server is 376 not reachable at a particular address, it SHOULD behave as if it had 377 received a 400-class error response to that request. 379 The client tries to find one or more addresses for the SIP server by 380 querying DNS. The procedure is as follows: 382 1. If the host portion of the Request-URI is an IP address, 383 the client contacts the server at the given address. 384 Otherwise, the client proceeds to the next step. 386 2. The client queries the DNS server for address records for 387 the host portion of the Request-URI. If the DNS server 388 returns no address records, the client stops, as it has 389 been unable to locate a server. By address record, we mean 390 A RR's, AAAA RR's, or other similar address records, chosen 391 according to the client's network protocol capabilities. 393 There are no mandatory rules on how to select a host name 394 for a SIP server. Users are encouraged to name their SIP 395 servers using the sip.domainname (i.e., sip.example.com) 396 convention, as specified in RFC 2219 [16]. Users may only 397 know an email address instead of a full SIP URL for a 398 callee, however. In that case, implementations may be able 399 to increase the likelihood of reaching a SIP server for 400 that domain by constructing a SIP URL from that email 401 address by prefixing the host name with "sip.". In the 402 future, this mechanism is likely to become unnecessary as 403 better DNS techniques, such as the one in Appendix D, 404 become widely available. 406 A client MAY cache a successful DNS query result. A successful query 407 is one which contained records in the answer, and a server was 408 contacted at one of the addresses from the answer. When the client 409 wishes to send a request to the same host, it MUST start the search 410 as if it had just received this answer from the name server. The 411 client MUST follow the procedures in RFC1035 [15] regarding DNS cache 412 invalidation when the DNS time-to-live expires. 414 1.4.3 SIP Transaction 416 Once the host part has been resolved to a SIP server, the client 417 sends one or more SIP requwwests to that server and receives one or 418 more responses from the server. A request (and its retransmissions) 419 together with the responses triggered by that request make up a SIP 420 transaction. All responses to a request contain the same values in 421 the Call-ID, CSeq, To, and From fields (with the possible addition of 422 a tag in the To field (section 6.37)). This allows responses to be 423 matched with requests. The ACK request following an INVITE is not 424 part of the transaction since it may traverse a different set of 425 hosts. 427 If TCP is used, request and responses within a single SIP transaction 428 are carried over the same TCP connection (see Section 10). Several 429 SIP requests from the same client to the same server MAY use the same 430 TCP connection or MAY use a new connection for each request. 432 If the client sent the request via unicast UDP, the response is sent 433 to the address contained in the next Via header field (Section 6.40) 434 of the response. If the request is sent via multicast UDP, the 435 response is directed to the same multicast address and destination 436 port. For UDP, reliability is achieved using retransmission (Section 437 10). 439 The SIP message format and operation is independent of the transport 440 protocol. 442 1.4.4 SIP Invitation 444 A successful SIP invitation consists of two requests, INVITE followed 445 by ACK. The INVITE (Section 4.2.1) request asks the callee to join a 446 particular conference or establish a two-party conversation. After 447 the callee has agreed to participate in the call, the caller confirms 448 that it has received that response by sending an ACK (Section 4.2.2) 449 request. If the caller no longer wants to participate in the call, it 450 sends a BYE request instead of an ACK. 452 The INVITE request typically contains a session description, for 453 example written in SDP (RFC 2327 [6]) format, that provides the 454 called party with enough information to join the session. For 455 multicast sessions, the session description enumerates the media 456 types and formats that are allowed to be distributed to that session. 457 For a unicast session, the session description enumerates the media 458 types and formats that the caller is willing to receive and where it 459 wishes the media data to be sent. In either case, if the callee 460 wishes to accept the call, it responds to the invitation by returning 461 a similar description listing the media it wishes to receive. For a 462 multicast session, the callee SHOULD only return a session 463 description if it is unable to receive the media indicated in the 464 caller's description or wants to receive data via unicast. 466 The protocol exchanges for the INVITE method are shown in Fig. 1 for 467 a proxy server and in Fig. 2 for a redirect server. (Note that the 468 messages shown in the figures have been abbreviated slightly.) In 469 Fig. 1, the proxy server accepts the INVITE request (step 1), 470 contacts the location service with all or parts of the address (step 471 2) and obtains a more precise location (step 3). The proxy server 472 then issues a SIP INVITE request to the address(es) returned by the 473 location service (step 4). The user agent server alerts the user 474 (step 5) and returns a success indication to the proxy server (step 475 6). The proxy server then returns the success result to the original 476 caller (step 7). The receipt of this message is confirmed by the 477 caller using an ACK request, which is forwarded to the callee (steps 478 8 and 9). Note that an ACK can also be sent directly to the callee, 479 bypassing the proxy. All requests and responses have the same Call- 480 ID. 482 +....... cs.columbia.edu .......+ 483 : : 484 : (~~~~~~~~~~) : 485 : ( location ) : 486 : ( service ) : 487 : (~~~~~~~~~~) : 488 : ^ | : 489 : | hgs@lab : 490 : 2| 3| : 491 : | | : 492 : henning | : 493 +.. cs.tu-berlin.de ..+ 1: INVITE : | | : 494 : : henning@cs.col: | \/ 4: INVITE 5: ring : 495 : cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) : 496 : <........................( )<.........( ) : 497 : : 7: 200 OK : ( )6: 200 OK ( ) : 498 : : : ( work ) ( lab ) : 499 : : 8: ACK : ( )9: ACK ( ) : 500 : ========================>(~~~~~~)=========>(~~~~~~) : 501 +.....................+ +...............................+ 503 ====> SIP request 504 ....> SIP response 506 ^ 507 | non-SIP protocols 508 | 510 Figure 1: Example of SIP proxy server 512 The redirect server shown in Fig. 2 accepts the INVITE request (step 513 1), contacts the location service as before (steps 2 and 3) and, 514 instead of contacting the newly found address itself, returns the 515 address to the caller (step 4), which is then acknowledged via an ACK 516 request (step 5). The caller issues a new request, with the same 517 call-ID but a higher CSeq, to the address returned by the first 518 server (step 6). In the example, the call succeeds (step 7). The 519 caller and callee complete the handshake with an ACK (step 8). 521 The next section discusses what happens if the location service 522 returns more than one possible alternative. 524 1.4.5 Locating a User 526 A callee may move between a number of different end systems over 527 time. These locations can be dynamically registered with the SIP 528 server (Sections 1.4.7, 4.2.6). A location server MAY also use one or 529 more other protocols, such as finger (RFC 1288 [17]), rwhois (RFC 530 2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20] or 531 operating-system dependent mechanisms to actively determine the end 532 system where a user might be reachable. A location server MAY return 533 several locations because the user is logged in at several hosts 534 simultaneously or because the location server has (temporarily) 535 inaccurate information. The SIP server combines the results to yield 536 a list of a zero or more locations. 538 The action taken on receiving a list of locations varies with the 539 type of SIP server. A SIP redirect server returns the list to the 540 client as Contact headers (Section 6.13). A SIP proxy server can 541 sequentially or in parallel try the addresses until the call is 542 successful (2xx response) or the callee has declined the call (6xx 543 response). With sequential attempts, a proxy server can implement an 544 "anycast" service. 546 If a proxy server forwards a SIP request, it MUST add itself to the 547 end of the list of forwarders noted in the Via (Section 6.40) 548 headers. The Via trace ensures that replies can take the same path 549 back, ensuring correct operation through compliant firewalls and 550 avoiding request loops. On the response path, each host MUST remove 551 its Via, so that routing internal information is hidden from the 552 callee and outside networks. A proxy server MUST check that it does 553 not generate a request to a host listed in the Via sent-by, via- 554 received or via-maddr parameters (Section 6.40). (Note: If a host has 555 several names or network addresses, this does not always work. Thus, 556 each host also checks if it is part of the Via list.) 558 A SIP invitation may traverse more than one SIP proxy server. If one 559 of these "forks" the request, i.e., issues more than one request in 560 response to receiving the invitation request, it is possible that a 561 client is reached, independently, by more than one copy of the 562 invitation request. Each of these copies bears the same Call-ID. The 563 user agent MUST return the same status response returned in the first 564 response. Duplicate requests are not an error. 566 1.4.6 Changing an Existing Session 568 In some circumstances, it is desirable to change the parameters of an 569 existing session. This is done by re-issuing the INVITE, using the 570 same Call-ID, but a new or different body or header fields to convey 571 the new information. This re INVITE MUST have a higher CSeq than any 572 previous request from the client to the server. 574 For example, two parties may have been conversing and then want to 575 add a third party, switching to multicast for efficiency. One of the 576 participants invites the third party with the new multicast address 577 and simultaneously sends an INVITE to the second party, with the new 578 multicast session description, but with the old call identifier. 580 1.4.7 Registration Services 582 The REGISTER request allows a client to let a proxy or redirect 583 server know at which address(es) it can be reached. A client MAY also 584 use it to install call handling features at the server. 586 1.5 Protocol Properties 588 1.5.1 Minimal State 590 A single conference session or call involves one or more SIP 591 request-response transactions. Proxy servers do not have to keep 592 state for a particular call, however, they MAY maintain state for a 593 single SIP transaction, as discussed in Section 12. For efficiency, a 594 server MAY cache the results of location service requests. 596 1.5.2 Lower-Layer-Protocol Neutral 598 SIP makes minimal assumptions about the underlying transport and 599 network-layer protocols. The lower-layer can provide either a packet 600 or a byte stream service, with reliable or unreliable service. 602 In an Internet context, SIP is able to utilize both UDP and TCP as 603 transport protocols, among others. UDP allows the application to more 604 carefully control the timing of messages and their retransmission, to 605 perform parallel searches without requiring TCP connection state for 606 each outstanding request, and to use multicast. Routers can more 607 readily snoop SIP UDP packets. TCP allows easier passage through 608 existing firewalls. 610 When TCP is used, SIP can use one or more connections to attempt to 611 contact a user or to modify parameters of an existing conference. 612 Different SIP requests for the same SIP call MAY use different TCP 613 connections or a single persistent connection, as appropriate. 615 +....... cs.columbia.edu .......+ 616 : : 617 : (~~~~~~~~~~) : 618 : ( location ) : 619 : ( service ) : 620 : (~~~~~~~~~~) : 621 : ^ | : 622 : | hgs@lab : 623 : 2| 3| : 624 : | | : 625 : henning| : 626 +.. cs.tu-berlin.de ..+ 1: INVITE : | | : 627 : : henning@cs.col: | \/ : 628 : cz@cs.tu-berlin.de =======================>(~~~~~~) : 629 : | ^ | <.......................( ) : 630 : | . | : 4: 302 Moved : ( ) : 631 : | . | : hgs@lab : ( work ) : 632 : | . | : : ( ) : 633 : | . | : 5: ACK : ( ) : 634 : | . | =======================>(~~~~~~) : 635 : | . | : : : 636 +.......|...|.........+ : : 637 | . | : : 638 | . | : : 639 | . | : : 640 | . | : : 641 | . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) : 642 | . ==================================================> ( ) : 643 | ..................................................... ( ) : 644 | 7: 200 OK : ( lab ) : 645 | : ( ) : 646 | 8: ACK : ( ) : 647 ======================================================> (~~~~~~) : 648 +...............................+ 650 ====> SIP request 651 ....> SIP response 653 ^ 654 | non-SIP protocols 655 | 657 Figure 2: Example of SIP redirect server 658 For concreteness, this document will only refer to Internet 659 protocols. However, SIP MAY also be used directly with protocols 660 such as ATM AAL5, IPX, frame relay or X.25. The necessary naming 661 conventions are beyond the scope of this document. User agents SHOULD 662 implement both UDP and TCP transport. Proxy, registrar, and redirect 663 servers MUST implement both UDP and TCP transport. 665 1.5.3 Text-Based 667 SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This 668 allows easy implementation in languages such as Java, Tcl and Perl, 669 allows easy debugging, and most importantly, makes SIP flexible and 670 extensible. As SIP is used for initiating multimedia conferences 671 rather than delivering media data, it is believed that the additional 672 overhead of using a text-based protocol is not significant. 674 2 SIP Uniform Resource Locators 676 SIP URLs are used within SIP messages to indicate the originator 677 (From), current destination (Request-URI) and final recipient (To) of 678 a SIP request, and to specify redirection addresses (Contact). A SIP 679 URL can also be embedded in web pages or other hyperlinks to indicate 680 that a particular user or service can be called via SIP. When used as 681 a hyperlink, the SIP URL indicates the use of the INVITE method. 683 The SIP URL scheme is defined to allow setting SIP request-header 684 fields and the SIP message-body. 686 This corresponds to the use of mailto: URLs. It makes it 687 possible, for example, to specify the subject, urgency or 688 media types of calls initiated through a web page or as 689 part of an email message. 691 A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax 692 shown in Fig. 3. The syntax is described using Augmented Backus-Naur 693 Form (See Section C). Note that reserved characters have to be 694 escaped and that the "set of characters reserved within any given URI 695 component is defined by that component. In general, a character is 696 reserved if the semantics of the URI changes if the character is 697 replaced with its escaped US-ASCII encoding" [12]. 699 The URI character classes referenced above are described in Appendix 700 C. 702 The components of the SIP URI have the following meanings. 704 SIP-URL = "sip:" [ userinfo "@" ] hostport 705 url-parameters [ headers ] 706 userinfo = user [ ":" password ] 707 user = *( unreserved | escaped 708 | "&" | "=" | "+" | "$" | "," ) 709 password = *( unreserved | escaped 710 | "&" | "=" | "+" | "$" | "," ) 711 hostport = host [ ":" port ] 712 host = hostname | IPv4address 713 hostname = *( domainlabel "." ) toplabel [ "." ] 714 domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum 715 toplabel = alpha | alpha *( alphanum | "-" ) alphanum 716 IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit 717 port = *digit 718 url-parameters = *( ";" url-parameter ) 719 url-parameter = transport-param | user-param | method-param 720 | ttl-param | maddr-param | other-param 721 transport-param = "transport=" ( "udp" | "tcp" ) 722 ttl-param = "ttl=" ttl 723 ttl = 1*3DIGIT ; 0 to 255 724 maddr-param = "maddr=" host 725 user-param = "user=" ( "phone" | "ip" ) 726 method-param = "method=" Method 727 tag-param = "tag=" UUID 728 UUID = 1*( hex | "-" ) 729 other-param = ( token | ( token "=" ( token | quoted-string ))) 730 headers = "?" header *( "&" header ) 731 header = hname "=" hvalue 732 hname = 1*uric 733 hvalue = *uric 734 uric = reserved | unreserved | escaped 735 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | 736 "$" | "," 737 digits = 1*DIGIT 739 Figure 3: SIP URL syntax 741 user: If the host is an Internet telephony gateway, the user field 742 MAY also encode a telephone number using the notation of 743 telephone-subscriber (Fig. 4). The telephone number is a special 744 case of a user name and cannot be distinguished by a BNF. Thus, 745 a URL parameter, user, is added to distinguish telephone numbers 746 from user names. The phone identifier is to be used when 747 connecting to a telephony gateway. Even without this parameter, 749 telephone-subscriber = global-phone-number | local-phone-number 750 global-phone-number = "+" 1*phonedigit [isdn-subaddress] 751 [post-dial] 752 local-phone-number = 1*(phonedigit | dtmf-digit | 753 pause-character) [isdn-subaddress] 754 [post-dial] 755 isdn-subaddress = ";" "isub=" 1*phonedigit 756 post-dial = ";" "postd=" 1*(phonedigit | dtmf-digit 757 | pause-character) 758 phonedigit = DIGIT | visual-separator 759 visual-separator = "-" | "." 760 pause-character = one-second-pause | wait-for-dial-tone 761 one-second-pause = "p" 762 wait-for-dial-tone = "w" 763 dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D" 765 Figure 4: SIP URL syntax; telephone subscriber 767 recipients of SIP URLs MAY interpret the pre-@ part as a phone 768 number if local restrictions on the name space for user name 769 allow it. 771 password: The SIP scheme MAY use the format "user:password" in the 772 userinfo field. The use of passwords in the userinfo is NOT 773 RECOMMENDED, because the passing of authentication information 774 in clear text (such as URIs) has proven to be a security risk in 775 almost every case where it has been used. 777 host: The mailto: URL and RFC 822 email addresses require that 778 numeric host addresses ("host numbers") are enclosed in square 779 brackets (presumably, since host names might be numeric), while 780 host numbers without brackets are used for all other URLs. The 781 SIP URL requires the latter form, without brackets. 783 The issue of IPv6 literal addresses in URLs is being looked at 784 elsewhere in the IETF. SIP implementers are advised to keep up to 785 date on that activity. 787 port: The port number to send a request to. If not present, the 788 procedures outlined in Section 1.4.2 are used to determine the 789 port number to send a request to. 791 URL parameters: SIP URLs can define specific parameters of the 792 request. URL parameters are added after the host component and 793 are separated by semi-colons. The transport parameter determines 794 the the transport mechanism (UDP or TCP). UDP is to be assumed 795 when no explicit transport parameter is included. The maddr 796 parameter provides the server address to be contacted for this 797 user, overriding the address supplied in the host field. This 798 address is typically a multicast address, but could also be the 799 address of a backup server. The ttl parameter determines the 800 time-to-live value of the UDP multicast packet and MUST only be 801 used if maddr is a multicast address and the transport protocol 802 is UDP. The user parameter was described above. For example, to 803 specify to call j.doe@big.com using multicast to 239.255.255.1 804 with a ttl of 15, the following URL would be used: 806 sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 808 The transport, maddr, and ttl parameters MUST NOT be used in the From 809 and To header fields and the Request-URI; they are ignored if 810 present. 812 Headers: Headers of the SIP request can be defined with the "?" 813 mechanism within a SIP URL. The special hname "body" indicates 814 that the associated hvalue is the message-body of the SIP INVITE 815 request. Headers MUST NOT be used in the From and To header 816 fields and the Request-URI; they are ignored if present. hname 817 and hvalue are encodings of a SIP header name and value, 818 respectively. All URL reserved characters in the header names 819 and values MUST be escaped. 821 Method: The method of the SIP request can be specified with the 822 method parameter. This parameter MUST NOT be used in the From 823 and To header fields and the Request-URI; they are ignored if 824 present. 826 Table 2 summarizes where the components of the SIP URL can be used 827 and what default values they assume if not present. 829 Examples of SIP URLs are: 831 sip:j.doe@big.com 832 sip:j.doe:secret@big.com;transport=tcp 833 sip:j.doe@big.com?subject=project 834 sip:+1-212-555-1212:1234@gateway.com;user=phone 835 sip:1212@gateway.com 836 sip:alice@10.1.2.3 837 default Req.-URI To From Contact external 838 user -- x x x x x 839 password -- x x x x 840 host mandatory x x x x x 841 port 5060 x x x x x 842 user-param ip x x x x x 843 method INVITE x x 844 maddr-param -- x x 845 ttl-param 1 x x 846 transp.-param -- x x 847 headers -- x x 849 Table 2: Use and default values of URL components for SIP headers, 850 Request-URI and references 852 sip:alice@example.com 853 sip:alice 854 sip:alice@registrar.com;method=REGISTER 856 Within a SIP message, URLs are used to indicate the source and 857 intended destination of a request, redirection addresses and the 858 current destination of a request. Normally all these fields will 859 contain SIP URLs. 861 SIP URLs are case-insensitive, so that for example the two URLs 862 sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent. All 863 URL parameters are included when comparing SIP URLs for equality. 865 SIP header fields MAY contain non-SIP URLs. As an example, if a call 866 from a telephone is relayed to the Internet via SIP, the SIP From 867 header field might contain a phone URL. 869 3 SIP Message Overview 871 SIP is a text-based protocol and uses the ISO 10646 character set in 872 UTF-8 encoding (RFC 2279 [21]). Senders MUST terminate lines with a 873 CRLF, but receivers MUST also interpret CR and LF by themselves as 874 line terminators. 876 Except for the above difference in character sets, much of the 877 message syntax is and header fields are identical to HTTP/1.1; rather 878 than repeating the syntax and semantics here we use [HX.Y] to refer 879 to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [11]). 880 In addition, we describe SIP in both prose and an augmented Backus- 881 Naur form (ABNF). See section C for an overview of ABNF. 883 Note, however, that SIP is not an extension of HTTP. 885 Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP 886 transactions can be carried in a single TCP connection or UDP 887 datagram. UDP datagrams, including all headers, SHOULD NOT be larger 888 than the path maximum transmission unit (MTU) if the MTU is known, or 889 1500 bytes if the MTU is unknown. 891 The 1500 bytes accommodates encapsulation within the 892 "typical" ethernet MTU without IP fragmentation. Recent 893 studies [22] indicate that an MTU of 1500 bytes is a 894 reasonable assumption. The next lower common MTU values are 895 1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191 896 [23]). Thus, another reasonable value would be a message 897 size of 950 bytes, to accommodate packet headers within the 898 SLIP MTU without fragmentation. 900 A SIP message is either a request from a client to a server, or a 901 response from a server to a client. 903 SIP-message = Request | Response 905 Both Request (section 4) and Response (section 5) messages use the 906 generic-message format of RFC 822 [24] for transferring entities (the 907 body of the message). Both types of messages consist of a start-line, 908 one or more header fields (also known as "headers"), an empty line 909 (i.e., a line with nothing preceding the carriage-return line-feed 910 (CRLF)) indicating the end of the header fields, and an optional 911 message-body. To avoid confusion with similar-named headers in HTTP, 912 we refer to the headers describing the message body as entity 913 headers. These components are described in detail in the upcoming 914 sections. 916 generic-message = start-line 917 *message-header 918 CRLF 919 [ message-body ] 921 start-line = Request-Line | ;Section 4.1 922 Status-Line ;Section 5.1 924 message-header = ( general-header 925 | request-header 926 | response-header 927 | entity-header ) 929 In the interest of robustness, any leading empty line(s) MUST be 930 ignored. In other words, if the Request or Response message begins 931 with one or more CRLF, CR, or LFs, these characters MUST be ignored. 933 4 Request 935 The Request message format is shown below: 937 Request = Request-Line ; Section 4.1 938 *( general-header 939 | request-header 940 | entity-header ) 941 CRLF 942 [ message-body ] ; Section 8 944 4.1 Request-Line 946 The Request-Line begins with a method token, followed by the 947 Request-URI and the protocol version, and ending with CRLF. The 948 elements are separated by SP characters. No CR or LF are allowed 949 except in the final CRLF sequence. 951 Request-Line = Method SP Request-URI SP SIP-Version CRLF 953 4.2 Methods 955 The methods are defined below. Methods that are not supported by a 956 proxy or redirect server are treated by that server as if they were 957 an OPTIONS method and forwarded accordingly. Methods that are not 958 supported by a user agent server or registrar cause a 501 (Not 959 Implemented) response to be returned (Section 7). As in HTTP, the 960 Method token is case-sensitive. 962 general-header = Accept ; Section 6.7 963 | Accept-Encoding ; Section 6.8 964 | Accept-Language ; Section 6.9 965 | Call-ID ; Section 6.12 966 | Contact ; Section 6.13 967 | CSeq ; Section 6.17 968 | Date ; Section 6.18 969 | Encryption ; Section 6.19 970 | Expires ; Section 6.20 971 | From ; Section 6.21 972 | Record-Route ; Section 6.29 973 | Timestamp ; Section 6.36 974 | To ; Section 6.37 975 | Via ; Section 6.40 976 entity-header = Content-Encoding ; Section 6.14 977 | Content-Length ; Section 6.15 978 | Content-Type ; Section 6.16 979 request-header = Authorization ; Section 6.11 980 | Contact ; Section 6.13 981 | Hide ; Section 6.22 982 | Max-Forwards ; Section 6.23 983 | Organization ; Section 6.24 984 | Priority ; Section 6.25 985 | Proxy-Authorization ; Section 6.27 986 | Proxy-Require ; Section 6.28 987 | Route ; Section 6.33 988 | Require ; Section 6.30 989 | Response-Key ; Section 6.31 990 | Subject ; Section 6.35 991 | User-Agent ; Section 6.39 992 response-header = Allow ; Section 6.10 993 | Proxy-Authenticate ; Section 6.26 994 | Retry-After ; Section 6.32 995 | Server ; Section 6.34 996 | Unsupported ; Section 6.38 997 | Warning ; Section 6.41 998 | WWW-Authenticate ; Section 6.42 1000 Table 3: SIP headers 1002 Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" 1003 | "CANCEL" | "REGISTER" 1005 4.2.1 INVITE 1006 The INVITE method indicates that the user or service is being invited 1007 to participate in a session. The message body contains a description 1008 of the session to which the callee is being invited. For two-party 1009 calls, the caller indicates the type of media it is able to receive 1010 and possibly the media it is willing to send as well as their 1011 parameters such as network destination. A success response MUST 1012 indicate in its message body which media the callee wishes to receive 1013 and MAY indicate the media the callee is going to send. 1015 Not all session description formats have the ability to 1016 indicate sending media. 1018 A server MAY automatically respond to an invitation for a conference 1019 the user is already participating in, identified either by the SIP 1020 Call-ID or a globally unique identifier within the session 1021 description, with a 200 (OK) response. 1023 If a user agent receives an INVITE request for an existing call leg 1024 with a higher CSeq sequence number than any previous INVITE for the 1025 same Call-ID, it MUST check any version identifiers in the session 1026 description or, if there are no version identifiers, the content of 1027 the session description to see if it has changed. It MUST also 1028 inspect any other header fields for changes. If there is a change, 1029 the user agent MUST update any internal state or information 1030 generated as a result of that header. If the session description has 1031 changed, the user agent server MUST adjust the session parameters 1032 accordingly, possibly after asking the user for confirmation. 1033 (Versioning of the session description can be used to accommodate the 1034 capabilities of new arrivals to a conference, add or delete media or 1035 change from a unicast to a multicast conference.) 1037 This method MUST be supported by SIP proxy, redirect and user agent 1038 servers as well as clients. 1040 4.2.2 ACK 1042 The ACK request confirms that the client has received a final 1043 response to an INVITE request. (ACK is used only with INVITE 1044 requests.) 2xx responses are acknowledged by client user agents, all 1045 other final responses by the first proxy or client user agent to 1046 receive the response. The Via is always initialized to the host that 1047 originates the ACK request, i.e., the client user agent after a 2xx 1048 response or the first proxy to receive a non-2xx final response. The 1049 ACK request is forwarded as the corresponding INVITE request, based 1050 on its Request-URI. See Section 10 for details. 1052 The ACK request MAY contain a message body with the final session 1053 description to be used by the callee. If the ACK message body is 1054 empty, the callee uses the session description in the INVITE request. 1056 A proxy server receiving an ACK request after having sent a 3xx, 4xx, 1057 5xx, or 6xx response must make a determination about whether the ACK 1058 is for it, or for some user agent or proxy server further downstream. 1059 This determination is made by examining the tag in the To field. If 1060 the tag in the ACK To header field matches the tag in the To header 1061 field of the response, and the From, CSeq and Call-ID header fields 1062 in the response match those in the ACK, the ACK is meant for the 1063 proxy server. Otherwise, the ACK SHOULD be proxied downstream as any 1064 other request. 1066 It is possible for a user agent client or proxy server to 1067 receive multiple 3xx, 4xx, 5xx, and 6xx responses to a 1068 request along a single branch. This can happen under 1069 various error conditions, typically when a forking proxy 1070 transitions from stateful to stateless before receiving all 1071 responses. The various responses will all be identical, 1072 except for the tag in the To field, which is different for 1073 each one. It can therefore be used as a means to 1074 disambiguate them. 1076 This method MUST be supported by SIP proxy, redirect and user agent 1077 servers as well as clients. 1079 4.2.3 OPTIONS 1081 The server is being queried as to its capabilities. A server that 1082 believes it can contact the user, such as a user agent where the user 1083 is logged in and has been recently active, MAY respond to this 1084 request with a capability set. A called user agent MAY return a 1085 status reflecting how it would have responded to an invitation, e.g., 1086 600 (Busy). Such a server SHOULD return an Allow header field 1087 indicating the methods that it supports. Proxy and redirect servers 1088 simply forward the request without indicating their capabilities. 1090 This method MUST be supported by SIP proxy, redirect and user agent 1091 servers, registrars and clients. 1093 4.2.4 BYE 1095 The user agent client uses BYE to indicate to the server that it 1096 wishes to release the call. A BYE request is forwarded like an INVITE 1097 request and MAY be issued by either caller or callee. A party to a 1098 call SHOULD issue a BYE request before releasing a call ("hanging 1099 up"). A party receiving a BYE request MUST cease transmitting media 1100 streams specifically directed at the party issuing the BYE request. 1102 If the INVITE request contained a Contact header, the callee SHOULD 1103 send a BYE request to that address rather than the From address. 1105 This method MUST be supported by proxy servers and SHOULD be 1106 supported by redirect and user agent SIP servers. 1108 4.2.5 CANCEL 1110 The CANCEL request cancels a pending request with the same Call-ID, 1111 To, From and CSeq (sequence number only) header field values, but 1112 does not affect a completed request. (A request is considered 1113 completed if the server has returned a final status response.) 1115 A user agent client or proxy client MAY issue a CANCEL request at any 1116 time. A proxy, in particular, MAY choose to send a CANCEL to 1117 destinations that have not yet returned a final response after it has 1118 received a 2xx or 6xx response for one or more of the parallel-search 1119 requests. A proxy that receives a CANCEL request forwards the request 1120 to all destinations with pending requests. 1122 The Call-ID, To, the numeric part of CSeq and From headers in the 1123 CANCEL request are identical to those in the original request. This 1124 allows a CANCEL request to be matched with the request it cancels. 1125 However, to allow the client to distinguish responses to the CANCEL 1126 from those to the original request, the CSeq Method component is set 1127 to CANCEL. The Via header field is initialized to the proxy issuing 1128 the CANCEL request. (Thus, responses to this CANCEL request only 1129 reach the issuing proxy.) 1131 Once a user agent server has received a CANCEL, it MUST NOT issue a 1132 2xx response for the cancelled original request. 1134 A redirect or user agent server receiving a CANCEL request responds 1135 with a status of 200 (OK) if the transaction exists and a status of 1136 481 (Transaction Does Not Exist) if not, but takes no further action. 1137 In particular, any existing call is unaffected. 1139 The BYE request cannot be used to cancel branches of a 1140 parallel search, since several branches may, through 1141 intermediate proxies, find the same user agent server and 1142 then terminate the call. To terminate a call instead of 1143 just pending searches, the UAC must use BYE instead of or 1144 in addition to CANCEL. While CANCEL can terminate any 1145 pending request other than ACK or CANCEL, it is typically 1146 useful only for INVITE. 200 responses to INVITE and 200 1147 responses to CANCEL are distinguished by the method in the 1148 Cseq header field, so there is no ambiguity. 1150 This method MUST be supported by proxy servers and SHOULD be 1151 supported by all other SIP server types. 1153 4.2.6 REGISTER 1155 A client uses the REGISTER method to register the address listed in 1156 the To header field with a SIP server. 1158 A user agent MAY register with a local server on startup by sending a 1159 REGISTER request to the well-known "all SIP servers" multicast 1160 address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped 1161 to ensure it is not forwarded beyond the boundaries of the 1162 administrative system. This MAY be done with either TTL or 1163 administrative scopes[25], depending on what is implemented in the 1164 network. SIP user agents MAY listen to that address and use it to 1165 become aware of the location of other local users [20]; however, they 1166 do not respond to the request. A user agent MAY also be configured 1167 with the address of a registrar server to which it sends a REGISTER 1168 request upon startup. 1170 Requests are processed in the order received. Clients SHOULD avoid 1171 sending a new registration (as opposed to a retransmission) until 1172 they have received the response from the server for the previous one. 1174 Clients may register from different locations, by necessity 1175 using different Call-ID values. Thus, the CSeq value cannot 1176 be used to enforce ordering. Since registrations are 1177 additive, ordering is less of a problem than if each 1178 REGISTER request completely replaced all earlier ones. 1180 The meaning of the REGISTER request-header fields is defined as 1181 follows. We define "address-of-record" as the SIP address that the 1182 registry knows the registrand, typically of the form "user@domain" 1183 rather than "user@host". In third-party registration, the entity 1184 issuing the request is different from the entity being registered. 1186 To: The To header field contains the address-of-record whose 1187 registration is to be created or updated. 1189 From: The From header field contains the address-of-record of the 1190 person responsible for the registration. For first-party 1191 registration, it is identical to the To header field value. 1193 Request-URI: The Request-URI names the destination of the 1194 registration request, i.e., the domain of the registrar. The 1195 user name MUST be empty. Generally, the domains in the Request- 1196 URI and the To header field have the same value; however, it is 1197 possible to register as a "visitor", while maintaining one's 1198 name. For example, a traveller sip:alice@acme.com (To) might 1199 register under the Request-URI sip:atlanta.hiayh.org , with the 1200 former as the To header field and the latter as the Request-URI. 1201 The request is no longer forwarded once it reached the server 1202 whose authoritative domain is the one listed in the Request-URI. 1204 Call-ID: All registrations from a client SHOULD use the same Call-ID 1205 header value, at least within the same reboot cycle. 1207 Cseq: Registrations with the same Call-ID MUST have increasing CSeq 1208 header values. However, the server does not reject out-of-order 1209 requests. 1211 Contact: The request MAY contain a Contact header field; future non- 1212 REGISTER requests for the URI given in the To header field 1213 SHOULD be directed to the address(es) given in the Contact 1214 header. 1216 If the request does not contain a Contact header, the registration 1217 remains unchanged. 1219 This is useful to obtain the current list of registrations 1220 in the response. Registrations using SIP URIs that differ 1221 in one or more of host, port, transport-param or maddr- 1222 param (see Figure 3) from an existing registration are 1223 added to the list of registrations. Other URI types are 1224 compared according to the standard URI equivalency rules 1225 for the URI schema. If the URIs are equivalent to that of 1226 an existing registration, the new registration replaces the 1227 old one if it has a higher q value or, for the same value 1228 of q, if the ttl value is higher. All current registrations 1229 MUST share the same action value. Registrations that have 1230 a different action than current registrations for the same 1231 user MUST be rejected with status of 409 (Conflict). 1233 A proxy server ignores the q parameter when processing non-REGISTER 1234 requests, while a redirect server simply returns that parameter in 1235 its Contact response header field. 1237 Having the proxy server interpret the q parameter is not 1238 sufficient to guide proxy behavior, as it is not clear, for 1239 example, how long it is supposed to wait between trying 1240 addresses. 1242 If the registration is changed while a user agent or proxy server 1243 processes an invitation, the new information SHOULD be used. 1245 This allows a service known as "directed pick-up". In the 1246 telephone network, directed pickup permits a user at a 1247 remote station who hears his own phone ringing to pick up 1248 at that station, dial an access code, and be connected to 1249 the calling user as if he had answered his own phone. 1251 A server MAY choose any duration for the registration lifetime. 1252 Registrations not refreshed after this amount of time SHOULD be 1253 silently discarded. Responses to a registration SHOULD include an 1254 Expires header (Section 6.20) or expires Contact parameters (Section 1255 6.13), indicating the time at which the server will drop the 1256 registration. If none is present, one hour is assumed. Clients MAY 1257 request a registration lifetime by indicating the time in an Expires 1258 header in the request. A server SHOULD NOT use a higher lifetime than 1259 the one requested, but MAY use a lower one. A single address (if 1260 host-independent) MAY be registered from several different clients. 1262 A client cancels an existing registration by sending a REGISTER 1263 request with an expiration time (Expires) of zero seconds for a 1264 particular Contact or the wildcard Contact designated by a "*" for 1265 all registrations. Registrations are matched based on the user, host, 1266 port and maddr parameters. 1268 The server SHOULD return the current list of registrations in the 200 1269 response as Contact header fields. 1271 It is particularly important that REGISTER requests are authenticated 1272 since they allow to redirect future requests (see Section 13.2). 1274 Beyond its use as a simple location service, this method is 1275 needed if there are several SIP servers on a single host. 1276 In that case, only one of the servers can use the default 1277 port number. 1279 Support of this method is RECOMMENDED. 1281 4.3 Request-URI 1283 The Request-URI is a SIP URL as described in Section 2 or a general 1284 URI. It indicates the user or service to which this request is being 1285 addressed. Unlike the To field, the Request-URI MAY be re-written by 1286 proxies. 1288 When used as a Request-URI, a SIP-URL MUST NOT contain the 1289 transport-param, maddr-param, ttl-param, or headers elements. A 1290 server that receives a SIP-URL with these elements removes them 1291 before further processing. 1293 Typically, the UAC sets the Request-URI and To to the same 1294 SIP URL, presumed to remain unchanged over long time 1295 periods. However, if the UAC has cached a more direct path 1296 to the callee, e.g., from the Contact header field of a 1297 response to a previous request, the To would still contain 1298 the long-term, "public" address, while the Request-URI 1299 would be set to the cached address. 1301 Proxy and redirect servers MAY use the information in the Request-URI 1302 and request header fields to handle the request and possibly rewrite 1303 the Request-URI. For example, a request addressed to the generic 1304 address sip:sales@acme.com is proxied to the particular person, e.g., 1305 sip:bob@ny.acme.com , with the To field remaining as 1306 sip:sales@acme.com. At ny.acme.com , Bob then designates Alice as 1307 the temporary substitute. 1309 The host part of the Request-URI typically agrees with one of the 1310 host names of the receiving server. If it does not, the server SHOULD 1311 proxy the request to the address indicated or return a 404 (Not 1312 Found) response if it is unwilling or unable to do so. For example, 1313 the Request-URI and server host name can disagree in the case of a 1314 firewall proxy that handles outgoing calls. This mode of operation is 1315 similar to that of HTTP proxies. 1317 If a SIP server receives a request with a URI indicating a scheme 1318 other than SIP which that server does not understand, the server MUST 1319 return a 400 (Bad Request) response. It MUST do this even if the To 1320 header field contains a scheme it does understand. This is because 1321 proxies are responsible for processing the Request-URI; the To field 1322 is of end-to-end significance. 1324 4.3.1 SIP Version 1326 Both request and response messages include the version of SIP in use, 1327 and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced 1328 by SIP/2.0) regarding version ordering, compliance requirements, and 1329 upgrading of version numbers. To be compliant with this 1330 specification, applications sending SIP messages MUST include a SIP- 1331 Version of "SIP/2.0". 1333 4.4 Option Tags 1334 Option tags are unique identifiers used to designate new options in 1335 SIP. These tags are used in Require (Section 6.30) and Unsupported 1336 (Section 6.38) fields. 1338 Syntax: 1340 option-tag = token 1342 See Section C for a definition of token. The creator of a new SIP 1343 option MUST either prefix the option with their reverse domain name 1344 or register the new option with the Internet Assigned Numbers 1345 Authority (IANA). For example, "com.foo.mynewfeature" is an apt name 1346 for a feature whose inventor can be reached at "foo.com". Individual 1347 organizations are then responsible for ensuring that option names 1348 don't collide. Options registered with IANA have the prefix 1349 "org.iana.sip.", options described in RFCs have the prefix 1350 "org.ietf.rfc.N", where N is the RFC number. Option tags are case- 1351 insensitive. 1353 4.4.1 Registering New Option Tags with IANA 1355 When registering a new SIP option, the following information MUST be 1356 provided: 1358 o Name and description of option. The name MAY be of any length, 1359 but SHOULD be no more than twenty characters long. The name 1360 MUST consist of alphanum (See Figure 3) characters only; 1362 o Indication of who has change control over the option (for 1363 example, IETF, ISO, ITU-T, other international standardization 1364 bodies, a consortium or a particular company or group of 1365 companies); 1367 o A reference to a further description, if available, for 1368 example (in order of preference) an RFC, a published paper, a 1369 patent filing, a technical report, documented source code or a 1370 computer manual; 1372 o Contact information (postal and email address); 1374 Registrations should be sent to iana@iana.org. 1376 This procedure has been borrowed from RTSP [4] and the RTP 1377 AVP [26]. 1379 5 Response 1381 After receiving and interpreting a request message, the recipient 1382 responds with a SIP response message. The response message format is 1383 shown below: 1385 Response = Status-Line ; Section 5.1 1386 *( general-header 1387 | response-header 1388 | entity-header ) 1389 CRLF 1390 [ message-body ] ; Section 8 1392 SIP's structure of responses is similar to [H6], but is defined 1393 explicitly here. 1395 5.1 Status-Line 1397 The first line of a Response message is the Status-Line, consisting 1398 of the protocol version (Section 4.3.1) followed by a numeric 1399 Status-Code and its associated textual phrase, with each element 1400 separated by SP characters. No CR or LF is allowed except in the 1401 final CRLF sequence. 1403 Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF 1405 5.1.1 Status Codes and Reason Phrases 1407 The Status-Code is a 3-digit integer result code that indicates the 1408 outcome of the attempt to understand and satisfy the request. The 1409 Reason-Phrase is intended to give a short textual description of the 1410 Status-Code. The Status-Code is intended for use by automata, whereas 1411 the Reason-Phrase is intended for the human user. The client is not 1412 required to examine or display the Reason-Phrase. 1414 Status-Code = Informational ;Fig. 5 1415 | Success ;Fig. 5 1416 | Redirection ;Fig. 6 1417 | Client-Error ;Fig. 7 1418 | Server-Error ;Fig. 8 1419 | Global-Failure ;Fig. 9 1420 | extension-code 1421 extension-code = 3DIGIT 1422 Reason-Phrase = * 1424 We provide an overview of the Status-Code below, and provide full 1425 definitions in Section 7. The first digit of the Status-Code defines 1426 the class of response. The last two digits do not have any 1427 categorization role. SIP/2.0 allows 6 values for the first digit: 1429 1xx: Informational -- request received, continuing to process the 1430 request; 1432 2xx: Success -- the action was successfully received, understood, and 1433 accepted; 1435 3xx: Redirection -- further action needs to be taken in order to 1436 complete the request; 1438 4xx: Client Error -- the request contains bad syntax or cannot be 1439 fulfilled at this server; 1441 5xx: Server Error -- the server failed to fulfill an apparently valid 1442 request; 1444 6xx: Global Failure -- the request cannot be fulfilled at any server. 1446 Figures 5 through 9 present the individual values of the numeric 1447 response codes, and an example set of corresponding reason phrases 1448 for SIP/2.0. These reason phrases are only recommended; they may be 1449 replaced by local equivalents without affecting the protocol. Note 1450 that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response 1451 codes in the range starting at x80 to avoid conflicts with newly 1452 defined HTTP response codes, and adds a new class, 6xx, of response 1453 codes. 1455 SIP response codes are extensible. SIP applications are not required 1456 to understand the meaning of all registered response codes, though 1457 such understanding is obviously desirable. However, applications MUST 1458 understand the class of any response code, as indicated by the first 1459 digit, and treat any unrecognized response as being equivalent to the 1460 x00 response code of that class, with the exception that an 1461 unrecognized response MUST NOT be cached. For example, if a client 1462 receives an unrecognized response code of 431, it can safely assume 1463 that there was something wrong with its request and treat the 1464 response as if it had received a 400 (Bad Request) response code. In 1465 such cases, user agents SHOULD present to the user the message body 1466 returned with the response, since that message body is likely to 1467 include human-readable information which will explain the unusual 1468 status. 1470 Informational = "100" ; Trying 1471 | "180" ; Ringing 1472 | "181" ; Call Is Being Forwarded 1473 | "182" ; Queued 1474 Success = "200" ; OK 1476 Figure 5: Informational and success status codes 1478 Redirection = "300" ; Multiple Choices 1479 | "301" ; Moved Permanently 1480 | "302" ; Moved Temporarily 1481 | "303" ; See Other 1482 | "305" ; Use Proxy 1483 | "380" ; Alternative Service 1485 Figure 6: Redirection status codes 1487 6 Header Field Definitions 1489 SIP header fields are similar to HTTP header fields in both syntax 1490 and semantics. In particular, SIP header fields follow the syntax for 1491 message-header as described in [H4.2]. The rules for extending header 1492 fields over multiple lines, and use of multiple message-header fields 1493 with the same field-name, described in [H4.2] also apply to SIP. The 1494 rules in [H4.2] regarding ordering of header fields apply to SIP, 1495 with the exception of Via fields, see below, whose order matters. 1496 Additionally, header fields which are hop-by-hop MUST appear before 1497 any header fields which are end-to-end. Proxies SHOULD NOT reorder 1498 header fields. Proxies add Via header fields and MAY add other hop- 1499 by-hop header fields. They can modify certain header fields, such as 1500 Max-Forwards 6.23 and "fix up" the Via header fields with "received" 1501 Client-Error = "400" ; Bad Request 1502 | "401" ; Unauthorized 1503 | "402" ; Payment Required 1504 | "403" ; Forbidden 1505 | "404" ; Not Found 1506 | "405" ; Method Not Allowed 1507 | "406" ; Not Acceptable 1508 | "407" ; Proxy Authentication Required 1509 | "408" ; Request Timeout 1510 | "409" ; Conflict 1511 | "410" ; Gone 1512 | "411" ; Length Required 1513 | "413" ; Request Entity Too Large 1514 | "414" ; Request-URI Too Large 1515 | "415" ; Unsupported Media Type 1516 | "420" ; Bad Extension 1517 | "480" ; Temporarily not available 1518 | "481" ; Call Leg/Transaction Does Not Exist 1519 | "482" ; Loop Detected 1520 | "483" ; Too Many Hops 1521 | "484" ; Address Incomplete 1522 | "485" ; Ambiguous 1523 | "486" ; Busy Here 1525 Figure 7: Client error status codes 1527 Server-Error = "500" ; Internal Server Error 1528 | "501" ; Not Implemented 1529 | "502" ; Bad Gateway 1530 | "503" ; Service Unavailable 1531 | "504" ; Gateway Time-out 1532 | "505" ; SIP Version not supported 1534 Figure 8: Server error status codes 1536 parameters as described in Section 6.40.1. Proxies MUST NOT alter any 1537 fields that are authenticated (see Section 13.2). 1539 The header fields required, optional and not applicable for each 1540 method are listed in Table 4 and Table 5. The table uses "o" to 1541 Global-Failure | "600" ; Busy Everywhere 1542 | "603" ; Decline 1543 | "604" ; Does not exist anywhere 1544 | "606" ; Not Acceptable 1546 Figure 9: Global failure status codes 1548 indicate optional, "m" mandatory and "-" for not applicable. A "*" 1549 indicates that the header fields are needed only if message body is 1550 not empty. See sections 6.15, 6.16 and 8 for details. 1552 The "where" column describes the request and response types with 1553 which the header field can be used. "R" refers to header fields that 1554 can be used in requests (that is, request and general header fields). 1555 "r" designates a response or general-header field as applicable to 1556 all responses, while a list of numeric values indicates the status 1557 codes with which the header field can be used. "g" and "e" designate 1558 general (Section 6.1) and entity header (Section 6.2) fields, 1559 respectively. If a header field is marked "c", it is copied from the 1560 request to the response. 1562 The "enc." column describes whether this message header field MAY be 1563 encrypted end-to-end. A "n" designates fields that MUST NOT be 1564 encrypted, while "c" designates fields that SHOULD be encrypted if 1565 encryption is used. 1567 The "e-e" column has a value of "e" for end-to-end and a value of "h" 1568 for hop-by-hop header fields. 1570 Other header fields can be added as required; a server MUST ignore 1571 header fields not defined in this specification that it does not 1572 understand. A proxy MUST NOT remove or modify header fields not 1573 defined in this specification that it does not understand. A compact 1574 form of these header fields is also defined in Section 9 for use over 1575 UDP when the request has to fit into a single packet and size is an 1576 issue. 1578 Table 6 in Appendix A lists those header fields that different client 1579 and server types MUST be able to parse. 1581 6.1 General Header Fields 1582 where enc. e-e ACK BYE CAN INV OPT REG 1583 __________________________________________________________ 1584 Accept R e - - - o o o 1585 Accept 415 e - - - o o o 1586 Accept-Encoding R e - - - o o o 1587 Accept-Encoding 415 e - - - o o o 1588 Accept-Language R e - o o o o o 1589 Accept-Language 415 e - o o o o o 1590 Allow 200 e - - - - m - 1591 Allow 405 e o o o o o o 1592 Authorization R e o o o o o o 1593 Call-ID gc n e m m m m m m 1594 Contact R e o - - o o o 1595 Contact 1xx e - - - o o - 1596 Contact 2xx e - - - o o o 1597 Contact 3xx e - o - o o o 1598 Contact 485 e - o - o o o 1599 Content-Encoding e e o - - o o o 1600 Content-Length e e o - - o o o 1601 Content-Type e e * - - * * * 1602 CSeq gc n e m m m m m m 1603 Date g e o o o o o o 1604 Encryption g n e o o o o o o 1605 Expires g e - - - o - o 1606 From gc n e m m m m m m 1607 Hide R n h o o o o o o 1608 Max-Forwards R n e o o o o o o 1609 Organization g c h - - - o o o 1611 Table 4: Summary of header fields, A--O 1613 General header fields apply to both request and response messages. 1614 The "general-header" field names can be extended reliably only in 1615 combination with a change in the protocol version. However, new or 1616 experimental header fields MAY be given the semantics of general 1617 header fields if all parties in the communication recognize them to 1618 be "general-header" fields. Unrecognized header fields are treated as 1619 "entity-header" fields. 1621 6.2 Entity Header Fields 1623 The "entity-header" fields define meta-information about the 1624 message-body or, if no body is present, about the resource identified 1625 by the request. The term "entity header" is an HTTP 1.1 term where 1626 the response body can contain a transformed version of the message 1627 body. The original message body is referred to as the "entity". We 1628 retain the same terminology for header fields but usually refer to 1629 where enc. e-e ACK BYE CAN INV OPT REG 1630 ___________________________________________________________________ 1631 Proxy-Authenticate 407 n h o o o o o o 1632 Proxy-Authorization R n h o o o o o o 1633 Proxy-Require R n h o o o o o o 1634 Priority R c e - - - o - - 1635 Require R e o o o o o o 1636 Retry-After R c e - - - - - o 1637 Retry-After 404,480,486 c e o o o o o o 1638 503 c e o o o o o o 1639 600,603 c e o o o o o o 1640 Response-Key R c e - o o o o o 1641 Record-Route R h o o o o o o 1642 Record-Route 2xx h o o o o o o 1643 Route R h - o o o o o 1644 Server r c e o o o o o o 1645 Subject R c e - - - o - - 1646 Timestamp g e o o o o o o 1647 To gc(1) n e m m m m m m 1648 Unsupported 420 e o o o o o o 1649 User-Agent g c e o o o o o o 1650 Via gc(2) n e m m m m m m 1651 Warning r e o o o o o o 1652 WWW-Authenticate 401 c e o o o o o o 1654 Table 5: Summary of header fields, P--Z; (1): copied with possible 1655 addition of tag; (2): UAS removes first Via header field 1657 the "message body" rather then the entity as the two are the same in 1658 SIP. 1660 6.3 Request Header Fields 1662 The "request-header" fields allow the client to pass additional 1663 information about the request, and about the client itself, to the 1664 server. These fields act as request modifiers, with semantics 1665 equivalent to the parameters of a programming language method 1666 invocation. 1668 The "request-header" field names can be extended reliably only in 1669 combination with a change in the protocol version. However, new or 1670 experimental header fields MAY be given the semantics of "request- 1671 header" fields if all parties in the communication recognize them to 1672 be request-header fields. Unrecognized header fields are treated as 1673 "entity-header" fields. 1675 6.4 Response Header Fields 1677 The "response-header" fields allow the server to pass additional 1678 information about the response which cannot be placed in the Status- 1679 Line. These header fields give information about the server and about 1680 further access to the resource identified by the Request-URI. 1682 Response-header field names can be extended reliably only in 1683 combination with a change in the protocol version. However, new or 1684 experimental header fields MAY be given the semantics of "response- 1685 header" fields if all parties in the communication recognize them to 1686 be "response-header" fields. Unrecognized header fields are treated 1687 as "entity-header" fields. 1689 6.5 End-to-end and Hop-by-hop Headers 1691 End-to-end headers MUST be transmitted unmodified across all proxies, 1692 while hop-by-hop headers MAY be modified or added by proxies. 1694 6.6 Header Field Format 1696 Header fields ("general-header", "request-header", "response-header", 1697 and "entity-header") follow the same generic header format as that 1698 given in Section 3.1 of RFC 822 [24]. Each header field consists of a 1699 name followed by a colon (":") and the field value. Field names are 1700 case-insensitive. The field value MAY be preceded by any amount of 1701 leading white space (LWS), though a single space (SP) is preferred. 1702 Header fields can be extended over multiple lines by preceding each 1703 extra line with at least one SP or horizontal tab (HT). Applications 1704 MUST follow HTTP "common form" when generating these constructs, 1705 since there might exist some implementations that fail to accept 1706 anything beyond the common forms. 1708 message-header = field-name ":" [ field-value ] CRLF 1709 field-name = token 1710 field-value = *( field-content | LWS ) 1711 field-content = < the OCTETs making up the field-value 1712 and consisting of either *TEXT-UTF8 1713 or combinations of token, 1714 tspecials, and quoted-string> 1716 The relative order of header fields with different field names is not 1717 significant. Multiple header fields with the same field-name may be 1718 present in a message if and only if the entire field-value for that 1719 header field is defined as a comma-separated list (i.e., #(values)). 1721 It MUST be possible to combine the multiple header fields into one 1722 "field-name: field-value" pair, without changing the semantics of the 1723 message, by appending each subsequent field-value to the first, each 1724 separated by a comma. The order in which header fields with the same 1725 field-name are received is therefore significant to the 1726 interpretation of the combined field value, and thus a proxy MUST NOT 1727 change the order of these field values when a message is forwarded. 1729 Field names are not case-sensitive, although their values may be. 1731 6.7 Accept 1733 The Accept header follows the syntax defined in [H14.1]. The 1734 semantics are also identical, with the exception that if no Accept 1735 header is present, the server SHOULD assume a default value of 1736 application/sdp. 1738 This request-header field is used only with the INVITE, OPTIONS and 1739 REGISTER request methods to indicate what media types are acceptable 1740 in the response. 1742 Example: 1744 Accept: application/sdp;level=1, application/x-private, text/html 1746 6.8 Accept-Encoding 1748 The Accept-Encoding request-header field is similar to Accept, but 1749 restricts the content-codings [H3.4.1] that are acceptable in the 1750 response. See [H14.3]. The syntax of this header is defined in 1751 [H14.3]. The semantics in SIP are identical to those defined in 1752 [H14.3]. 1754 6.9 Accept-Language 1756 The Accept-Language header follows the syntax defined in [H14.4]. The 1757 rules for ordering the languages based on the q parameter apply to 1758 SIP as well. When used in SIP, the Accept-Language request-header 1759 field can be used to allow the client to indicate to the server in 1760 which language it would prefer to receive reason phrases, session 1761 descriptions or status responses carried as message bodies. A proxy 1762 MAY use this field to help select the destination for the call, for 1763 example, a human operator conversant in a language spoken by the 1764 caller. 1766 Example: 1768 Accept-Language: da, en-gb;q=0.8, en;q=0.7 1770 6.10 Allow 1772 The Allow entity-header field lists the set of methods supported by 1773 the resource identified by the Request-URI. The purpose of this field 1774 is strictly to inform the recipient of valid methods associated with 1775 the resource. An Allow header field MUST be present in a 405 (Method 1776 Not Allowed) response and SHOULD be present in an OPTIONS response. 1778 Allow = "Allow" ":" 1#Method 1780 6.11 Authorization 1782 A user agent that wishes to authenticate itself with a server -- 1783 usually, but not necessarily, after receiving a 401 response -- MAY 1784 do so by including an Authorization request-header field with the 1785 request. The Authorization field value consists of credentials 1786 containing the authentication information of the user agent for the 1787 realm of the resource being requested. 1789 Section 13.2 overviews the use of the Authorization header, and 1790 section 15 describes the syntax and semantics when used with PGP 1791 based authentication. 1793 6.12 Call-ID 1795 The Call-ID general-header field uniquely identifies a particular 1796 invitation or all registrations of a particular client. Note that a 1797 single multimedia conference can give rise to several calls with 1798 different Call-IDs, e.g., if a user invites a single individual 1799 several times to the same (long-running) conference. 1801 For an INVITE request, a callee user agent server SHOULD NOT alert 1802 the user if the user has responded previously to the Call-ID in the 1803 INVITE request. If the user is already a member of the conference and 1804 the conference parameters contained in the session description have 1805 not changed, a callee user agent server MAY silently accept the call, 1806 regardless of the Call-ID. An invitation for an existing Call-ID or 1807 session can change the parameters of the conference. A client 1808 application MAY decide to simply indicate to the user that the 1809 conference parameters have been changed and accept the invitation 1810 automatically or it MAY require user confirmation. 1812 A user may be invited to the same conference or call using several 1813 different Call-IDs. If desired, the client MAY use identifiers within 1814 the session description to detect this duplication. For example, SDP 1815 contains a session id and version number in the origin (o) field. 1817 The REGISTER and OPTIONS methods use the Call-ID value to 1818 unambiguously match requests and responses. All REGISTER requests 1819 issued by a single client SHOULD use the same Call-ID, at least 1820 within the same boot cycle. 1822 Since the Call-ID is generated by and for SIP, there is no 1823 reason to deal with the complexity of URL-encoding and 1824 case-ignoring string comparison. 1826 Call-ID = ( "Call-ID" | "i" ) ":" local-id "@" host 1827 local-id = 1*uric 1829 "host" SHOULD be either a fully qualified domain name or a globally 1830 routable IP address. If this is the case, the "local-id" SHOULD be an 1831 identifier consisting of URI characters that is unique within "host". 1832 Use of cryptographically random identifiers [27] is RECOMMENDED. If, 1833 however, host is not an FQDN or globally routable IP address (such as 1834 a net 10 address), the local-id MUST be globally unique, as opposed 1835 to unique within host. These rules guarantee overall global 1836 uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused 1837 for a different call. Call-IDs are case-sensitive. 1839 Using cryptographically random identifiers provides some 1840 protection against session hijacking. Call-ID, To and From 1841 are needed to identify a call leg. The distinction between 1842 call and call leg matters in calls with third-party 1843 control. 1845 For systems which have tight bandwidth constraints, many of the 1846 mandatory SIP headers have a compact form, as discussed in Section 9. 1847 These are alternate names for the headers which occupy less space in 1848 the message. In the case of Call-ID, the compact form is i. 1850 For example, both of the following are valid: 1852 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 1854 or 1856 i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 1858 6.13 Contact 1860 The Contact general-header field can appear in INVITE, ACK, and 1861 REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In 1862 general, it provides a URL where the user can be reached for further 1863 communications. 1865 INVITE and ACK requests: INVITE and ACK requests MAY contain Contact 1866 headers indicating from which location the request is 1867 originating. 1869 This allows the callee to send future requests, such as 1870 BYE, directly to the caller instead of through a series of 1871 proxies. The Via header is not sufficient since the 1872 desired address may be that of a proxy. 1874 INVITE 2xx responses: A user agent server sending a definitive, 1875 positive response (2xx) MAY insert a Contact response header 1876 field indicating the SIP address under which it is reachable 1877 most directly for future SIP requests, such as ACK, within the 1878 same Call-ID. The Contact header field contains the address of 1879 the server itself or that of a proxy, e.g., if the host is 1880 behind a firewall. The value of this Contact header is copied 1881 into the Request-URI of subsequent requests for this call. If 1882 the response also contains a Record-Route header field, the 1883 address in the Contact header field is added as the last item in 1884 the Route header field. See Section 6.29 for details. 1886 The Contact value SHOULD NOT be cached across calls, as it 1887 may not represent the most desirable location for a 1888 particular destination address. 1890 INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY 1891 insert a Contact response header. It has the same semantics in a 1892 1xx response as a 2xx INVITE response. Note that CANCEL requests 1893 MUST NOT be sent to that address, but rather follow the same 1894 path as the original request. 1896 REGISTER requests: REGISTER requests MAY contain a Contact header 1897 field indicating at which locations the user is reachable. The 1898 REGISTER request defines a wildcard Contact field, "*", which 1899 MUST only be used with Expires: 0 to remove all registrations 1900 for a particular user. An optional "expires" parameter indicates 1901 the desired expiration time of the registration. If a Contact 1902 entry does not have an "expires" parameter, the Expires header 1903 field is used as the default value. If neither of these 1904 mechanisms is used, SIP URIs are assumed to expire after one 1905 hour. Other URI schemes have no expiration times. 1907 REGISTER 2xx responses: A REGISTER response MAY return all locations 1908 at which the user is currently reachable. An optional "expires" 1909 parameter indicates the expiration time of the registration. If 1910 a Contact entry does not have an "expires" parameter, the value 1911 of the Expires header field indicates the expiration time. If 1912 neither mechanism is used, the expiration time specified in the 1913 request, explicitly or by default, is used. 1915 3xx and 485 responses: The Contact response-header field can be used 1916 with a 3xx or 485 (Ambiguous) response codes to indicate one or 1917 more alternate addresses to try. It can appear in responses to 1918 BYE, INVITE and OPTIONS methods. The Contact header field 1919 contains URIs giving the new locations or user names to try, or 1920 may simply specify additional transport parameters. A 300 1921 (Multiple Choices), 301 (Moved Permanently), 302 (Moved 1922 Temporarily) or 485 (Ambiguous) response SHOULD contain a 1923 Contact field containing URIs of new addresses to be tried. A 1924 301 or 302 response may also give the same location and username 1925 that was being tried but specify additional transport parameters 1926 such as a different server or multicast address to try or a 1927 change of SIP transport from UDP to TCP or vice versa. The 1928 client copies the "user", "password", "host", "port" and "user- 1929 param" elements of the Contact URI into the Request-URI of the 1930 redirected request and directs the request to the address 1931 specified by the "maddr" and "port" parameters, using the 1932 transport protocol given in the "transport" parameter. If 1933 "maddr" is a multicast address, the value of "ttl" is used as 1934 the time-to-live value. 1936 Note that the Contact header field MAY also refer to a different 1937 entity than the one originally called. For example, a SIP call 1938 connected to GSTN gateway may need to deliver a special information 1939 announcement such as "The number you have dialed has been changed." 1941 A Contact response header field can contain any suitable URI 1942 indicating where the called party can be reached, not limited to SIP 1943 URLs. For example, it could contain URL's for phones, fax, or irc (if 1944 they were defined) or a mailto: (RFC 2368, [28]) URL. 1946 The following parameters are defined. Additional parameters may be 1947 defined in other specifications. 1949 q: The "qvalue" indicates the relative preference among the locations 1950 given. "qvalue" values are decimal numbers from 0 to 1, with 1951 higher values indicating higher preference. 1953 action: The "action" parameter is used only when registering with the 1954 REGISTER request. It indicates whether the client wishes that 1955 the server proxy or redirect future requests intended for the 1956 client. If this parameter is not specified the action taken 1957 depends on server configuration. In its response, the registrar 1958 SHOULD indicate the mode used. This parameter is ignored for 1959 other requests. 1961 expires: The "expires" parameter indicates how long the URI is valid. 1962 The parameter is either a number indicating seconds or a quoted 1963 string containing a SIP-date. If this parameter is not provided, 1964 the value of the Expires header field determines how long the 1965 URI is valid. Implementations MAY treat values larger than 1966 2**32-1 (4294967295 or 136 years) as equivalent to 2**32-1. 1968 Contact = ( "Contact" | "m" ) ":" ("*" | (1# ( name-addr | addr-spec ) 1969 [ *( ";" contact-params ) ] [ comment ] )) 1971 name-addr = [ display-name ] "<" addr-spec ">" 1972 addr-spec = SIP-URL | URI 1973 display-name = *token | quoted-string 1975 contact-params = "q" "=" qvalue 1976 | "action" "=" "proxy" | "redirect" 1977 | "expires" "=" delta-seconds | <"> SIP-date <"> 1978 | extension-attribute 1980 extension-attribute = extension-name [ "=" extension-value ] 1982 Even if the "display-name" is empty, the "name-addr" form MUST be 1983 used if the "addr-spec" contains a comma, semicolon or question mark. 1985 The Contact header field fulfills functionality similar to 1986 the Location header field in HTTP. However, the HTTP header 1987 only allows one address, unquoted. Since URIs can contain 1988 commas and semicolons as reserved characters, they can be 1989 mistaken for header or parameter delimiters, respectively. 1990 The current syntax corresponds to that for the To and From 1991 header, which also allows the use of display names. 1993 Example: 1995 Contact: "Mr. Watson" 1996 ;q=0.7; expires=3600, 1997 "Mr. Watson" ;q=0.1 1999 6.14 Content-Encoding 2001 Content-Encoding = ( "Content-Encoding" | "e" ) ":" 2002 1#content-coding 2004 The Content-Encoding entity-header field is used as a modifier to the 2005 "media-type". When present, its value indicates what additional 2006 content codings have been applied to the entity-body, and thus what 2007 decoding mechanisms MUST be applied in order to obtain the media-type 2008 referenced by the Content-Type header field. Content-Encoding is 2009 primarily used to allow a body to be compressed without losing the 2010 identity of its underlying media type. 2012 If multiple encodings have been applied to an entity, the content 2013 codings MUST be listed in the order in which they were applied. 2015 All content-coding values are case-insensitive. The Internet Assigned 2016 Numbers Authority (IANA) acts as a registry for content-coding value 2017 tokens. See [3.5] for a definition of the syntax for content-coding. 2019 Clients MAY apply content encodings to the body in requests. If the 2020 server is not capable of decoding the body, or does not recognize any 2021 of the content-coding values, it MUST send a 415 "Unsupported Media 2022 Type" response, listing acceptable encodings in the Accept-Encoding 2023 header. A server MAY apply content encodings to the bodies in 2024 responses. The server MUST only use encodings listed in the Accept- 2025 Encoding header in the request. 2027 6.15 Content-Length 2029 The Content-Length entity-header field indicates the size of the 2030 message-body, in decimal number of octets, sent to the recipient. 2032 Content-Length = ( "Content-Length" | "l" ) ":" 1*DIGIT 2034 An example is 2036 Content-Length: 3495 2038 Applications SHOULD use this field to indicate the size of the 2039 message-body to be transferred, regardless of the media type of the 2040 entity. Any Content-Length greater than or equal to zero is a valid 2041 value. If no body is present in a message, then the Content-Length 2042 header field MUST be set to zero. If a server receives a UDP request 2043 without Content-Length, it MUST assume that the request encompasses 2044 the remainder of the packet. If a server receives a UDP request with 2045 a Content-Length, but the value is larger than the size of the body 2046 sent in the request, the client SHOULD generate a 400 class response. 2047 If there is additional data in the UDP packet after the last byte of 2048 the body has been read, the server MUST treat the remaining data as a 2049 separate message. This allows several messages to be placed in a 2050 single UDP packet. 2052 If a response does not contain a Content-Length, the client assumes 2053 that it encompasses the remainder of the UDP packet or the data until 2054 the TCP connection is closed, as applicable. Section 8 describes how 2055 to determine the length of the message body. 2057 6.16 Content-Type 2059 The Content-Type entity-header field indicates the media type of the 2060 message-body sent to the recipient. The "media-type" element is 2061 defined in [H3.7]. 2063 Content-Type = ( "Content-Type" | "c" ) ":" media-type 2065 Examples of this header field are 2067 Content-Type: application/sdp 2068 Content-Type: text/html; charset=ISO-8859-4 2070 6.17 CSeq 2072 Clients MUST add the CSeq (command sequence) general-header field to 2073 every request. A CSeq header field in a request contains the request 2074 method and a single decimal sequence number chosen by the requesting 2075 client, unique within a single value of Call-ID. The sequence number 2076 MUST be expressible as a 32-bit unsigned integer. The initial value 2077 of the sequence number is arbitrary, but MUST be less than 2**31. 2078 Consecutive requests that differ in request method, headers or body, 2079 but have the same Call-ID MUST contain strictly monotonically 2080 increasing and contiguous sequence numbers; sequence numbers do not 2081 wrap around. Retransmissions of the same request carry the same 2082 sequence number, but an INVITE with a different message body or 2083 different header fields (a "re-invitation") acquires a new, higher 2084 sequence number. A server MUST echo the CSeq value from the request 2085 in its response. If the Method value is missing in the received CSeq 2086 header field, the server fills it in appropriately. 2088 The ACK and CANCEL requests MUST contain the same CSeq value as the 2089 INVITE request that it refers to, while a BYE request cancelling an 2090 invitation MUST have a higher sequence number. A BYE request with a 2091 CSeq that is not higher should cause a 400 response to be generated. 2093 A user agent server MUST remember the highest sequence number for any 2094 INVITE request with the same Call-ID value. The server MUST respond 2095 to, and then discard, any INVITE request with a lower sequence 2096 number. 2098 All requests spawned in a parallel search have the same CSeq value as 2099 the request triggering the parallel search. 2101 CSeq = "CSeq" ":" 1*DIGIT Method 2103 Strictly speaking, CSeq header fields are needed for any 2104 SIP request that can be cancelled by a BYE or CANCEL 2105 request or where a client can issue several requests for 2106 the same Call-ID in close succession. Without a sequence 2107 number, the response to an INVITE could be mistaken for the 2108 response to the cancellation (BYE or CANCEL). Also, if the 2109 network duplicates packets or if an ACK is delayed until 2110 the server has sent an additional response, the client 2111 could interpret an old response as the response to a re- 2112 invitation issued shortly thereafter. Using CSeq also makes 2113 it easy for the server to distinguish different versions of 2114 an invitation, without comparing the message body. 2116 The Method value allows the client to distinguish the response to an 2117 INVITE request from that of a CANCEL response. CANCEL requests can be 2118 generated by proxies; if they were to increase the sequence number, 2119 it might conflict with a later request issued by the user agent for 2120 the same call. 2122 With a length of 32 bits, a server could generate, within a single 2123 call, one request a second for about 136 years before needing to wrap 2124 around. The initial value of the sequence number is chosen so that 2125 subsequent requests within the same call will not wrap around. A 2126 non-zero initial value allows to use a time-based initial sequence 2127 number, if the client desires. A client could, for example, choose 2128 the 31 most significant bits of a 32-bit second clock as an initial 2129 sequence number. 2131 Forked requests MUST have the same CSeq as there would be ambiguity 2132 otherwise between these forked requests and later BYE issued by the 2133 client user agent. 2135 Example: 2137 CSeq: 4711 INVITE 2139 6.18 Date 2141 Date is a general-header field. Its syntax is: 2143 SIP-date = rfc1123-date 2145 See [H14.19] for a definition of rfc1123-date. Note that unlike 2146 HTTP/1.1, SIP only supports the most recent RFC1123 [29] formatting 2147 for dates. 2149 The Date header field reflects the time when the request or response 2150 is first sent. Thus, retransmissions have the same Date header field 2151 value as the original. 2153 The Date header field can be used by simple end systems 2154 without a battery-backed clock to acquire a notion of 2155 current time. 2157 6.19 Encryption 2159 The Encryption general-header field specifies that the content has 2160 been encrypted. Section 13 describes the overall SIP security 2161 architecture and algorithms. This header field is intended for end- 2162 to-end encryption of requests and responses. Requests are encrypted 2163 based on the public key belonging to the entity named in the To 2164 header field. Responses are encrypted based on the public key 2165 conveyed in the Response-Key header field. Note that the public keys 2166 themselves may not be used for the encryption. This depends on the 2167 particular algorithms used. 2169 For any encrypted message, at least the message body and possibly 2170 other message header fields are encrypted. An application receiving a 2171 request or response containing an Encryption header field decrypts 2172 the body and then concatenates the plaintext to the request line and 2173 headers of the original message. Message headers in the decrypted 2174 part completely replace those with the same field name in the 2175 plaintext part. (Note: If only the body of the message is to be 2176 encrypted, the body has to be prefixed with CRLF to allow proper 2177 concatenation.) Note that the request method and Request-URI cannot 2178 be encrypted. 2180 Encryption only provides privacy; the recipient has no 2181 guarantee that the request or response came from the party 2182 listed in the From message header, only that the sender 2183 used the recipient's public key. However, proxies will not 2184 be able to modify the request or response. 2186 Encryption = "Encryption" ":" encryption-scheme 1*SP 2187 #encryption-params 2188 encryption-scheme = token 2189 encryption-params = token "=" ( token | quoted-string ) 2191 The token indicates the form of encryption used; it is 2192 described in section 13. 2194 The example in Figure 10 shows a message encrypted with ASCII-armored 2195 PGP that was generated by applying "pgp -ea" to the payload to be 2196 encrypted. 2198 INVITE sip:watson@boston.bell-telephone.com SIP/2.0 2199 Via: SIP/2.0/UDP 169.130.12.5 2200 From: 2201 To: T. A. Watson 2202 Call-ID: 187602141351@worcester.bell-telephone.com 2203 Content-Length: 885 2204 Encryption: PGP version=2.6.2,encoding=ascii 2206 hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red 2207 h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs 2208 ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR 2209 RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA 2210 zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu 2211 X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6 2212 IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/ 2213 GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E 2214 WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed 2215 wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO 2216 z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+ 2217 6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2 2218 z8X9N4MhMyXEVuC9rt8/AUhmVQ== 2219 =bOW+ 2221 Figure 10: PGP Encryption Example 2223 Since proxies can base their forwarding decision on any combination 2224 of SIP header fields, there is no guarantee that an encrypted request 2225 "hiding" header fields will reach the same destination as an 2226 otherwise identical un-encrypted request. 2228 6.20 Expires 2230 The Expires entity-header field gives the date and time after which 2231 the message content expires. 2233 This header field is currently defined only for the REGISTER and 2234 INVITE methods. For REGISTER, it is a request and response-header 2235 field. In a REGISTER request, the client indicates how long it wishes 2236 the registration to be valid. In the response, the server indicates 2237 the earliest expiration time of all registrations. The server MAY 2238 choose a shorter time interval than that requested by the client, but 2239 SHOULD NOT choose a longer one. 2241 For INVITE requests, it is a request and response-header field. In a 2242 request, the caller can limit the validity of an invitation, for 2243 example, if a client wants to limit the time duration of a search or 2244 a conference invitation. A user interface MAY take this as a hint to 2245 leave the invitation window on the screen even if the user is not 2246 currently at the workstation. This also limits the duration of a 2247 search. If the request expires before the search completes, the proxy 2248 returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily) 2249 response, a server can advise the client of the maximal duration of 2250 the redirection. 2252 The value of this field can be either a SIP-date or an integer number 2253 of seconds (in decimal), measured from the receipt of the request. 2254 The latter approach is preferable for short durations, as it does not 2255 depend on clients and servers sharing a synchronized clock. 2256 Implementations MAY treat values larger than 2**32-1 (4294967295 or 2257 136 years) as equivalent to 2**32-1. 2259 Expires = "Expires" ":" ( SIP-date | delta-seconds ) 2261 Two examples of its use are 2263 Expires: Thu, 01 Dec 1994 16:00:00 GMT 2264 Expires: 5 2266 6.21 From 2268 Requests and responses MUST contain a From general-header field, 2269 indicating the initiator of the request. The From field MAY contain 2270 the "tag" parameter. The server copies the From header field from the 2271 request to the response. The optional "display-name" is meant to be 2272 rendered by a human-user interface. A system SHOULD use the display 2273 name "Anonymous" if the identity of the client is to remain hidden. 2275 The SIP-URL MUST NOT contain the "transport-param", "maddr-param", 2276 "ttl-param", or "headers" elements. A server that receives a SIP-URL 2277 with these elements removes them before further processing. 2279 Even if the "display-name" is empty, the "name-addr" form MUST be 2280 used if the "addr-spec" contains a comma, question mark, or 2281 semicolon. 2283 From = ( "From" | "f" ) ":" ( name-addr | addr-spec ) 2284 *( ";" addr-params ) 2285 addr-params = tag-param 2286 tag-param = "tag=" UUID 2287 UUID = 1*( hex | "-" ) 2289 Examples: 2291 From: "A. G. Bell" 2292 From: sip:+12125551212@server.phone2net.com 2293 From: Anonymous 2295 The "tag" MAY appear in the From field of a request. It MUST be 2296 present when it is possible that two instances of a user sharing a 2297 SIP address can make call invitations with the same Call-ID. 2299 The "tag" value MUST be globally unique and cryptographically random 2300 with at least 32 bits of randomness. A single user maintains the same 2301 tag throughout the call identified by the Call-ID. 2303 Call-ID, To and From are needed to identify a call leg. 2304 The distinction between call and call leg matters in calls 2305 with multiple responses to a forked request. The format is 2306 similar to the equivalent RFC 822 [24] header, but with a 2307 URI instead of just an email address. 2309 6.22 Hide 2311 A client uses the Hide request header field to indicate that it wants 2312 the path comprised of the Via header fields (Section 6.40) to be 2313 hidden from subsequent proxies and user agents. It can take two 2314 forms: Hide: route and Hide: hop. Hide header fields are typically 2315 added by the client user agent, but MAY be added by any proxy along 2316 the path. 2318 If a request contains the "Hide: route" header field, all following 2319 proxies SHOULD hide their previous hop. If a request contains the 2320 "Hide: hop" header field, only the next proxy SHOULD hide the 2321 previous hop and then remove the Hide option unless it also wants to 2322 remain anonymous. 2324 A server hides the previous hop by encrypting the "host" and "port" 2325 parts of the top-most Via header field with an algorithm of its 2326 choice. Servers SHOULD add additional "salt" to the "host" and "port" 2327 information prior to encryption to prevent malicious downstream 2328 proxies from guessing earlier parts of the path based on seeing 2329 identical encrypted Via headers. Hidden Via fields are marked with 2330 the "hidden" Via option, as described in Section 6.40. 2332 A server that is capable of hiding Via headers MUST attempt to 2333 decrypt all Via headers marked as "hidden" to perform loop detection. 2334 Servers that are not capable of hiding can ignore hidden Via fields 2335 in their loop detection algorithm. 2337 If hidden headers were not marked, a proxy would have to 2338 decrypt all headers to detect loops, just in case one was 2339 encrypted, as the Hide: Hop option may have been removed 2340 along the way. 2342 A host MUST NOT add such a "Hide: hop" header field unless it can 2343 guarantee it will only send a request for this destination to the 2344 same next hop. The reason for this is that it is possible that the 2345 request will loop back through this same hop from a downstream proxy. 2346 The loop will be detected by the next hop if the choice of next hop 2347 is fixed, but could loop an arbitrary number of times otherwise. 2349 A client requesting "Hide: route" can only rely on keeping the 2350 request path private if it sends the request to a trusted proxy. 2351 Hiding the route of a SIP request is of limited value if the request 2352 results in data packets being exchanged directly between the calling 2353 and called user agent. 2355 The use of Hide header fields is discouraged unless path privacy is 2356 truly needed; Hide fields impose extra processing costs and 2357 restrictions for proxies and can cause requests to generate 482 (Loop 2358 Detected) responses that could otherwise be avoided. 2360 The encryption of Via header fields is described in more detail in 2361 Section 13. 2363 The Hide header field has the following syntax: 2365 Hide = "Hide" ":" ( "route" | "hop" ) 2367 6.23 Max-Forwards 2369 The Max-Forwards request-header field may be used with any SIP method 2370 to limit the number of proxies or gateways that can forward the 2371 request to the next downstream server. This can also be useful when 2372 the client is attempting to trace a request chain which appears to be 2373 failing or looping in mid-chain. 2375 Max-Forwards = "Max-Forwards" ":" 1*DIGIT 2377 The Max-Forwards value is a decimal integer indicating the remaining 2378 number of times this request message is allowed to be forwarded. 2380 Each proxy or gateway recipient of a request containing a Max- 2381 Forwards header field MUST check and update its value prior to 2382 forwarding the request. If the received value is zero (0), the 2383 recipient MUST NOT forward the request. Instead, for the OPTIONS and 2384 REGISTER methods, it MUST respond as the final recipient. For all 2385 other methods, the server returns 483 (Too many hops). 2387 If the received Max-Forwards value is greater than zero, then the 2388 forwarded message MUST contain an updated Max-Forwards field with a 2389 value decremented by one (1). 2391 Example: 2393 Max-Forwards: 6 2395 6.24 Organization 2397 The Organization general-header field conveys the name of the 2398 organization to which the entity issuing the request or response 2399 belongs. It MAY also be inserted by proxies at the boundary of an 2400 organization. 2402 The field MAY be used by client software to filter calls. 2404 Organization = "Organization" ":" *TEXT-UTF8 2406 6.25 Priority 2408 The Priority request-header field indicates the urgency of the 2409 request as perceived by the client. 2411 Priority = "Priority" ":" priority-value 2412 priority-value = "emergency" | "urgent" | "normal" 2413 | "non-urgent" 2415 It is RECOMMENDED that the value of "emergency" only be used when 2416 life, limb or property are in imminent danger. 2418 Examples: 2420 Subject: A tornado is heading our way! 2421 Priority: emergency 2423 Subject: Weekend plans 2424 Priority: non-urgent 2426 These are the values of RFC 2076 [30], with the addition of 2427 "emergency". 2429 6.26 Proxy-Authenticate 2431 The Proxy-Authenticate response-header field MUST be included as part 2432 of a 407 (Proxy Authentication Required) response. The field value 2433 consists of a challenge that indicates the authentication scheme and 2434 parameters applicable to the proxy for this Request-URI. 2436 Unlike its usage within HTTP, the Proxy-Authenticate header MUST be 2437 passed upstream in the response to tha UAC. In SIP, only UAC's can 2438 authenticate themselves to proxies. 2440 The syntax for this header is defined in [H14.33]. See 14 for further 2441 details on its usage. 2443 A client SHOULD cache the credentials used for a particular proxy 2444 server and realm for the next request to that server. Credentials 2445 are, in general, valid for a specific value of the Request-URI at a 2446 particular proxy server. If a client contacts a proxy server that has 2447 required authentication in the past, but the client does not have 2448 credentials for the particular Request-URI, it MAY attempt to use the 2449 most-recently used credential. The server responds with 401 2450 (Unauthorized) if the client guessed wrong. 2452 This suggested caching behavior is motivated by proxies 2453 restricting phone calls to authenticated users. It seems 2454 likely that in most cases, all destinations require the 2455 same password. Note that end-to-end authentication is 2456 likely to be destination-specific. 2458 6.27 Proxy-Authorization 2460 The Proxy-Authorization request-header field allows the client to 2461 identify itself (or its user) to a proxy which requires 2462 authentication. The Proxy-Authorization field value consists of 2463 credentials containing the authentication information of the user 2464 agent for the proxy and/or realm of the resource being requested. 2466 Unlike Authorization, the Proxy-Authorization header field applies 2467 only to the next outbound proxy that demanded authentication using 2468 the Proxy- Authenticate field. When multiple proxies are used in a 2469 chain, the Proxy-Authorization header field is consumed by the first 2470 outbound proxy that was expecting to receive credentials. A proxy MAY 2471 relay the credentials from the client request to the next proxy if 2472 that is the mechanism by which the proxies cooperatively authenticate 2473 a given request. 2475 See [H14.34] for a definition of the syntax, and section 14 for a 2476 discussion of its usage. 2478 6.28 Proxy-Require 2480 The Proxy-Require header field is used to indicate proxy-sensitive 2481 features that MUST be supported by the proxy. Any Proxy-Require 2482 header field features that are not supported by the proxy MUST be 2483 negatively acknowledged by the proxy to the client if not supported. 2484 Servers treat this field identically to the Require field. 2486 See Section 6.30 for more details on the mechanics of this message 2487 and a usage example. 2489 6.29 Record-Route 2491 The Record-Route request and response header field is added to a 2492 request by any proxy that insists on being in the path of subsequent 2493 requests for the same call leg. It contains a globally reachable 2494 Request-URI that identifies the proxy server. Each proxy server adds 2495 its Request-URI to the beginning of the list. 2497 The server copies the Record-Route header field unchanged into the 2498 response. (Record-Route is only relevant for 2xx responses.) 2500 The calling user agent client copies the Record-Route header into a 2501 Route header field of subsequent requests within the same call leg, 2502 reversing the order of requests, so that the first entry is closest 2503 to the user agent client. If the response contained a Contact header 2504 field, the calling user agent adds its content as the last Route 2505 header. Unless this would cause a loop, any client MUST send any 2506 subsequent requests for this call leg to the first Request-URI in the 2507 Route request header field and remove that entry. 2509 The calling user agent MUST NOT use the Record-Route header field in 2510 requests that contain Route header fields. 2512 Some proxies, such as those controlling firewalls or in an 2513 automatic call distribution (ACD) system, need to maintain 2514 call state and thus need to receive any BYE and ACK packets 2515 for the call. 2517 The Record-Route header field has the following syntax: 2519 Record-Route = "Record-Route" ":" 1# name-addr 2521 Proxy servers SHOULD use the "maddr" URL parameter containing their 2522 address to ensure that subsequent requests are guaranteed to reach 2523 exactly the same server. 2525 Example for a request that has traversed the hosts ieee.org and 2526 bell-telephone.com , in that order: 2528 Record-Route: , 2529 2531 6.30 Require 2533 The Require request-header field is used by clients to tell user 2534 agent servers about options that the client expects the server to 2535 support in order to properly process the request. If a server does 2536 not understand the option, it MUST respond by returning status code 2537 420 (Bad Extension) and list those options it does not understand in 2538 the Unsupported header. 2540 Require = "Require" ":" 1#option-tag 2542 Example: 2544 C->S: INVITE sip:watson@bell-telephone.com SIP/2.0 2545 Require: com.example.billing 2546 Payment: sheep_skins, conch_shells 2548 S->C: SIP/2.0 420 Bad Extension 2549 Unsupported: com.example.billing 2551 This is to make sure that the client-server interaction 2552 will proceed without delay when all options are understood 2553 by both sides, and only slow down if options are not 2554 understood (as in the example above). For a well-matched 2555 client-server pair, the interaction proceeds quickly, 2556 saving a round-trip often required by negotiation 2557 mechanisms. In addition, it also removes ambiguity when the 2558 client requires features that the server does not 2559 understand. Some features, such as call handling fields, 2560 are only of interest to end systems. 2562 Proxy and redirect servers MUST ignore features that are not 2563 understood. If a particular extension requires that intermediate 2564 devices support it, the extension MUST be tagged in the Proxy-Require 2565 field as well (see Section 6.28). 2567 6.31 Response-Key 2569 The Response-Key request-header field can be used by a client to 2570 request the key that the called user agent SHOULD use to encrypt the 2571 response with. The syntax is: 2573 Response-Key = "Response-Key" ":" key-scheme 1*SP #key-param 2574 key-scheme = token 2575 key-param = token "=" ( token | quoted-string ) 2577 The "key-scheme" gives the type of encryption to be used for the 2578 response. Section 13 describes security schemes. 2580 If the client insists that the server return an encrypted response, 2581 it includes a 2583 Require: org.ietf.sip.encrypt-response 2585 header field in its request. If the server cannot encrypt for 2586 whatever reason, it MUST follow normal Require header field 2587 procedures and return a 420 (Bad Extension) response. If this Require 2588 header field is not present, a server SHOULD still encrypt if it can. 2590 6.32 Retry-After 2592 The Retry-After general-header field can be used with a 503 (Service 2593 Unavailable) response to indicate how long the service is expected to 2594 be unavailable to the requesting client and with a 404 (Not Found), 2595 600 (Busy), or 603 (Decline) response to indicate when the called 2596 party anticipates being available again. The value of this field can 2597 be either an SIP-date or an integer number of seconds (in decimal) 2598 after the time of the response. 2600 A REGISTER request MAY include this header field when deleting 2601 registrations with "Contact: * ;expires: 0". The Retry-After value 2602 then indicates when the user might again be reachable. The registrar 2603 MAY then include this information in responses to future calls. 2605 An optional comment can be used to indicate additional information 2606 about the time of callback. An optional "duration" parameter 2607 indicates how long the called party will be reachable starting at the 2608 initial time of availability. If no duration parameter is given, the 2609 service is assumed to be available indefinitely. 2611 Retry-After = "Retry-After" ":" ( SIP-date | delta-seconds ) 2612 [ comment ] [ ";" "duration" "=" delta-seconds ] 2614 Examples of its use are 2616 Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting) 2617 Retry-After: Mon, 01 Jan 9999 00:00:00 GMT 2618 (Dear John: Don't call me back, ever) 2619 Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600 2620 Retry-After: 120 2622 In the third example, the callee is reachable for one hour starting 2623 at 21:00 GMT. In the last example, the delay is 2 minutes. 2625 6.33 Route 2627 The Route request-header field determines the route taken by a 2628 request. Each host removes the first entry and then proxies the 2629 request to the host listed in that entry, also using it as the 2630 Request-URI. The operation is further described in Section 6.29. 2632 The Route header field has the following syntax: 2634 Route = "Route" ":" 1# name-addr 2636 6.34 Server 2638 The Server response-header field contains information about the 2639 software used by the user agent server to handle the request. The 2640 syntax for this field is defined in [H14.39]. 2642 6.35 Subject 2644 This is intended to provide a summary, or to indicate the nature, of 2645 the call, allowing call filtering without having to parse the session 2646 description. (Also, the session description does not have to use the 2647 same subject indication as the invitation.) 2649 Subject = ( "Subject" | "s" ) ":" *TEXT-UTF8 2651 Example: 2653 Subject: Tune in - they are talking about your work! 2655 6.36 Timestamp 2657 The timestamp general-header field describes when the client sent the 2658 request to the server. The value of the timestamp is of significance 2659 only to the client and MAY use any timescale. The server MUST echo 2660 the exact same value and MAY, if it has accurate information about 2661 this, add a floating point number indicating the number of seconds 2662 that have elapsed since it has received the request. The timestamp is 2663 used by the client to compute the round-trip time to the server so 2664 that it can adjust the timeout value for retransmissions. 2666 Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] 2667 delay = *(DIGIT) [ "." *(DIGIT) ] 2669 Note that there MUST NOT be any LWS between a DIGIT and the decimal 2670 point. 2672 6.37 To 2674 The To general-header field specifies recipient of the request, with 2675 the same SIP URL syntax as the From field. 2677 To = ( "To" | "t" ) ":" ( name-addr | addr-spec ) 2678 *( ";" addr-params ) 2680 Requests and responses MUST contain a To general-header field, 2681 indicating the desired recipient of the request. The optional 2682 "display-name" is meant to be rendered by a human-user interface. 2683 The UAS or redirect server copies the To header field into its 2684 response, and MUST add a "tag" parameter if the request contained 2685 more than one Via header field. 2687 If there was more than one Via header field, the request 2688 was handled by at least one proxy server. Since the 2689 receiver cannot know whether any of the proxy servers 2690 forked the request, it is safest to assume that they might 2691 have. 2693 The SIP-URL MUST NOT contain the "transport-param", "maddr-param", 2694 "ttl-param", or "headers" elements. A server that receives a SIP-URL 2695 with these elements removes them before further processing. 2697 The "tag" parameter serves as a general mechanism to distinguish 2698 multiple instances of a user identified by a single SIP URL. As 2699 proxies can fork requests, the same request can reach multiple 2700 instances of a user (mobile and home phones, for example). As each 2701 can respond, there needs to be a means to distinguish the responses 2702 from each at the caller. The situation also arises with multicast 2703 requests. The tag in the To header field serves to distinguish 2704 responses at the UAC. It MUST be placed in the To field of the 2705 response by each instance when there is a possibility that the 2706 request was forked at an intermediate proxy. The "tag" MUST be added 2707 by UAS, registrars and redirect servers, but MUST NOT be inserted 2708 into responses forwarded upstream by proxies. The "tag" is added for 2709 all definitive responses for all methods, and MAY be added for 2710 informational responses from a UAS or redirect server. All subsequent 2711 transactions between two entities MUST include the "tag" parameter, 2712 as described in Section 11. 2714 See Section 6.21 for details of the "tag" parameter. 2716 The "tag" parameter in To headers is ignored when matching responses 2717 to requests that did not contain a "tag" in their To header. 2719 A SIP server returns a 400 (Bad Request) response if it receives a 2720 request with a To header field containing a URI with a scheme it does 2721 not recognize. 2723 Even if the "display-name" is empty, the "name-addr" form MUST be 2724 used if the "addr-spec" contains a comma, question mark, or 2725 semicolon. 2727 The following are examples of valid To headers: 2729 To: The Operator ;tag=287447 2730 To: sip:+12125551212@server.phone2net.com 2732 Call-ID, To and From are needed to identify a call leg. 2733 The distinction between call and call leg matters in calls 2734 with multiple responses from a forked request. The "tag" is 2735 added to the To header field in the response to allow 2736 forking of future requests for the same call by proxies, 2737 while addressing only one of the possibly several 2738 responding user agent servers. It also allows several 2739 instances of the callee to send requests that can be 2740 distinguished. 2742 6.38 Unsupported 2744 The Unsupported response-header field lists the features not 2745 supported by the server. See Section 6.30 for a usage example and 2746 motivation. 2748 Syntax: 2750 Unsupported = "Unsupported" ":" 1#option-tag 2752 6.39 User-Agent 2754 The User-Agent general-header field contains information about the 2755 client user agent originating the request. The syntax and semantics 2756 are defined in [H14.42]. 2758 6.40 Via 2760 The Via field indicates the path taken by the request so far. This 2761 prevents request looping and ensures replies take the same path as 2762 the requests, which assists in firewall traversal and other unusual 2763 routing situations. 2765 6.40.1 Requests 2767 The client originating the request MUST insert into the request a Via 2768 field containing its host name or network address and, if not the 2769 default port number, the port number at which it wishes to receive 2770 responses. (Note that this port number can differ from the UDP source 2771 port number of the request.) A fully-qualified domain name is 2772 RECOMMENDED. Each subsequent proxy server that sends the request 2773 onwards MUST add its own additional Via field before any existing Via 2774 fields. A proxy that receives a redirection (3xx) response and then 2775 searches recursively, MUST use the same Via headers as on the 2776 original proxied request. 2778 A proxy SHOULD check the top-most Via header field to ensure that it 2779 contains the sender's correct network address, as seen from that 2780 proxy. If the sender's address is incorrect, the proxy MUST add an 2781 additional "received" attribute, as described 6.40.2. 2783 A host behind a network address translator (NAT) or 2784 firewall may not be able to insert a network address into 2785 the Via header that can be reached by the next hop beyond 2786 the NAT. Use of the received attribute allows SIP requests 2787 to traverse NAT's which only modify the source IP address. 2788 NAT's which modify port numbers, called Network Address 2789 Port Translator's (NAPT) will not properly pass SIP when 2790 transported on UDP, in which case an application layer 2791 gateway is required. When run over TCP, SIP stands a 2792 better chance of traversing NAT's, since its behavior is 2793 similar to HTTP in this case (but of course on different 2794 ports). 2796 A proxy sending a request to a multicast address MUST add the "maddr" 2797 parameter to its Via header field, and SHOULD add the "ttl" 2798 parameter. If a server receives a request which contained an "maddr" 2799 parameter in the topmost Via field, it SHOULD send the response to 2800 the multicast address listed in the "maddr" parameter. 2802 If a proxy server receives a request which contains its own address 2803 in the Via header value, it MUST respond with a 482 (Loop Detected) 2804 status code. 2806 A proxy server MUST NOT forward a request to a multicast group which 2807 already appears in any of the Via headers. 2809 This prevents a malfunctioning proxy server from causing 2810 loops. Also, it cannot be guaranteed that a proxy server 2811 can always detect that the address returned by a location 2812 service refers to a host listed in the Via list, as a 2813 single host may have aliases or several network interfaces. 2815 6.40.2 Receiver-tagged Via Header Fields 2817 Normally, every host that sends or forwards a SIP message adds a Via 2818 field indicating the path traversed. However, it is possible that 2819 Network Address Translators (NAT) changes the source address and port 2820 of the request (e.g., from net-10 to a globally routable address), in 2821 which case the Via header field cannot be relied on to route replies. 2822 To prevent this, a proxy SHOULD check the top-most Via header field 2823 to ensure that it contains the sender's correct network address, as 2824 seen from that proxy. If the sender's address is incorrect, the proxy 2825 MUST add a "received" parameter to the Via header field inserted by 2826 the previous hop. Such a modified Via header field is known as a 2827 receiver-tagged Via header field. An example is: 2829 Via: SIP/2.0/UDP erlang.bell-telephone.com:5060 2830 Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3 2832 In this example, the message originated from 10.0.0.1 and traversed a 2833 NAT with the external address border.ieee.org (199.172.136.3) to 2834 reach erlang.bell-telephone.com. The latter noticed the mismatch, 2835 and added a parameter to the previous hop's Via header field, 2836 containing the address that the packet actually came from. (Note that 2837 the NAT border.ieee.org is not a SIP server.) 2839 6.40.3 Responses 2841 Via header fields in responses are processed by a proxy or UAC 2842 according to the following rules: 2844 1. The first Via header field should indicate the proxy or 2845 client processing this response. If it does not, discard 2846 the message. Otherwise, remove this Via field. 2848 2. If there is no second Via header field, this response is 2849 destined for this client. Otherwise, the processing depends 2850 on whether the Via field contains a "maddr" parameter or is 2851 a receiver-tagged field: 2853 - If the second Via header field contains a "maddr" 2854 parameter, send the response to the multicast address 2855 listed there, using the port indicated in "sent-by", or 2856 port 5060 if none is present. The response SHOULD be sent 2857 using the TTL indicated in the "ttl" parameter, or with a 2858 TTL of 1 if that parameter is not present. For 2859 robustness, responses MUST be sent to the address 2860 indicated in the "maddr" parameter even if it is not a 2861 multicast address. 2863 - If the second Via header field does not contain a "maddr" 2864 parameter and is a receiver-tagged field (Section 2865 6.40.2), send the message to the address in the 2866 "received" parameter, using the port indicated in the 2867 "sent-by" value, or using port 5060 if none is present. 2869 - If neither of the previous cases apply, send the message 2870 to the address indicated by the "sent-by" value in the 2871 second Via header field. 2873 6.40.4 User Agent and Redirect Servers 2875 A UAS or redirect server sends a response based on one of the 2876 following rules: 2878 o If the first Via header field in the request contains a 2879 "maddr" parameter, send the response to the multicast address 2880 listed there, using the port indicated in "sent-by", or port 2881 5060 if none is present. The response SHOULD be sent using the 2882 TTL indicated in the "ttl" parameter, or with a TTL of 1 if 2883 that parameter is not present. For robustness, responses MUST 2884 be sent to the address indicated in the "maddr" parameter even 2885 if it is not a multicast address. 2887 o If the address in the "sent-by" value of the first Via field 2888 differs from the source address of the packet, send the 2889 response to the actual packet source address, similar to the 2890 treatment for receiver-tagged Via header fields (Section 2891 6.40.2). 2893 o If neither of these conditions is true, send the response to 2894 the address contained in the "sent-by" value. If the request 2895 was sent using TCP, use the existing TCP connection if 2896 available. 2898 6.40.5 Syntax 2900 The format for a Via header field is shown in Fig. 11. The defaults 2901 for "protocol-name" and "transport" are "SIP" and "UDP", 2902 respectively. The "maddr" parameter, designating the multicast 2903 address, and the "ttl" parameter, designating the time-to-live (TTL) 2904 value, are included only if the request was sent via multicast. The 2905 "received" parameter is added only for receiver-added Via fields 2906 (Section 6.40.2). For reasons of privacy, a client or proxy may wish 2907 to hide its Via information by encrypting it (see Section 6.22). The 2908 "hidden" parameter is included if this header field was hidden by the 2909 upstream proxy (see 6.22). Note that privacy of the proxy relies on 2910 the cooperation of the next hop, as the next-hop proxy will, by 2911 necessity, know the IP address and port number of the source host. 2913 Via = ( "Via" | "v") ":" 1#( sent-protocol sent-by 2914 *( ";" via-params ) [ comment ] ) 2915 via-params = via-hidden | via-ttl | via-maddr 2916 | via-received | via-branch 2917 via-hidden = "hidden" 2918 via-ttl = "ttl" "=" ttl 2919 via-maddr = "maddr" "=" maddr 2920 via-received = "received" "=" host 2921 via-branch = "branch" "=" token 2922 sent-protocol = protocol-name "/" protocol-version "/" transport 2923 protocol-name = "SIP" | token 2924 protocol-version = token 2925 transport = "UDP" | "TCP" | token 2926 sent-by = ( host [ ":" port ] ) | ( concealed-host ) 2927 concealed-host = token 2928 ttl = 1*3DIGIT ; 0 to 255 2930 Figure 11: Syntax of Via header field 2932 The "branch" parameter is included by every forking proxy. The token 2933 MUST be unique for each distinct request generated when a proxy 2934 forks. CANCEL requests MUST have the same branch value as the 2935 corresponding forked request. When a response arrives at the proxy 2936 it can use the branch value to figure out which branch the response 2937 corresponds to. A proxy which generates a single request (non- 2938 forking) MAY also insert the "branch" parameter. The identifier has 2939 to be unique only within a set of isomorphic requests. 2941 Via: SIP/2.0/UDP first.example.com:4000;ttl=16 2942 ;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example) 2943 Via: SIP/2.0/UDP adk8 2945 6.41 Warning 2947 The Warning response-header field is used to carry additional 2948 information about the status of a response. Warning headers are sent 2949 with responses and have the following format: 2951 Warning = "Warning" ":" 1#warning-value 2952 warning-value = warn-code SP warn-agent SP warn-text 2953 warn-code = 3DIGIT 2954 warn-agent = ( host [ ":" port ] ) | pseudonym 2955 ; the name or pseudonym of the server adding 2956 ; the Warning header, for use in debugging 2957 warn-text = quoted-string 2959 A response MAY carry more than one Warning header. 2961 The "warn-text" should be in a natural language that is most likely 2962 to be intelligible to the human user receiving the response. This 2963 decision can be based on any available knowledge, such as the 2964 location of the cache or user, the Accept-Language field in a 2965 request, or the Content-Language field in a response. The default 2966 language is i-default [31]. 2968 Any server MAY add Warning headers to a response. Proxy servers MUST 2969 place additional Warning headers before any Authorization headers. 2970 Within that constraint, Warning headers MUST be added after any 2971 existing Warning headers not covered by a signature. A proxy server 2972 MUST NOT delete any Warning header field that it received with a 2973 response. 2975 When multiple Warning headers are attached to a response, the user 2976 agent SHOULD display as many of them as possible, in the order that 2977 they appear in the response. If it is not possible to display all of 2978 the warnings, the user agent first displays warnings that appear 2979 early in the response. 2981 The warn-code consists of three digits. A first digit of "3" 2982 indicates warnings specific to SIP. 2984 This is a list of the currently-defined "warn-code"s, each with a 2985 recommended warn-text in English, and a description of its meaning. 2986 Note that these warnings describe failures induced by the session 2987 description. 2989 Warnings 300 through 329 are reserved for indicating problems with 2990 keywords in the session description, 330 through 339 are warnings 2991 related to basic network services requested in the session 2992 description, 370 through 379 are warnings related to quantitative QoS 2993 parameters requested in the session description, and 390 through 399 2994 are miscellaneous warnings that do not fall into one of the above 2995 categories. 2997 300 Incompatible network protocol: One or more network protocols 2998 contained in the session description are not available. 3000 301 Incompatible network address formats: One or more network address 3001 formats contained in the session description are not available. 3003 302 Incompatible transport protocol: One or more transport protocols 3004 described in the session description are not available. 3006 303 Incompatible bandwidth units: One or more bandwidth measurement 3007 units contained in the session description were not understood. 3009 304 Media type not available: One or more media types contained in 3010 the session description are not available. 3012 305 Incompatible media format: One or more media formats contained in 3013 the session description available. 3015 306 Attribute not understood: One or more of the media attributes in 3016 the session description are not supported. 3018 307 Session description parameter not understood: A parameter other 3019 than those listed above was not understood. 3021 330 Multicast not available: The site where the user is located does 3022 not support multicast. 3024 331 Unicast not available: The site where the user is located does 3025 not support unicast communication (usually due to the presence 3026 of a firewall). 3028 370 Insufficient bandwidth: The bandwidth specified in the session 3029 description or defined by the media exceeds that known to be 3030 available. 3032 399 Miscellaneous warning: The warning text can include arbitrary 3033 information to be presented to a human user, or logged. A system 3034 receiving this warning MUST NOT take any automated action. 3036 1xx and 2xx have been taken by HTTP/1.1. 3038 Additional "warn-code"s, as in the example below, can be defined 3039 through IANA. 3041 Examples: 3043 Warning: 307 isi.edu "Session parameter 'foo' not understood" 3044 Warning: 301 isi.edu "Incompatible network address type 'E.164'" 3046 6.42 WWW-Authenticate 3048 The WWW-Authenticate response-header field MUST be included in 401 3049 (Unauthorized) response messages. The field value consists of at 3050 least one challenge that indicates the authentication scheme(s) and 3051 parameters applicable to the Request-URI. See [H14.46] for a 3052 definition of the syntax, and section 14 for an overview of usage. 3054 The content of the "realm" parameter SHOULD be displayed to the user. 3055 A user agent SHOULD cache the authorization credentials for a given 3056 value of the destination (To header) and "realm" and attempt to re- 3057 use these values on the next request for that destination. 3059 In addition to the "basic" and "digest" authentication schemes 3060 defined in the specifications cited above, SIP defines a new scheme, 3061 PGP (RFC 2015, [32]), Section 15. Other schemes, such as S/MIME, are 3062 for further study. 3064 7 Status Code Definitions 3066 The response codes are consistent with, and extend, HTTP/1.1 response 3067 codes. Not all HTTP/1.1 response codes are appropriate, and only 3068 those that are appropriate are given here. Other HTTP/1.1 response 3069 codes SHOULD NOT be used. Response codes not defined by HTTP/1.1 have 3070 codes x80 upwards to avoid clashes with future HTTP response codes. 3071 Also, SIP defines a new class, 6xx. The default behavior for unknown 3072 response codes is given for each category of codes. 3074 7.1 Informational 1xx 3076 Informational responses indicate that the server or proxy contacted 3077 is performing some further action and does not yet have a definitive 3078 response. The client SHOULD wait for a further response from the 3079 server, and the server SHOULD send such a response without further 3080 prompting. A server SHOULD send a 1xx response if it expects to take 3081 more than 200 ms to obtain a final response. A server MAY issue zero 3082 or more 1xx responses, with no restriction on their ordering or 3083 uniqueness. Note that 1xx responses are not transmitted reliably, 3084 that is, they do not cause the client to send an ACK. Servers are 3085 free to retransmit informational responses and clients can inquire 3086 about the current state of call processing by re-sending the request. 3088 7.1.1 100 Trying 3090 Some unspecified action is being taken on behalf of this call (e.g., 3091 a database is being consulted), but the user has not yet been 3092 located. 3094 7.1.2 180 Ringing 3096 The called user agent has located a possible location where the user 3097 has registered recently and is trying to alert the user. 3099 7.1.3 181 Call Is Being Forwarded 3101 A proxy server MAY use this status code to indicate that the call is 3102 being forwarded to a different set of destinations. 3104 7.1.4 182 Queued 3106 The called party is temporarily unavailable, but the callee has 3107 decided to queue the call rather than reject it. When the callee 3108 becomes available, it will return the appropriate final status 3109 response. The reason phrase MAY give further details about the status 3110 of the call, e.g., "5 calls queued; expected waiting time is 15 3111 minutes". The server MAY issue several 182 responses to update the 3112 caller about the status of the queued call. 3114 7.2 Successful 2xx 3116 The request was successful and MUST terminate a search. 3118 7.2.1 200 OK 3120 The request has succeeded. The information returned with the response 3121 depends on the method used in the request, for example: 3123 BYE: The call has been terminated. The message body is empty. 3125 CANCEL: The search has been cancelled. The message body is empty. 3127 INVITE: The callee has agreed to participate; the message body 3128 indicates the callee's capabilities. 3130 OPTIONS: The callee has agreed to share its capabilities, included in 3131 the message body. 3133 REGISTER: The registration has succeeded. The client treats the 3134 message body according to its Content-Type. 3136 7.3 Redirection 3xx 3138 3xx responses give information about the user's new location, or 3139 about alternative services that might be able to satisfy the call. 3140 They SHOULD terminate an existing search, and MAY cause the initiator 3141 to begin a new search if appropriate. 3143 Any redirection (3xx) response MUST NOT suggest any of the addresses 3144 in the Via (Section 6.40) path of the request in the Contact header 3145 field. (Addresses match if their host and port number match.) 3147 To avoid forwarding loops, a user agent client or proxy MUST check 3148 whether the address returned by a redirect server equals an address 3149 tried earlier. 3151 7.3.1 300 Multiple Choices 3153 The address in the request resolved to several choices, each with its 3154 own specific location, and the user (or user agent) can select a 3155 preferred communication end point and redirect its request to that 3156 location. 3158 The response SHOULD include an entity containing a list of resource 3159 characteristics and location(s) from which the user or user agent can 3160 choose the one most appropriate, if allowed by the Accept request 3161 header. The entity format is specified by the media type given in the 3162 Content-Type header field. The choices SHOULD also be listed as 3163 Contact fields (Section 6.13). Unlike HTTP, the SIP response MAY 3164 contain several Contact fields or a list of addresses in a Contact 3165 field. User agents MAY use the Contact header field value for 3166 automatic redirection or MAY ask the user to confirm a choice. 3167 However, this specification does not define any standard for such 3168 automatic selection. 3170 This status response is appropriate if the callee can be 3171 reached at several different locations and the server 3172 cannot or prefers not to proxy the request. 3174 7.3.2 301 Moved Permanently 3176 The user can no longer be found at the address in the Request-URI and 3177 the requesting client SHOULD retry at the new address given by the 3178 Contact header field (Section 6.13). The caller SHOULD update any 3179 local directories, address books and user location caches with this 3180 new value and redirect future requests to the address(es) listed. 3182 7.3.3 302 Moved Temporarily 3184 The requesting client SHOULD retry the request at the new address(es) 3185 given by the Contact header field (Section 6.13). The duration of 3186 the redirection can be indicated through an Expires (Section 6.20) 3187 header. If there is no explicit expiration time, the address is only 3188 valid for this call and MUST NOT be cached for future calls. 3190 7.3.4 305 Use Proxy 3192 The requested resource MUST be accessed through the proxy given by 3193 the Contact field. The Contact field gives the URI of the proxy. The 3194 recipient is expected to repeat this single request via the proxy. 3195 305 responses MUST only be generated by user agent servers. 3197 7.3.5 380 Alternative Service 3199 The call was not successful, but alternative services are possible. 3200 The alternative services are described in the message body of the 3201 response. Formats for such bodies are not defined here, and may be 3202 the subject of future standardization. 3204 7.4 Request Failure 4xx 3206 4xx responses are definite failure responses from a particular 3207 server. The client SHOULD NOT retry the same request without 3208 modification (e.g., adding appropriate authorization). However, the 3209 same request to a different server might be successful. 3211 7.4.1 400 Bad Request 3212 The request could not be understood due to malformed syntax. 3214 7.4.2 401 Unauthorized 3216 The request requires user authentication. 3218 7.4.3 402 Payment Required 3220 Reserved for future use. 3222 7.4.4 403 Forbidden 3224 The server understood the request, but is refusing to fulfill it. 3225 Authorization will not help, and the request SHOULD NOT be repeated. 3227 7.4.5 404 Not Found 3229 The server has definitive information that the user does not exist at 3230 the domain specified in the Request-URI. This status is also returned 3231 if the domain in the Request-URI does not match any of the domains 3232 handled by the recipient of the request. 3234 7.4.6 405 Method Not Allowed 3236 The method specified in the Request-Line is not allowed for the 3237 address identified by the Request-URI. The response MUST include an 3238 Allow header field containing a list of valid methods for the 3239 indicated address. 3241 7.4.7 406 Not Acceptable 3243 The resource identified by the request is only capable of generating 3244 response entities which have content characteristics not acceptable 3245 according to the accept headers sent in the request. 3247 7.4.8 407 Proxy Authentication Required 3249 This code is similar to 401 (Unauthorized), but indicates that the 3250 client MUST first authenticate itself with the proxy. The proxy MUST 3251 return a Proxy-Authenticate header field (section 6.26) containing a 3252 challenge applicable to the proxy for the requested resource. The 3253 client MAY repeat the request with a suitable Proxy-Authorization 3254 header field (section 6.27). SIP access authentication is explained 3255 in section 13.2 and 14. 3257 This status code is used for applications where access to the 3258 communication channel (e.g., a telephony gateway) rather than the 3259 callee requires authentication. 3261 7.4.9 408 Request Timeout 3263 The server could not produce a response, e.g., a user location, 3264 within the time indicated in the Expires request-header field. The 3265 client MAY repeat the request without modifications at any later 3266 time. 3268 7.4.10 409 Conflict 3270 The request could not be completed due to a conflict with the current 3271 state of the resource. This response is returned if the action 3272 parameter in a REGISTER request conflicts with existing 3273 registrations. 3275 7.4.11 410 Gone 3277 The requested resource is no longer available at the server and no 3278 forwarding address is known. This condition is expected to be 3279 considered permanent. If the server does not know, or has no facility 3280 to determine, whether or not the condition is permanent, the status 3281 code 404 (Not Found) SHOULD be used instead. 3283 7.4.12 411 Length Required 3285 The server refuses to accept the request without a defined Content- 3286 Length. The client MAY repeat the request if it adds a valid 3287 Content-Length header field containing the length of the message-body 3288 in the request message. 3290 7.4.13 413 Request Entity Too Large 3292 The server is refusing to process a request because the request 3293 entity is larger than the server is willing or able to process. The 3294 server MAY close the connection to prevent the client from continuing 3295 the request. 3297 If the condition is temporary, the server SHOULD include a Retry- 3298 After header field to indicate that it is temporary and after what 3299 time the client MAY try again. 3301 7.4.14 414 Request-URI Too Long 3303 The server is refusing to service the request because the Request-URI 3304 is longer than the server is willing to interpret. 3306 7.4.15 415 Unsupported Media Type 3308 The server is refusing to service the request because the message 3309 body of the request is in a format not supported by the requested 3310 resource for the requested method. The server SHOULD return a list of 3311 acceptable formats using the Accept, Accept-Encoding and Accept- 3312 Language header fields. 3314 7.4.16 420 Bad Extension 3316 The server did not understand the protocol extension specified in a 3317 Require (Section 6.30) header field. 3319 7.4.17 480 Temporarily Unavailable 3321 The callee's end system was contacted successfully but the callee is 3322 currently unavailable (e.g., not logged in or logged in in such a 3323 manner as to preclude communication with the callee). The response 3324 MAY indicate a better time to call in the Retry-After header. The 3325 user could also be available elsewhere (unbeknownst to this host), 3326 thus, this response does not terminate any searches. The reason 3327 phrase SHOULD indicate a more precise cause as to why the callee is 3328 unavailable. This value SHOULD be setable by the user agent. Status 3329 486 (Busy Here) MAY be used to more precisely indicate a particular 3330 reason for the call failure. 3332 This status is also returned by a redirect server that recognizes the 3333 user identified by the Request-URI, but does not currently have a 3334 valid forwarding location for that user. 3336 7.4.18 481 Call Leg/Transaction Does Not Exist 3338 This status is returned under two conditions: The server received a 3339 BYE request that does not match any existing call leg or the server 3340 received a CANCEL request that does not match any existing 3341 transaction. (A server simply discards an ACK referring to an unknown 3342 transaction.) 3344 7.4.19 482 Loop Detected 3346 The server received a request with a Via (Section 6.40) path 3347 containing itself. 3349 7.4.20 483 Too Many Hops 3351 The server received a request that contains more Via entries (hops) 3352 (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header 3353 field. 3355 7.4.21 484 Address Incomplete 3356 The server received a request with a To (Section 6.37) address or 3357 Request-URI that was incomplete. Additional information SHOULD be 3358 provided. 3360 This status code allows overlapped dialing. With overlapped 3361 dialing, the client does not know the length of the dialing 3362 string. It sends strings of increasing lengths, prompting 3363 the user for more input, until it no longer receives a 484 3364 status response. 3366 7.4.22 485 Ambiguous 3368 The callee address provided in the request was ambiguous. The 3369 response MAY contain a listing of possible unambiguous addresses in 3370 Contact headers. 3372 Revealing alternatives can infringe on privacy concerns of the user 3373 or the organization. It MUST be possible to configure a server to 3374 respond with status 404 (Not Found) or to suppress the listing of 3375 possible choices if the request address was ambiguous. 3377 Example response to a request with the URL lee@example.com : 3379 485 Ambiguous SIP/2.0 3380 Contact: Carol Lee 3381 Contact: Ping Lee 3382 Contact: Lee M. Foote 3384 Some email and voice mail systems provide this 3385 functionality. A status code separate from 3xx is used 3386 since the semantics are different: for 300, it is assumed 3387 that the same person or service will be reached by the 3388 choices provided. While an automated choice or sequential 3389 search makes sense for a 3xx response, user intervention is 3390 required for a 485 response. 3392 7.4.23 486 Busy Here 3394 The callee's end system was contacted successfully but the callee is 3395 currently not willing or able to take additional calls. The response 3396 MAY indicate a better time to call in the Retry-After header. The 3397 user could also be available elsewhere, such as through a voice mail 3398 service, thus, this response does not terminate any searches. Status 3399 600 (Busy Everywhere) SHOULD be used if the client knows that no 3400 other end system will be able to accept this call. 3402 7.5 Server Failure 5xx 3404 5xx responses are failure responses given when a server itself has 3405 erred. They are not definitive failures, and MUST NOT terminate a 3406 search if other possible locations remain untried. 3408 7.5.1 500 Server Internal Error 3410 The server encountered an unexpected condition that prevented it from 3411 fulfilling the request. The client MAY display the specific error 3412 condition, and MAY retry the request after several seconds. 3414 7.5.2 501 Not Implemented 3416 The server does not support the functionality required to fulfill the 3417 request. This is the appropriate response when the server does not 3418 recognize the request method and is not capable of supporting it for 3419 any user. 3421 7.5.3 502 Bad Gateway 3423 The server, while acting as a gateway or proxy, received an invalid 3424 response from the downstream server it accessed in attempting to 3425 fulfill the request. 3427 7.5.4 503 Service Unavailable 3429 The server is currently unable to handle the request due to a 3430 temporary overloading or maintenance of the server. The implication 3431 is that this is a temporary condition which will be alleviated after 3432 some delay. If known, the length of the delay MAY be indicated in a 3433 Retry-After header. If no Retry-After is given, the client MUST 3434 handle the response as it would for a 500 response. 3436 Note: The existence of the 503 status code does not imply that a 3437 server has to use it when becoming overloaded. Some servers MAY wish 3438 to simply refuse the connection. 3440 7.5.5 504 Gateway Time-out 3442 The server, while acting as a gateway, did not receive a timely 3443 response from the server (e.g., a location server) it accessed in 3444 attempting to complete the request. 3446 7.5.6 505 Version Not Supported 3447 The server does not support, or refuses to support, the SIP protocol 3448 version that was used in the request message. The server is 3449 indicating that it is unable or unwilling to complete the request 3450 using the same major version as the client, other than with this 3451 error message. The response MAY contain an entity describing why that 3452 version is not supported and what other protocols are supported by 3453 that server. The format for such an entity is not defined here and 3454 may be the subject of future standardization. 3456 7.6 Global Failures 6xx 3458 6xx responses indicate that a server has definitive information about 3459 a particular user, not just the particular instance indicated in the 3460 Request-URI. All further searches for this user are doomed to failure 3461 and pending searches SHOULD be terminated. 3463 7.6.1 600 Busy Everywhere 3465 The callee's end system was contacted successfully but the callee is 3466 busy and does not wish to take the call at this time. The response 3467 MAY indicate a better time to call in the Retry-After header. If the 3468 callee does not wish to reveal the reason for declining the call, the 3469 callee uses status code 603 (Decline) instead. This status response 3470 is returned only if the client knows that no other end point (such as 3471 a voice mail system) will answer the request. Otherwise, 486 (Busy 3472 Here) should be returned. 3474 7.6.2 603 Decline 3476 The callee's machine was successfully contacted but the user 3477 explicitly does not wish to or cannot participate. The response MAY 3478 indicate a better time to call in the Retry-After header. 3480 7.6.3 604 Does Not Exist Anywhere 3482 The server has authoritative information that the user indicated in 3483 the To request field does not exist anywhere. Searching for the user 3484 elsewhere will not yield any results. 3486 7.6.4 606 Not Acceptable 3488 The user's agent was contacted successfully but some aspects of the 3489 session description such as the requested media, bandwidth, or 3490 addressing style were not acceptable. 3492 A 606 (Not Acceptable) response means that the user wishes to 3493 communicate, but cannot adequately support the session described. The 3494 606 (Not Acceptable) response MAY contain a list of reasons in a 3495 Warning header field describing why the session described cannot be 3496 supported. Reasons are listed in Section 6.41. It is hoped that 3497 negotiation will not frequently be needed, and when a new user is 3498 being invited to join an already existing conference, negotiation may 3499 not be possible. It is up to the invitation initiator to decide 3500 whether or not to act on a 606 (Not Acceptable) response. 3502 8 SIP Message Body 3504 8.1 Body Inclusion 3506 Requests MAY contain message bodies unless otherwise noted. Within 3507 this specification, the BYE request MUST NOT contain a message body. 3508 For ACK, INVITE and OPTIONS, the message body is always a session 3509 description. The use of message bodies for REGISTER requests is for 3510 further study. 3512 For response messages, the request method and the response status 3513 code determine the type and interpretation of any message body. All 3514 responses MAY include a body. Message bodies for 1xx responses 3515 contain advisory information about the progress of the request. 2xx 3516 responses to INVITE requests contain session descriptions. In 3xx 3517 responses, the message body MAY contain the description of 3518 alternative destinations or services, as described in Section 7.3. 3519 For responses with status 400 or greater, the message body MAY 3520 contain additional, human-readable information about the reasons for 3521 failure. It is RECOMMENDED that information in 1xx and 300 and 3522 greater responses be of type text/plain or text/html 3524 8.2 Message Body Type 3526 The Internet media type of the message body MUST be given by the 3527 Content-Type header field. If the body has undergone any encoding 3528 (such as compression) then this MUST be indicated by the Content- 3529 Encoding header field, otherwise Content-Encoding MUST be omitted. If 3530 applicable, the character set of the message body is indicated as 3531 part of the Content-Type header-field value. 3533 8.3 Message Body Length 3535 The body length in bytes SHOULD be given by the Content-Length header 3536 field. Section 6.15 describes the behavior in detail. 3538 The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. 3539 (Note: The chunked encoding modifies the body of a message in order 3540 to transfer it as a series of chunks, each with its own size 3541 indicator.) 3543 9 Compact Form 3545 When SIP is carried over UDP with authentication and a complex 3546 session description, it may be possible that the size of a request or 3547 response is larger than the MTU. To address this problem, a more 3548 compact form of SIP is also defined by using abbreviations for the 3549 common header fields listed below: 3551 short field name long field name note 3552 c Content-Type 3553 e Content-Encoding 3554 f From 3555 i Call-ID 3556 m Contact from "moved" 3557 l Content-Length 3558 s Subject 3559 t To 3560 v Via 3562 Thus, the message in section 16.2 could also be written: 3564 INVITE sip:schooler@vlsi.caltech.edu SIP/2.0 3565 v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16 3566 v:SIP/2.0/UDP 128.16.64.19 3567 f:sip:mjh@isi.edu 3568 t:sip:schooler@cs.caltech.edu 3569 i:62729-27@128.16.64.19 3570 c:application/sdp 3571 CSeq: 4711 INVITE 3572 l:187 3574 v=0 3575 o=user1 53655765 2353687637 IN IP4 128.3.4.5 3576 s=Mbone Audio 3577 i=Discussion of Mbone Engineering Issues 3578 e=mbone@somewhere.com 3579 c=IN IP4 224.2.0.1/127 3580 t=0 0 3581 m=audio 3456 RTP/AVP 0 3583 Clients MAY mix short field names and long field names within the 3584 same request. Servers MUST accept both short and long field names for 3585 requests. Proxies MAY change header fields between their long and 3586 short forms, but this MUST NOT be done to fields following an 3587 Authorization header. 3589 10 Behavior of SIP Clients and Servers 3591 10.1 General Remarks 3593 SIP is defined so it can use either UDP (unicast or multicast) or TCP 3594 as a transport protocol; it provides its own reliability mechanism. 3596 10.1.1 Requests 3598 Servers discard isomorphic requests, but first retransmit the 3599 appropriate response. (SIP requests are said to be idempotent , i.e., 3600 receiving more than one copy of a request does not change the server 3601 state.) 3603 After receiving a CANCEL request from an upstream client, a stateful 3604 proxy server MAY send a CANCEL on all branches where it has not yet 3605 received a final response. 3607 When a user agent receives a request, it checks the Call-ID against 3608 those of in-progress calls. If the Call-ID was found, it compares the 3609 tag value of To with the user's tag and rejects the request if the 3610 two do not match. If the From header, including any tag value, 3611 matches the value for an existing call leg, the server compares the 3612 CSeq header field value. If less than or equal to the current 3613 sequence number, the request is a retransmission. Otherwise, it is a 3614 new request. If the From header does not match an existing call leg, 3615 a new call leg is created. 3617 If the Call-ID was not found, a new call leg is created, with entries 3618 for the To, From and Call-ID headers. In this case, the To header 3619 field should not have contained a tag. The server returns a response 3620 containing the same To value, but with a unique tag added. The tag 3621 MAY be omitted if the request contained only one Via header field. 3623 10.1.2 Responses 3625 A server MAY issue one or more provisional responses at any time 3626 before sending a final response. If a stateful proxy, user agent 3627 server, redirect server or registrar cannot respond to a request with 3628 a final response within 200 ms, it SHOULD issue a provisional (1xx) 3629 response as soon as possible. Stateless proxies MUST NOT issue 3630 provisional responses on their own. 3632 Responses are mapped to requests by the matching To, From, Call-ID, 3633 CSeq headers and the branch parameter of the first Via header. 3635 Responses terminate request retransmissions even if they have Via 3636 headers that cause them to be delivered to an upstream client. 3638 A stateful proxy may receive a response that it does not have state 3639 for, that is, where it has no a record of an associated request. If 3640 the Via header field indicates that the upstream server used TCP, the 3641 proxy actively opens a TCP connection to that address. Thus, proxies 3642 have to be prepared to receive responses on the incoming side of 3643 passive TCP connections, even though most responses will arrive on 3644 the incoming side of an active connection. (An active connection is a 3645 TCP connection initiated by the proxy, a passive connection is one 3646 accepted by the proxy, but initiated by another entity.) 3648 100 responses SHOULD NOT be forwarded, other 1xx responses MAY be 3649 forwarded, possibly after the server eliminates responses with status 3650 codes that had already been sent earlier. 2xx responses are forwarded 3651 according to the Via header. Once a stateful proxy has received a 2xx 3652 response, it MUST NOT forward non-2xx final responses. Responses 3653 with status 300 and higher are retransmitted by each stateful proxy 3654 until the next upstream proxy sends an ACK (see below for timing 3655 details) or CANCEL. 3657 A stateful proxy SHOULD maintain state for at least 32 seconds after 3658 the receipt of the first definitive non-200 response, in order to 3659 handle retransmissions of the response. 3661 The 32 second window is given by the maximum retransmission 3662 duration of 200-class responses using the default timers, 3663 in case the ACK is lost somewhere on the way to the called 3664 user agent or the next stateful proxy. 3666 10.2 Source Addresses, Destination Addresses and Connections 3668 10.2.1 Unicast UDP 3670 Responses are returned to the address listed in the Via header field 3671 (Section 6.40), not the source address of the request. 3673 Recall that responses are not generated by the next-hop 3674 stateless server, but generated by either a proxy server or 3675 the user agent server. Thus, the stateless proxy can only 3676 use the Via header field to forward the response. 3678 10.2.2 Multicast UDP 3680 Requests MAY be multicast; multicast requests likely feature a host- 3681 independent Request-URI. This request SHOULD be scoped to ensure it 3682 is not forwarded beyond the boundaries of the administrative system. 3683 This MAY be done with either TTL or administrative scopes[25], 3684 depending on what is implemented in the network. 3686 A client receiving a multicast query does not have to check whether 3687 the host part of the Request-URI matches its own host or domain name. 3688 If the request was received via multicast, the response is also 3689 returned via multicast. Responses to multicast requests are multicast 3690 with the same TTL as the request, where the TTL is derived from the 3691 ttl parameter in the Via header (Section 6.40). 3693 To avoid response implosion, servers MUST NOT answer multicast 3694 requests with a status code other than 2xx or 6xx. The server delays 3695 its response by a random interval uniformly distributed between zero 3696 and one second. Servers MAY suppress responses if they hear a lower- 3697 numbered or 6xx response from another group member prior to sending. 3698 Servers do not respond to CANCEL requests received via multicast to 3699 avoid request implosion. A proxy or UAC SHOULD send a CANCEL on 3700 receiving the first 2xx or 6xx response to a multicast request. 3702 Server response suppression is a MAY since it requires a 3703 server to violate some basic message processing rules. Lets 3704 say A sends a multicast request, and it is received by B,C, 3705 and D. B sends a 200 response. The topmost Via field in the 3706 response will contain the address of A. C will also receive 3707 this response, and could use it to suppress its own 3708 response. However, C would normally not examine this 3709 response, as the topmost Via is not its own. Normally, a 3710 response received with an incorrect topmost Via MUST be 3711 dropped, but not in this case. To distinguish this packet 3712 from a misrouted or multicast looped packet is fairly 3713 complex, and for this reason the procedure is a MAY. The 3714 CANCEL, instead, provides a simpler and more standard way 3715 to perform response suppression. It is for this reason that 3716 the use of CANCEL here is a SHOULD 3718 10.3 TCP 3720 A single TCP connection can serve one or more SIP transactions. A 3721 transaction contains zero or more provisional responses followed by 3722 one or more final responses. (Typically, transactions contain exactly 3723 one final response, but there are exceptional circumstances, where, 3724 for example, multiple 200 responses can be generated.) 3726 The client SHOULD keep the connection open at least until the first 3727 final response arrives. If the client closes or resets the TCP 3728 connection prior to receiving the first final response, the server 3729 treats this action as equivalent to a CANCEL request. 3731 This behavior makes it less likely that malfunctioning 3732 clients cause a proxy server to keep connection state 3733 indefinitely. 3735 The server SHOULD NOT close the TCP connection until it has sent its 3736 final response, at which point it MAY close the TCP connection if it 3737 wishes to. However, normally it is the client's responsibility to 3738 close the connection. 3740 If the server leaves the connection open, and if the client so 3741 desires it MAY re-use the connection for further SIP requests or for 3742 requests from the same family of protocols (such as HTTP or stream 3743 control commands). 3745 If a server needs to return a response to a client and no longer has 3746 a connection open to that client, it MAY open a connection to the 3747 address listed in the Via header. Thus, a proxy or user agent MUST be 3748 prepared to receive both requests and responses on a "passive" 3749 connection. 3751 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER Requests 3753 10.4.1 UDP 3755 A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or 3756 REGISTER request with an exponential backoff, starting at a T1 second 3757 interval, doubling the interval for each packet, and capping off at a 3758 T2 second interval. This means that after the first packet is sent, 3759 the second is sent T1 seconds later, the next 2*T1 seconds after 3760 that, the next 4*T1 seconds after that, and so on, until the interval 3761 hits T2. Subsequent retransmissions are spaced by T2 seconds. If the 3762 client receives a provisional response, it continues to retransmit 3763 the request, but with an interval of T2 seconds. Retransmissions 3764 cease when the client has sent a total of eleven packets, or receives 3765 a definitive response. Default values for T1 and T2 are 500 ms and 4 3766 s, respectively. Clients MAY use larger values, but SHOULD NOT use 3767 smaller ones. Servers retransmit the response upon receipt of a 3768 request retransmission. After the server sends a final response, it 3769 cannot be sure the client has received the response, and thus SHOULD 3770 cache the results for at least 10*T2 seconds to avoid having to, for 3771 example, contact the user or location server again upon receiving a 3772 request retransmission. 3774 Use of the exponential backoff is for congestion control 3775 purposes. However, the back-off must cap off, since request 3776 retransmissions are used to trigger response 3777 retransmissions at the server. Without a cap, the loss of a 3778 single response could significantly increase transaction 3779 latencies. 3781 The value of the initial retransmission timer is smaller than that 3782 that for TCP since it is expected that network paths suitable for 3783 interactive communications have round-trip times smaller than 500 ms. 3784 For congestion control purposes, the retransmission count has to be 3785 bounded. Given that most transactions are expected to consist of one 3786 request and a few responses, round-trip time estimation is not likely 3787 to be very useful. If RTT estimation is desired to more quickly 3788 discover a missing final response, each request retransmission needs 3789 to be labeled with its own Timestamp (Section 6.36), returned in the 3790 response. The server caches the result until it can be sure that the 3791 client will not retransmit the same request again. 3793 Each server in a proxy chain generates its own final response to a 3794 CANCEL request. The server responds immediately upon receipt of the 3795 CANCEL request rather than waiting until it has received final 3796 responses from the CANCEL requests it generates. 3798 BYE and OPTIONS final responses are generated by redirect and user 3799 agent servers; REGISTER final responses are generated by registrars. 3800 Note that in contrast to the reliability mechanism described in 3801 Section 10.5, responses to these requests are not retransmitted 3802 periodically and not acknowledged via ACK. 3804 10.4.2 TCP 3806 Clients using TCP do not need to retransmit requests. 3808 10.5 Reliability for INVITE Requests 3810 Special considerations apply for the INVITE method. 3812 1. After receiving an invitation, considerable time can elapse 3813 before the server can determine the outcome. For example, 3814 if the called party is "rung" or extensive searches are 3815 performed, delays between the request and a definitive 3816 response can reach several tens of seconds. If either 3817 caller or callee are automated servers not directly 3818 controlled by a human being, a call attempt could be 3819 unbounded in time. 3821 2. If a telephony user interface is modeled or if we need to 3822 interface to the PSTN, the caller's user interface will 3823 provide "ringback", a signal that the callee is being 3824 alerted. (The status response 180 (Ringing) MAY be used to 3825 initiate ringback.) Once the callee picks up, the caller 3826 needs to know so that it can enable the voice path and stop 3827 ringback. The callee's response to the invitation could get 3828 lost. Unless the response is transmitted reliably, the 3829 caller will continue to hear ringback while the callee 3830 assumes that the call exists. 3832 3. The client has to be able to terminate an on-going request, 3833 e.g., because it is no longer willing to wait for the 3834 connection or search to succeed. The server will have to 3835 wait several retransmission intervals to interpret the lack 3836 of request retransmissions as the end of a call. If the 3837 call succeeds shortly after the caller has given up, the 3838 callee will "pick up the phone" and not be "connected". 3840 10.5.1 UDP 3842 For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an 3843 interval that starts at T1 seconds, and doubles after each packet 3844 transmission. The client ceases retransmissions if it receives a 3845 provisional or definitive response, or once it has sent a total of 7 3846 request packets. 3848 A server which transmits a provisional response should retransmit it 3849 upon reception of a duplicate request. A server which transmits a 3850 final response should retransmit it with an interval that starts at 3851 T1 seconds, and doubles for each subsequent packet. Response 3852 retransmissions cease when any one of the following occurs: 3854 1. An ACK request for the same transaction is received; 3856 2. a BYE request for the same call leg is received; 3858 3. a CANCEL request for the same call leg is received and the 3859 final response status was equal or greater to 300; 3861 4. the response has been transmitted 7 times. 3863 Only the user agent client generates an ACK for 2xx final responses, 3864 If the response contained a Contact header field, the ACK MAY be sent 3865 to the address listed in that Contact header field. If the response 3866 did not contain a Contact header, the client uses the same To header 3867 field and Request-URI as for the INVITE request and sends the ACK to 3868 the same destination as the original INVITE request. ACKs for final 3869 responses other than 2xx are sent to the same server that the 3870 original request was sent to, using the same Request-URI as the 3871 original request. Note, however, that the To header field in the ACK 3872 is copied from the response being acknowledged, not the request, and 3873 thus MAY additionally contain the tag parameter. Also note than 3874 unlike 2xx final responses, a proxy generates an ACK for non-2xx 3875 final responses. 3877 The ACK request MUST NOT be acknowledged to prevent a response-ACK 3878 feedback loop. Fig. 12 and 13 show the client and server state 3879 diagram for invitations. 3881 The mechanism in Sec. 10.4 would not work well for INVITE 3882 because of the long delays between INVITE and a final 3883 response. If the 200 response were to get lost, the callee 3884 would believe the call to exist, but the voice path would 3885 be dead since the caller does not know that the callee has 3886 picked up. Thus, the INVITE retransmission interval would 3887 have to be on the order of a second or two to limit the 3888 duration of this state confusion. Retransmitting the 3889 response with an exponential back-off helps ensure that the 3890 response is received, without placing an undue burden on 3891 the network. 3893 10.5.2 TCP 3895 A user agent using TCP MUST NOT retransmit requests, but uses the 3896 same algorithm as for UDP (Section 10.5.1) to retransmit responses 3897 until it receives an ACK. 3899 It is necessary to retransmit 2xx responses as their 3900 reliability is assured end-to-end only. If the chain of 3901 proxies has a UDP link in the middle, it could lose the 3902 response, with no possibility of recovery. For simplicity, 3903 we also retransmit non-2xx responses, although that is not 3904 strictly necessary. 3906 10.6 Reliability for ACK Requests 3908 The ACK request does not generate responses. It is only generated 3909 when a response to an INVITE request arrives (see Section 10.5). This 3910 behavior is independent of the transport protocol. Note that the ACK 3911 request MAY take a different path than the original INVITE request, 3912 and MAY even cause a new TCP connection to be opened in order to send 3913 it. 3915 +===========+ 3916 * * 3917 ...........>* Initial *<;;;;;;;;;; 3918 : 7 INVITE * * ; 3919 : sent +===========+ ; 3920 : | ; 3921 : | - ; 3922 : | INVITE ; 3923 : | ; 3924 : v ; 3925 : ************* ; 3926 : T1*2^n <--* * ; 3927 : INVITE -->* Calling *--------+ ; 3928 : * * | ; 3929 : ************* | ; 3930 : : | | ; 3931 :.............: | 1xx xxx | ; 3932 | - ACK | ; 3933 | | ; 3934 v | ; 3935 ************* | ; 3936 * * | ; 3937 * Ringing *<->1xx | ; 3938 * * | ; 3939 ************* | ; 3940 | | ; 3941 |<-------------+ ; 3942 | ; 3943 v ; 3944 ************* ; 3945 xxx <--* * ; 3946 ACK -->* Completed * ; 3947 * * ; 3948 ************* ; 3949 ; 32s (for proxy); 3950 ;;;;;;;;;;;;;;;;;; 3952 event (xxx=status) 3953 message 3955 Figure 12: State transition diagram of client for INVITE method 3956 7 pkts sent +===============+ 3957 +-------------->* * 3958 | * Initial *<............... 3959 |;;;;;;;;;;;;;;>* * 3960 |; +===============+ : 3961 |; CANCEL ! : 3962 |; 200 ! : 3963 |; ! INVITE : 3964 |; ! 1xx : 3965 |; ! : 3966 |; v : 3967 |; ***************** BYE : 3968 |; INVITE -->* * 200 : 3969 |; 1xx <--* Call proceed. *..............>: 3970 |; * * : 3971 |;;;;;;;;;;;;;;;***************** : 3972 |; ! ! : 3973 |: ! ! : 3974 |; failure ! ! picks up : 3975 |; >= 300 ! ! 200 : 3976 |; +-------+ +-------+ : 3977 |; v v : 3978 |; *********** *********** : 3979 |;INVITE<* ** *>INVITE : 3980 |;status>* failure *>status<-* success *: 3987 ! ! BYE : 3988 +---------+---------+ 200 : 3989 ! ACK : 3990 ! : 3991 v : 3992 ***************** : 3993 V---* * : 3994 ACK * Confirmed * : 3995 |-->* * : 3996 ***************** . 3997 : : 3998 :......................>: 3999 event 4000 message sent 4002 Figure 13: State transition diagram of server for INVITE method 4004 10.7 ICMP Handling 4006 Handling of ICMP messages in the case of UDP messages is 4007 straightforward. For requests, a host, network, port, or protocol 4008 unreachable error SHOULD be treated as if a 400-class response was 4009 received. For responses, these errors SHOULD cause the server to 4010 cease retransmitting the response. 4012 Source quench ICMP messages SHOULD be ignored. TTL exceeded errors 4013 SHOULD be ignored. Parameter problem errors SHOULD be treated as if a 4014 400-class response was received. 4016 11 Behavior of SIP User Agents 4018 This section describes the rules for user agent client and servers 4019 for generating and processing requests and responses. 4021 11.1 Caller Issues Initial INVITE Request 4023 When a user agent client desires to initiate a call, it formulates an 4024 INVITE request. The To field in the request contains the address of 4025 the callee. The Request-URI contains the same address. The From field 4026 contains the address of the caller. If the From address can appear 4027 in requests generated by other user agent clients for the same call, 4028 the caller MUST insert the tag parameter in the From field. A UAC MAY 4029 optionally add a Contact header containing an address where it would 4030 like to be contacted for transactions from the callee back to the 4031 caller. 4033 11.2 Callee Issues Response 4035 When the initial INVITE request is received at the callee, the callee 4036 can accept, redirect, or reject the call. In all of these cases, it 4037 formulates a response. The response MUST copy the To, From, Call-ID, 4038 CSeq and Via fields from the request. Additionally, the responding 4039 UAS MUST add the tag parameter to the To field in the response if the 4040 request contained more than one Via header field. Since a request 4041 from a UAC may fork and arrive at multiple hosts, the tag parameter 4042 serves to distinguish, at the UAC, multiple responses from different 4043 UAS's. The UAS MAY add a Contact header field in the response. It 4044 contains an address where the callee would like to be contacted for 4045 subsequent transactions, including the ACK for the current INVITE. 4046 The UAS stores the values of the To and From field, including any 4047 tags. These become the local and remote addresses of the call leg, 4048 respectively. 4050 11.3 Caller Receives Response to Initial Request 4051 Multiple responses may arrive at the UAC for a single INVITE request, 4052 due to a forking proxy. Each response is distinguished by the "tag" 4053 parameter in the To header field, and each represents a distinct call 4054 leg. The caller MAY choose to acknowledge or terminate the call with 4055 each responding UAS. To acknowledge, it sends an ACK request, and to 4056 terminate it sends a BYE request. The To header field in the ACK or 4057 BYE MUST be the same as the To field in the 200 response, including 4058 any tag. The From header field MUST be the same as the From header 4059 field in the 200 (OK) response, including any tag. The Request-URI of 4060 the ACK or BYE request MAY be set to whatever address was found in 4061 the Contact header field in the 200 (OK) response, if present. 4062 Alternately, a UAC may copy the address from the To header field into 4063 the Request-URI. The UAC also notes the value of the To and From 4064 header fields in each response. For each call leg, the To header 4065 field becomes the remote address, and the From header field becomes 4066 the local address. 4068 11.4 Caller or Callee Generate Subsequent Requests 4070 Once the call has been established, either the caller or callee MAY 4071 generate INVITE or BYE requests to change or terminate the call. 4072 Regardless of whether the caller or callee is generating the new 4073 request, the header fields in the request are set as follows. For the 4074 desired call leg, the To header field is set to the remote address, 4075 and the From header field is set to the local address (both including 4076 any tags). The Contact header field MAY be different than the Contact 4077 header field sent in a previous response or request. The Request-URI 4078 MAY be set to the value of the Contact header field received in a 4079 previous request or response from the remote party, or to the value 4080 of the remote address. 4082 11.5 Receiving Subsequent Requests 4084 When a request is received subsequently, the following checks are 4085 made: 4087 1. If the Call-ID is new, the request is for a new call, 4088 regardless of the values of the To and From header fields. 4090 2. If the Call-ID exists, the request is for an existing call. 4091 If the To, From, Call-ID, and CSeq values exactly match 4092 (including tags) those of any requests received previously, 4093 the request is a retransmission. 4095 3. If there was no match to the previous step, the To and From 4096 fields are compared against existing call leg local and 4097 remote addresses. If there is a match, and the CSeq in the 4098 request is higher than the last CSeq received on that leg, 4099 the request is a new transaction for an existing call leg. 4101 12 Behavior of SIP Proxy and Redirect Servers 4103 This section describes behavior of SIP redirect and proxy servers in 4104 detail. Proxy servers can "fork" connections, i.e., a single incoming 4105 request spawns several outgoing (client) requests. 4107 12.1 Redirect Server 4109 A redirect server does not issue any SIP requests of its own. After 4110 receiving a request other than CANCEL, the server gathers the list of 4111 alternative locations and returns a final response of class 3xx or it 4112 refuses the request. For well-formed CANCEL requests, it SHOULD 4113 return a 2xx response. This response ends the SIP transaction. The 4114 redirect server maintains transaction state for the whole SIP 4115 transaction. It is up to the client to detect forwarding loops 4116 between redirect servers. 4118 12.2 User Agent Server 4120 User agent servers behave similarly to redirect servers, except that 4121 they also accept requests and can return a response of class 2xx. 4123 12.3 Proxy Server 4125 This section outlines processing rules for proxy servers. A proxy 4126 server can either be stateful or stateless. When stateful, a proxy 4127 remembers the incoming request which generated outgoing requests, and 4128 the outgoing requests. A stateless proxy forgets all information once 4129 an outgoing request is generated. A forking proxy SHOULD be stateful. 4130 Proxies that accept TCP connections MUST be stateful. 4132 Otherwise, if the proxy were to lose a request, the TCP 4133 client would never retransmit it. 4135 A stateful proxy SHOULD NOT become stateless until after it sends a 4136 definitive response upstream, and at least 32 seconds after it 4137 received a definitive response. 4139 A stateful proxy acts as a virtual UAS/UAC. It implements the server 4140 state machine when receiving requests, and the client state machine 4141 for generating outgoing requests, with the exception of receiving a 4142 2xx response to an INVITE. Instead of generating an ACK, the 2xx 4143 response is always forwarded upstream towards the caller. 4144 Furthermore, ACK's for 200 responses to INVITE's are always proxied 4145 downstream towards the UAS, as they would be for a stateless proxy. 4147 A stateless proxy does not act as a virtual UAS/UAC (as this would 4148 require state). Rather, a stateless proxy forwards every request it 4149 receives downstream, and every response it receives upstream. 4151 12.3.1 Proxying Requests 4153 To prevent loops, a server MUST check if its own address is already 4154 contained in the Via header field of the incoming request. 4156 The To, From, Call-ID, and Contact tags are copied exactly from the 4157 original request. The proxy SHOULD change the Request-URI to indicate 4158 the server where it intends to send the request. 4160 A proxy server always inserts a Via header field containing its own 4161 address into those requests that are caused by an incoming request. 4162 Each proxy MUST insert a "branch" parameter (Section 6.40). 4164 12.3.2 Proxying Responses 4166 A proxy only processes a response if the topmost Via field matches 4167 one of its addresses. A response with a non-matching top Via field 4168 MUST be dropped. 4170 12.3.3 Stateless Proxy: Proxying Responses 4172 A stateless proxy removes its own Via field, and checks the address 4173 in the next Via field. In the case of UDP, the response is sent to 4174 the address listed in the "maddr" tag if present, otherwise to the 4175 "received" tag if present, and finally to the address in the "sent- 4176 by" field. A proxy MUST remain stateful when handling requests 4177 received via TCP. 4179 A stateless proxy MUST NOT generate its own provisional responses. 4181 12.3.4 Stateful Proxy: Receiving Requests 4183 When a stateful proxy receives a request, it checks the To, From 4184 (including tags), Call-ID and CSeq against existing request records. 4185 If the tuple exists, the request is a retransmission. The provisional 4186 or final response sent previously is retransmitted, as per the server 4187 state machine. If the tuple does not exist, the request corresponds 4188 to a new transaction, and the request should be proxied. 4190 A stateful proxy server MAY generate its own provisional (1xx) 4191 responses. 4193 12.3.5 Stateful Proxy: Receiving ACKs 4194 When an ACK request is received, it is either processed locally or 4195 proxied. To make this determination, the To, From, CSeq and Call-ID 4196 fields are compared against those in previous requests. If there is 4197 no match, the ACK request is proxied as if it were an INVITE request. 4198 If there is a match, and if the server had ever sent a 200 response 4199 upstream, the ACK is proxied. If the server had never sent any 4200 responses upstream, the ACK is also proxied. If the server had sent a 4201 3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is 4202 processed locally if the tag in the To field of the ACK matches the 4203 tag sent by the proxy in the response. 4205 12.3.6 Stateful Proxy: Receiving Responses 4207 When a proxy server receives a response that has passed the Via 4208 checks, the proxy server checks the To (without the tag), From 4209 (including the tag), Call-ID and CSeq against values seen in previous 4210 requests. If there is no match, the response is forwarded upstream to 4211 the address listed in the Via field. If there is a match, the 4212 "branch" tag in the Via field is examined. If it matches a known 4213 branch identifier, the response is for the given branch, and 4214 processed by the virtual client for the given branch. Otherwise, the 4215 response is dropped. 4217 A stateful proxy should obey the rules in Section 12.4 to determine 4218 if the response should be proxied upstream. If it is to be proxied, 4219 the same rules for stateless proxies above are followed, with the 4220 following addition for TCP. If a request was received via TCP 4221 (indicated by the protocol in the top Via header), the proxy checks 4222 to see if it has a connection currently open to that address. If so, 4223 the response is sent on that connection. Otherwise, a new TCP 4224 connection is opened to the address and port in the Via field, and 4225 the response is sent there. Note that this implies that a UAC or 4226 proxy MUST be prepared to receive responses on the incoming side of a 4227 TCP connection. Definitive non 200-class responses MUST be 4228 retransmitted by the proxy, even over a TCP connection. 4230 12.3.7 Stateless, Non-Forking Proxy 4232 Proxies in this category issue at most a single unicast request for 4233 each incoming SIP request, that is, they do not "fork" requests. 4234 However, servers MAY choose to always operate in a mode that allows 4235 issuing of several requests, as described in Section 12.4. 4237 The server can forward the request and any responses. It does not 4238 have to maintain any state for the SIP transaction. Reliability is 4239 assured by the next redirect or stateful proxy server in the server 4240 chain. 4242 A proxy server SHOULD cache the result of any address translations 4243 and the response to speed forwarding of retransmissions. After the 4244 cache entry has been expired, the server cannot tell whether an 4245 incoming request is actually a retransmission of an older request. 4246 The server will treat it as a new request and commence another 4247 search. 4249 12.4 Forking Proxy 4251 The server MUST respond to the request immediately with a 100 4252 (Trying) response. 4254 Successful responses to an INVITE request MAY contain a Contact 4255 header field so that the following ACK or BYE bypasses the proxy 4256 search mechanism. If the proxy requires future requests to be routed 4257 through it, it adds a Record-Route header to the request (Section 4258 6.29). 4260 The following C-code describes the behavior of a proxy server issuing 4261 several requests in response to an incoming INVITE request. The 4262 function request(r, a, b) sends a SIP request of type r to address a, 4263 with branch id b. await_response() waits until a response is received 4264 and returns the response. close(a) closes the TCP connection to 4265 client with address a. response(r) sends a response to the client. 4266 ismulticast() returns 1 if the location is a multicast address and 4267 zero otherwise. The variable timeleft indicates the amount of time 4268 left until the maximum response time has expired. The variable 4269 recurse indicates whether the server will recursively try addresses 4270 returned through a 3xx response. A server MAY decide to recursively 4271 try only certain addresses, e.g., those which are within the same 4272 domain as the proxy server. Thus, an initial multicast request can 4273 trigger additional unicast requests. 4275 /* request type */ 4276 typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method; 4278 process_request(Method R, int N, address_t address[]) 4279 { 4280 struct { 4281 int branch; /* branch id */ 4282 int done; /* has responded */ 4283 } outgoing[]; 4284 int done[]; /* address has responded */ 4285 char *location[]; /* list of locations */ 4286 int heard = 0; /* number of sites heard from */ 4287 int class; /* class of status code */ 4288 int timeleft = 120; /* sample timeout value */ 4289 int loc = 0; /* number of locations */ 4290 struct { /* response */ 4291 int status; /* response: CANCEL=-1 */ 4292 int locations; /* number of redirect locations */ 4293 char *location[]; /* redirect locations */ 4294 address_t a; /* address of respondent */ 4295 int branch; /* branch identifier */ 4296 } r, best; /* response, best response */ 4297 int i; 4299 best.status = 1000; 4300 for (i = 0; i < N; i++) { 4301 request(R, address[i], i); 4302 outgoing[i].done = 0; 4303 outgoing[i].branch = i; 4304 } 4306 while (timeleft > 0 && heard < N) { 4307 r = await_response(); 4308 class = r.status / 100; 4310 /* If final response, mark branch as done. */ 4311 if (class >= 2) { 4312 heard++; 4313 for (i = 0; i < N; i++) { 4314 if (r.branch == outgoing[i].branch) { 4315 outgoing[i].done = 1; 4316 break; 4317 } 4318 } 4319 } 4320 /* CANCEL: respond, fork and wait for responses */ 4321 else if (class < 0) { 4322 best.status = 200; 4323 response(best); 4324 for (i = 0; i < N; i++) { 4325 if (!outgoing[i].done) 4326 request(CANCEL, address[i], outgoing[i].branch); 4327 } 4328 best.status = -1; 4329 } 4331 /* Send an ACK */ 4333 if (class != 2) { 4334 if (R == INVITE) request(ACK, r.a, r.branch); 4335 } 4336 if (class == 2) { 4337 if (r.status < best.status) best = r; 4338 break; 4339 } 4340 else if (class == 3) { 4341 /* A server MAY optionally recurse. The server MUST check 4342 * whether it has tried this location before and whether the 4343 * location is part of the Via path of the incoming request. 4344 * This check is omitted here for brevity. Multicast locations 4345 * MUST NOT be returned to the client if the server is not 4346 * recursing. 4347 */ 4348 if (recurse) { 4349 multicast = 0; 4350 N += r.locations; 4351 for (i = 0; i < r.locations; i++) { 4352 request(R, r.location[i]); 4353 } 4354 } else if (!ismulticast(r.location)) { 4355 best = r; 4356 } 4357 } 4358 else if (class == 4) { 4359 if (best.status >= 400) best = r; 4360 } 4361 else if (class == 5) { 4362 if (best.status >= 500) best = r; 4363 } 4364 else if (class == 6) { 4365 best = r; 4366 break; 4367 } 4368 } 4370 /* We haven't heard anything useful from anybody. */ 4371 if (best.status == 1000) { 4372 best.status = 404; 4373 } 4374 if (best.status/100 != 3) loc = 0; 4375 response(best); 4376 } 4378 Responses are processed as follows. The process completes (and state 4379 can be freed) when all requests have been answered by final status 4380 responses (for unicast) or 60 seconds have elapsed (for multicast). A 4381 proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to 4382 the client after 60 seconds or more. 4384 1xx: The proxy MAY forward the response upstream towards the client. 4386 2xx: The proxy MUST forward the response upstream towards the client, 4387 without sending an ACK downstream. After receiving a 2xx, the 4388 server MAY terminate all other pending requests by sending a 4389 CANCEL request and closing the TCP connection, if applicable. 4390 (Terminating pending requests is advisable as searches consume 4391 resources. Also, INVITE requests could "ring" on a number of 4392 workstations if the callee is currently logged in more than 4393 once.) 4395 3xx: The proxy MUST send an ACK and MAY recurse on the listed Contact 4396 addresses. Otherwise, the lowest-numbered response is returned 4397 if there were no 2xx responses. 4399 Location lists are not merged as that would prevent 4400 forwarding of authenticated responses. Also, responses can 4401 have message bodies, so that merging is not feasible. 4403 4xx, 5xx: The proxy MUST send an ACK and remember the response if it 4404 has a lower status code than any previous 4xx and 5xx responses. 4405 On completion, the lowest-numbered response is returned if there 4406 were no 2xx or 3xx responses. 4408 6xx: The proxy MUST forward the response to the client and send an 4409 ACK. Other pending requests MAY be terminated with CANCEL as 4410 described for 2xx responses. 4412 A proxy server forwards any response for Call-IDs for which it does 4413 not have a pending transaction according to the response's Via 4414 header. User agent servers respond to BYE requests for unknown call 4415 legs with status code 481 (Transaction Does Not Exist); they drop ACK 4416 requests with unknown call legs silently. 4418 Special considerations apply for choosing forwarding destinations for 4419 ACK and BYE requests. In most cases, these requests will bypass 4420 proxies and reach the desired party directly, keeping proxies from 4421 having to make forwarding decisions. 4423 A proxy MAY maintain call state for a period of its choosing. If a 4424 proxy still has list of destinations that it forwarded the last 4425 INVITE to, it SHOULD direct ACK requests only to those downstream 4426 servers. 4428 13 Security Considerations 4429 13.1 Confidentiality and Privacy: Encryption 4431 13.1.1 End-to-End Encryption 4433 SIP requests and responses can contain sensitive information about 4434 the communication patterns and communication content of individuals. 4435 The SIP message body MAY also contain encryption keys for the session 4436 itself. SIP supports three complementary forms of encryption to 4437 protect privacy: 4439 o End-to-end encryption of the SIP message body and certain 4440 sensitive header fields; 4442 o hop-by-hop encryption to prevent eavesdropping that tracks who 4443 is calling whom; 4445 o hop-by-hop encryption of Via fields to hide the route a 4446 request has taken. 4448 Not all of the SIP request or response can be encrypted end-to-end 4449 because header fields such as To and Via need to be visible to 4450 proxies so that the SIP request can be routed correctly. Hop-by-hop 4451 encryption encrypts the entire SIP request or response on the wire so 4452 that packet sniffers or other eavesdroppers cannot see who is calling 4453 whom. Hop-by-hop encryption can also encrypt requests and responses 4454 that have been end-to-end encrypted. Note that proxies can still see 4455 who is calling whom, and this information is also deducible by 4456 performing a network traffic analysis, so this provides a very 4457 limited but still worthwhile degree of protection. 4459 SIP Via fields are used to route a response back along the path taken 4460 by the request and to prevent infinite request loops. However, the 4461 information given by them can also provide useful information to an 4462 attacker. Section 6.22 describes how a sender can request that Via 4463 fields be encrypted by cooperating proxies without compromising the 4464 purpose of the Via field. 4466 End-to-end encryption relies on keys shared by the two user agents 4467 involved in the request. Typically, the message is sent encrypted 4468 with the public key of the recipient, so that only that recipient can 4469 read the message. All implementations SHOULD support PGP-based 4470 encryption [33] and MAY implement other schemes. 4472 A SIP request (or response) is end-to-end encrypted by splitting the 4473 message to be sent into a part to be encrypted and a short header 4474 that will remain in the clear. Some parts of the SIP message, namely 4475 the request line, the response line and certain header fields marked 4476 with "n" in the "enc." column in Table 4 and 5 need to be read and 4477 returned by proxies and thus MUST NOT be encrypted end-to-end. 4478 Possibly sensitive information that needs to be made available as 4479 plaintext include destination address (To) and the forwarding path 4480 (Via) of the call. The Authorization header field MUST remain in the 4481 clear if it contains a digital signature as the signature is 4482 generated after encryption, but MAY be encrypted if it contains 4483 "basic" or "digest" authentication. The From header field SHOULD 4484 normally remain in the clear, but MAY be encrypted if required, in 4485 which case some proxies MAY return a 401 (Unauthorized) status if 4486 they require a From field. 4488 Other header fields MAY be encrypted or MAY travel in the clear as 4489 desired by the sender. The Subject, Allow and Content-Type header 4490 fields will typically be encrypted. The Accept, Accept-Language, 4491 Date, Expires, Priority, Require, Call-ID, Cseq, and Timestamp header 4492 fields will remain in the clear. 4494 All fields that will remain in the clear MUST precede those that will 4495 be encrypted. The message is encrypted starting with the first 4496 character of the first header field that will be encrypted and 4497 continuing through to the end of the message body. If no header 4498 fields are to be encrypted, encrypting starts with the second CRLF 4499 pair after the last header field, as shown below. Carriage return and 4500 line feed characters have been made visible as "$", and the encrypted 4501 part of the message is outlined. 4503 INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ 4504 Via: SIP/2.0/UDP 169.130.12.5$ 4505 To: T. A. Watson $ 4506 From: A. Bell $ 4507 Encryption: PGP version=5.0$ 4508 Content-Length: 224$ 4509 Call-ID: 187602141351@worcester.bell-telephone.com$ 4510 CSeq: 488$ 4511 $ 4512 ******************************************************* 4513 * Subject: Mr. Watson, come here.$ * 4514 * Content-Type: application/sdp$ * 4515 * $ * 4516 * v=0$ * 4517 * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * 4518 * c=IN IP4 135.180.144.94$ * 4519 * m=audio 3456 RTP/AVP 0 3 4 5$ * 4520 ******************************************************* 4521 An Encryption header field MUST be added to indicate the encryption 4522 mechanism used. A Content-Length field is added that indicates the 4523 length of the encrypted body. The encrypted body is preceded by a 4524 blank line as a normal SIP message body would be. 4526 Upon receipt by the called user agent possessing the correct 4527 decryption key, the message body as indicated by the Content-Length 4528 field is decrypted, and the now-decrypted body is appended to the 4529 clear-text header fields. There is no need for an additional 4530 Content-Length header field within the encrypted body because the 4531 length of the actual message body is unambiguous after decryption. 4533 Had no SIP header fields required encryption, the message would have 4534 been as below. Note that the encrypted body MUST then include a blank 4535 line (start with CRLF) to disambiguate between any possible SIP 4536 header fields that might have been present and the SIP message body. 4538 INVITE sip:watson@boston.bell-telephone.com SIP/2.0$ 4539 Via: SIP/2.0/UDP 169.130.12.5$ 4540 To: T. A. Watson $ 4541 From: A. Bell $ 4542 Encryption: PGP version=5.0$ 4543 Content-Type: application/sdp$ 4544 Content-Length: 107$ 4545 $ 4546 ************************************************* 4547 * $ * 4548 * v=0$ * 4549 * o=bell 53655765 2353687637 IN IP4 128.3.4.5$ * 4550 * c=IN IP4 135.180.144.94$ * 4551 * m=audio 3456 RTP/AVP 0 3 4 5$ * 4552 ************************************************* 4554 13.1.2 Privacy of SIP Responses 4556 SIP requests can be sent securely using end-to-end encryption and 4557 authentication to a called user agent that sends an insecure 4558 response. This is allowed by the SIP security model, but is not a 4559 good idea. However, unless the correct behaviour is explicit, it 4560 would not always be possible for the called user agent to infer what 4561 a reasonable behaviour was. Thus when end-to-end encryption is used 4562 by the request originator, the encryption key to be used for the 4563 response SHOULD be specified in the request. If this were not done, 4564 it might be possible for the called user agent to incorrectly infer 4565 an appropriate key to use in the response. Thus, to prevent key- 4566 guessing becoming an acceptable strategy, we specify that a called 4567 user agent receiving a request that does not specify a key to be used 4568 for the response SHOULD send that response unencrypted. 4570 Any SIP header fields that were encrypted in a request SHOULD also be 4571 encrypted in an encrypted response. Contact response fields MAY be 4572 encrypted if the information they contain is sensitive, or MAY be 4573 left in the clear to permit proxies more scope for localized 4574 searches. 4576 13.1.3 Encryption by Proxies 4578 Normally, proxies are not allowed to alter end-to-end header fields 4579 and message bodies. Proxies MAY, however, encrypt an unsigned request 4580 or response with the key of the call recipient. 4582 Proxies need to encrypt a SIP request if the end system 4583 cannot perform encryption or to enforce organizational 4584 security policies. 4586 13.1.4 Hop-by-Hop Encryption 4588 SIP requests and responses MAY also be protected by security 4589 mechanisms at the transport or network layer. No particular mechanism 4590 is defined or recommended here. Two possibilities are IPSEC [34] or 4591 TLS [35]. The use of a particular mechanism will generally need to be 4592 specified out of band, through manual configuration, for example. 4594 13.1.5 Via field encryption 4596 When Via header fields are to be hidden, a proxy that receives a 4597 request containing an appropriate "Hide: hop" header field (as 4598 specified in section 6.22) SHOULD encrypt the header field. As only 4599 the proxy that encrypts the field will decrypt it, the algorithm 4600 chosen is entirely up to the proxy implementor. Two methods satisfy 4601 these requirements: 4603 o The server keeps a cache of Via header fields and the 4604 associated To header field, and replaces the Via header field 4605 with an index into the cache. On the reverse path, take the 4606 Via header field from the cache rather than the message. 4608 This is insufficient to prevent message looping, and so an 4609 additional ID MUST be added so that the proxy can detect loops. 4610 This SHOULD NOT normally be the address of the proxy as the goal 4611 is to hide the route, so instead a sufficiently large random 4612 number SHOULD be used by the proxy and maintained in the cache. 4614 It is possible for replies to get directed to the wrong 4615 originator if the cache entry gets reused, so great care needs 4616 to be taken to ensure this does not happen. 4618 o The server MAY use a secret key to encrypt the Via field, a 4619 timestamp and an appropriate checksum in any such message with 4620 the same secret key. The checksum is needed to detect whether 4621 successful decoding has occurred, and the timestamp is 4622 required to prevent possible replay attacks and to ensure that 4623 no two requests from the same previous hop have the same 4624 encrypted Via field. This is the preferred solution. 4626 13.2 Message Integrity and Access Control: Authentication 4628 Protective measures need to be taken to prevent an active attacker 4629 from modifying and replaying SIP requests and responses. The same 4630 cryptographic measures that are used to ensure the authenticity of 4631 the SIP message also serve to authenticate the originator of the 4632 message. However, the "basic" and "digest" authentication mechanism 4633 offer authentication only, without message integrity. 4635 Transport-layer or network-layer authentication MAY be used for hop- 4636 by-hop authentication. SIP also extends the HTTP WWW-Authenticate 4637 (Section 6.42) and Authorization (Section 6.11) header field and 4638 their Proxy counterparts to include cryptographically strong 4639 signatures. SIP also supports the HTTP "basic" and "digest" schemes 4640 (see Section 14) and other HTTP authentication schemes to be defined 4641 that offer a rudimentary mechanism of ascertaining the identity of 4642 the caller. 4644 Since SIP requests are often sent to parties with which no 4645 prior communication relationship has existed, we do not 4646 specify authentication based on shared secrets. 4648 SIP requests MAY be authenticated using the Authorization header 4649 field to include a digital signature of certain header fields, the 4650 request method and version number and the payload, none of which are 4651 modified between client and called user agent. The Authorization 4652 header field is used in requests to authenticate the request 4653 originator end-to-end to proxies and the called user agent, and in 4654 responses to authenticate the called user agent or proxies returning 4655 their own failure codes. If required, hop-by-hop authentication can 4656 be provided, for example, by the IPSEC Authentication Header. 4658 SIP does not dictate which digital signature scheme is used for 4659 authentication, but does define how to provide authentication using 4660 PGP in Section 15. As indicated above, SIP implementations MAY also 4661 use "basic" and "digest" authentication and other authentication 4662 mechanisms defined for HTTP. Note that "basic" authentication has 4663 severe security limitations. The following does not apply to these 4664 schemes. 4666 To cryptographically sign a SIP request, the order of the SIP header 4667 fields is important. When an Authorization header field is present, 4668 it indicates that all header fields following the Authorization 4669 header field have been included in the signature. Therefore, hop- 4670 by-hop header fields which MUST or SHOULD be modified by proxies MUST 4671 precede the Authorization header field as they will generally be 4672 modified or added-to by proxy servers. Hop-by-hop header fields 4673 which MAY be modified by a proxy MAY appear before or after the 4674 Authorization header. When they appear before, they MAY be modified 4675 by a proxy. When they appear after, they MUST NOT be modified by a 4676 proxy. To sign a request, a client constructs a message from the 4677 request method (in upper case) followed, without LWS, by the SIP 4678 version number, followed, again without LWS, by the request headers 4679 to be signed and the message body. The message thus constructed is 4680 then signed. 4682 For example, if the SIP request is to be: 4684 INVITE sip:watson@boston.bell-telephone.com SIP/2.0 4685 Via: SIP/2.0/UDP 169.130.12.5 4686 Authorization: PGP version=5.0, signature=... 4687 From: A. Bell 4688 To: T. A. Watson 4689 Call-ID: 187602141351@worcester.bell-telephone.com 4690 Subject: Mr. Watson, come here. 4691 Content-Type: application/sdp 4692 Content-Length: ... 4694 v=0 4695 o=bell 53655765 2353687637 IN IP4 128.3.4.5 4696 c=IN IP4 135.180.144.94 4697 m=audio 3456 RTP/AVP 0 3 4 5 4699 Then the data block that is signed is: 4701 INVITESIP/2.0From: A. Bell 4702 To: T. A. Watson 4703 Call-ID: 187602141351@worcester.bell-telephone.com 4704 Subject: Mr. Watson, come here. 4705 Content-Type: application/sdp 4706 Content-Length: ... 4708 v=0 4709 o=bell 53655765 2353687637 IN IP4 128.3.4.5 4710 c=IN IP4 135.180.144.94 4711 m=audio 3456 RTP/AVP 0 3 4 5 4713 Clients wishing to authenticate requests MUST construct the portion 4714 of the message below the Authorization header using a canonical form. 4715 This allows a proxy to parse the message, take it apart, and 4716 reconstruct it, without causing an authentication failure due to 4717 extra white space, for example. Canonical form consists of the 4718 following rules: 4720 o No short form header fields 4722 o Header field names are capitalized as shown in this document 4724 o No white space between the header name and the colon 4726 o A single space after the colon 4728 o Line termination with a CRLF 4730 o No line folding 4732 o No comma separated lists of header values; each must appear as 4733 a separate header 4735 o Only a single SP between tokens, between tokens and quoted 4736 strings, and between quoted strings; no SP after last token or 4737 quoted string 4739 o No LWS between tokens and separators, except as described 4740 above for after the colon in header fields 4742 Note that if a message is encrypted and authenticated using a digital 4743 signature, when the message is generated encryption is performed 4744 before the digital signature is generated. On receipt, the digital 4745 signature is checked before decryption. 4747 A client MAY require that a server sign its response by including a 4748 Require: org.ietf.sip.signed-response request header field. The 4749 client indicates the desired authentication method via the WWW- 4750 Authenticate header. 4752 The correct behaviour in handling unauthenticated responses to a 4753 request that requires authenticated responses is described in section 4754 13.2.1. 4756 13.2.1 Trusting responses 4758 There is the possibility that an eavesdropper listens to requests and 4759 then injects unauthenticated responses that terminate, redirect or 4760 otherwise interfere with a call. (Even encrypted requests contain 4761 enough information to fake a response.) 4763 Clients need to be particularly careful with 3xx redirection 4764 responses. Thus a client receiving, for example, a 301 (Moved 4765 Permanently) which was not authenticated when the public key of the 4766 called user agent is known to the client, and authentication was 4767 requested in the request SHOULD be treated as suspicious. The correct 4768 behaviour in such a case would be for the called-user to form a dated 4769 response containing the Contact field to be used, to sign it, and 4770 give this signed stub response to the proxy that will provide the 4771 redirection. Thus the response can be authenticated correctly. A 4772 client SHOULD NOT automatically redirect such a request to the new 4773 location without alerting the user to the authentication failure 4774 before doing so. 4776 Another problem might be responses such as 6xx failure responses 4777 which would simply terminate a search, or "4xx" and "5xx" response 4778 failures. 4780 If TCP is being used, a proxy SHOULD treat 4xx and 5xx responses as 4781 valid, as they will not terminate a search. However, fake 6xx 4782 responses from a rogue proxy terminate a search incorrectly. 6xx 4783 responses SHOULD be authenticated if requested by the client, and 4784 failure to do so SHOULD cause such a client to ignore the 6xx 4785 response and continue a search. 4787 With UDP, the same problem with 6xx responses exists, but also an 4788 active eavesdropper can generate 4xx and 5xx responses that might 4789 cause a proxy or client to believe a failure occurred when in fact it 4790 did not. Typically 4xx and 5xx responses will not be signed by the 4791 called user agent, and so there is no simple way to detect these 4792 rogue responses. This problem is best prevented by using hop-by-hop 4793 encryption of the SIP request, which removes any additional problems 4794 that UDP might have over TCP. 4796 These attacks are prevented by having the client require response 4797 authentication and dropping unauthenticated responses. A server user 4798 agent that cannot perform response authentication responds using the 4799 normal Require response of 420 (Bad Extension). 4801 13.3 Callee Privacy 4803 User location and SIP-initiated calls can violate a callee's privacy. 4804 An implementation SHOULD be able to restrict, on a per-user basis, 4805 what kind of location and availability information is given out to 4806 certain classes of callers. 4808 13.4 Known Security Problems 4810 With either TCP or UDP, a denial of service attack exists by a rogue 4811 proxy sending 6xx responses. Although a client SHOULD choose to 4812 ignore such responses if it requested authentication, a proxy cannot 4813 do so. It is obliged to forward the 6xx response back to the client. 4814 The client can then ignore the response, but if it repeats the 4815 request it will probably reach the same rogue proxy again, and the 4816 process will repeat. 4818 14 SIP Authentication using HTTP Basic and Digest Schemes 4820 SIP implementations MAY use HTTP's basic and digest authentication 4821 mechanisms to provide a rudimentary form of security. This section 4822 overviews usage of these mechanisms in SIP. The basic operation is 4823 almost completely identical to that for HTTP [36]. This section 4824 outlines this operation, pointing to [36] for details, and noting the 4825 differences when used in SIP. 4827 14.1 Framework 4829 The framework for SIP authentication parallels that for HTTP [36]. In 4830 particular, the BNF for auth-scheme, auth-param, challenge, realm, 4831 realm-value, and credentials is identical. The 401 response is used 4832 by user agent servers in SIP to challenge the authorization of a user 4833 agent client. Additionally, registrars and redirect servers MAY make 4834 use of 401 responses for authorization, but proxies MUST NOT, and 4835 instead MAY use the 407 response. The requirements for inclusion of 4836 the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and 4837 Authorization in the various messages is identical to [36]. 4839 Since SIP does not have the concept of a canonical root URL, the 4840 notion of protections spaces are interpreted differently for SIP. The 4841 realm is a protection domain for all SIP URIs with the same value for 4842 the userinfo, host and port part of the SIP Request-URI. For example: 4844 INVITE sip:alice.wonderland@example.com SIP/2.0 4845 WWW-Authenticate: Basic realm="business" 4847 and 4849 INVITE sip:aw@example.com SIP/2.0 4850 WWW-Authenticate: Basic realm="business" 4852 define different protection realms according to this rule. 4854 When a UAC resubmits a request with its credentials after receiving a 4855 401 or 407 response, it MUST increment the CSeq header field as it 4856 would normally do when sending an updated request. 4858 14.2 Basic Authentication 4860 The rules for basic authentication follow those defined in [36], but 4861 with the words "origin server" replaced with "user agent server, 4862 redirect server , or registrar". 4864 Since SIP URIs are not hierarchical, the paragraph in [36] that 4865 states that "all paths at or deeper than the depth of the last 4866 symbolic element in the path field of the Request-URI also are within 4867 the protection space specified by the Basic realm value of the 4868 current challenge" does not apply for SIP. SIP clients MAY 4869 preemptively send the corresponding Authorization header with 4870 requests for SIP URIs within the same protection realm (as defined 4871 above) without receipt of another challenge from the server. 4873 14.3 Digest Authentication 4875 The rules for digest authentication follow those defined in [36], 4876 with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following 4877 differences: 4879 1. The URI included in the challenge has the following BNF: 4881 URI = SIP-URL 4883 2. The BNF for digest-uri-value is: 4885 digest-uri-value = Request-URI ;as defined in Section 4886 4.3 4888 3. The example procedure for choosing a nonce based on Etag 4889 does not work for SIP. 4891 4. The Authentication-Info and Proxy-Authentication-Info 4892 fields are not used in SIP. 4894 5. The text in [36] regarding cache operation does not apply 4895 to SIP. 4897 6. [36] requires that a server check that the URI in the 4898 request line, and the URI included in the Authorization 4899 header, point to the same resource. In a SIP context, these 4900 two URI's may actually refer to different users, due to 4901 forwarding at some proxy. Therefore, in SIP, a server MAY 4902 check that the request-uri in the Authorization header 4903 corresponds to a user that the server is willing to accept 4904 forwarded or direct calls for. 4906 14.4 Proxy-Authentication 4908 The use of the Proxy-Authentication and Proxy-Authorization parallel 4909 that as described in [36], with one difference. Proxies MUST NOT add 4910 the Proxy-Authorization header. 407 responses MUST be forwarded 4911 upstream towards the client following the procedures for any other 4912 response. It is the client's responsibility to add the Proxy- 4913 Authorization header containing credentials for the proxy which has 4914 asked for authentication. 4916 If a proxy were to resubmit a request with a Proxy- 4917 Authorization header field, it would need to increment the 4918 CSeq in the new request. However, this would mean that the 4919 UAC which submitted the original request would discard a 4920 response from the UAS, as the CSeq value would be 4921 different. 4923 See sections 6.26 and 6.27 for additional information on usage of 4924 these fields as they apply to SIP. 4926 15 SIP Security Using PGP 4928 15.1 PGP Authentication Scheme 4930 The "pgp" authentication scheme is based on the model that the client 4931 authenticates itself with a request signed with the client's private 4932 key. The server can then ascertain the origin of the request if it 4933 has access to the public key, preferably signed by a trusted third 4934 party. 4936 15.1.1 The WWW-Authenticate Response Header 4938 WWW-Authenticate = "WWW-Authenticate" ":" "pgp" pgp-challenge 4939 pgp-challenge = * (";" pgp-params ) 4940 pgp-params = realm | pgp-version | pgp-algorithm | nonce 4941 realm = "realm" "=" realm-value 4942 realm-value = quoted-string 4943 pgp-version = 4944 "version" "=" <"> digit *( "." digit ) *letter <"> 4945 pgp-algorithm = "algorithm" "=" ( "md5" | "sha1" | token ) 4946 nonce = "nonce" "=" nonce-value 4947 nonce-value = quoted-string 4949 The meanings of the values of the parameters used above are as 4950 follows: 4952 realm: A string to be displayed to users so they know which identity 4953 to use. This string SHOULD contain at least the name of the host 4954 performing the authentication and MAY additionally indicate the 4955 collection of users who might have access. An example might be " 4956 Users with call-out privileges ". 4958 pgp-algorithm: The value of this parameter indicates the PGP message 4959 integrity check (MIC) to be used to produce the signature. If 4960 this not present it is assumed to be "md5". The currently 4961 defined values are "md5" for the MD5 checksum, and "sha1" for 4962 the SHA.1 algorithm. 4964 pgp-version: The version of PGP that the client MUST use. Common 4965 values are "2.6.2" and "5.0". The default is 5.0. 4967 nonce: A server-specified data string which should be uniquely 4968 generated each time a 401 response is made. It is RECOMMENDED 4969 that this string be base64 or hexadecimal data. Specifically, 4970 since the string is passed in the header lines as a quoted 4971 string, the double-quote character is not allowed. The contents 4972 of the nonce are implementation dependent. The quality of the 4973 implementation depends on a good choice. Since the nonce is used 4974 only to prevent replay attacks and is signed, a time stamp in 4975 units convenient to the server is sufficient. 4977 Replay attacks within the duration of the call setup are of 4978 limited interest, so that timestamps with a resolution of a 4979 few seconds are often should be sufficient. In that case, 4980 the server does not have to keep a record of the nonces. 4982 Example: 4984 WWW-Authenticate: pgp ;version="5.0" 4985 ;realm="Your Startrek identity, please" ;algorithm=md5 4986 ;nonce="913082051" 4988 15.1.2 The Authorization Request Header 4990 The client is expected to retry the request, passing an Authorization 4991 header line, which is defined as follows. 4993 Authorization = "Authorization" ":" "pgp" *( ";" pgp-response ) 4994 pgp-response = realm | pgp-version | pgp-signature 4995 | signed-by | nonce 4996 pgp-signature = "signature" "=" quoted-string 4997 signed-by = "signed-by" "=" <"> URI <"> 4999 The client MUST increment the CSeq header before resubmitting the 5000 request. The signature MUST correspond to the From header of the 5001 request unless the signed-by parameter is provided. 5003 pgp-signature: The PGP ASCII-armored signature [33], as it appears 5004 between the "BEGIN PGP MESSAGE" and "END PGP MESSAGE" 5005 delimiters, without the version indication. The signature is 5006 included without any linebreaks. 5008 The signature is computed across the nonce (if present), request 5009 method, request version and header fields following the Authorization 5010 header and the message body, in the same order as they appear in the 5011 message. The request method and version are prepended to the header 5012 fields without any white space. The signature is computed across the 5013 headers as sent, and the terminating CRLF. The CRLF following the 5014 Authorization header is NOT included in the signature. 5016 A server MAY be configured not to generate nonces only if replay 5017 attacks are not a concern. 5019 Not generating nonces avoids the additional set of request, 5020 401 response and possibly ACK messages and reduces delay by 5021 one round-trip time. 5023 Using the ASCII-armored version is about 25% less space- 5024 efficient than including the binary signature, but it is 5025 significantly easier for the receiver to piece together. 5026 Versions of the PGP program always include the full 5027 (compressed) signed text in their output unless ASCII- 5028 armored mode ( -sta ) is specified. Typical signatures are 5029 about 200 bytes long. -- The PGP signature mechanism allows 5030 the client to simply pass the request to an external PGP 5031 program. This relies on the requirement that proxy servers 5032 are not allowed to reorder or change header fields. 5034 realm: The realm is copied from the corresponding WWW-Authenticate 5035 header field parameter. 5037 signed-by: If and only if the request was not signed by the entity 5038 listed in the From header, the signed-by header indicates the 5039 name of the signing entity, expressed as a URI. 5041 Receivers of signed SIP messages SHOULD discard any end-to-end header 5042 fields above the Authorization header, as they may have been 5043 maliciously added en route by a proxy. 5045 Example: 5047 Authorization: pgp version="5.0" 5048 ;realm="Your Startrek identity, please" 5049 ;nonce="913082051" 5050 ;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf 5051 VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt 5052 SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX 5053 =aIrx" 5055 15.2 PGP Encryption Scheme 5057 The PGP encryption scheme uses the following syntax: 5059 Encryption = "Encryption" ":" "pgp" pgp-eparams 5060 pgp-eparams = 1# ( pgp-version | pgp-encoding ) 5061 pgp-encoding = "encoding" "=" "ascii" | token 5063 encoding: Describes the encoding or "armor" used by PGP. The value 5064 "ascii" refers to the standard PGP ASCII armor, without the 5065 lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and 5066 without the version identifier. By default, the encrypted part 5067 is included as binary. 5069 Example: 5071 Encryption: pgp version="2.6.2", encoding="ascii" 5073 15.3 Response-Key Header Field for PGP 5075 Response-Key = "Response-Key" ":" "pgp" pgp-eparams 5076 pgp-eparams = 1# ( pgp-version | pgp-encoding | pgp-key) 5077 pgp-key = "key" "=" quoted-string 5079 If ASCII encoding has been requested via the encoding parameter, the 5080 key parameter contains the user's public key as extracted from the 5081 pgp key ring with the "pgp -kxa user ". 5083 Example: 5085 Response-Key: pgp version="2.6.2", encoding="ascii", 5086 key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk 5087 mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx 5088 sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu 5089 bmVAY3MuY29sdW1iaWEuZWR1Pg== 5090 =+y19" 5092 16 Examples 5094 In the following examples, we often omit the message body and the 5095 corresponding Content-Length and Content-Type headers for brevity. 5097 16.1 Registration 5099 A user at host saturn.bell-tel.com registers on start-up, via 5100 multicast, with the local SIP server named bell-tel.com. In the 5101 example, the user agent on saturn expects to receive SIP requests on 5102 UDP port 3890. 5104 C->S: REGISTER sip:bell-tel.com SIP/2.0 5105 Via: SIP/2.0/UDP saturn.bell-tel.com 5106 From: sip:watson@bell-tel.com 5107 To: sip:watson@bell-tel.com 5108 Call-ID: 70710@saturn.bell-tel.com 5109 CSeq: 1 REGISTER 5110 Contact: 5111 Expires: 7200 5113 The registration expires after two hours. Any future invitations for 5114 watson@bell-tel.com arriving at sip.bell-tel.com will now be 5115 redirected to watson@saturn.bell-tel.com, UDP port 3890. 5117 If Watson wants to be reached elsewhere, say, an on-line service he 5118 uses while traveling, he updates his reservation after first 5119 cancelling any existing locations: 5121 C->S: REGISTER sip:bell-tel.com SIP/2.0 5122 Via: SIP/2.0/UDP saturn.bell-tel.com 5123 From: sip:watson@bell-tel.com 5124 To: sip:watson@bell-tel.com 5125 Call-ID: 70710@saturn.bell-tel.com 5126 CSeq: 2 REGISTER 5127 Contact: * 5128 Expires: 0 5130 C->S: REGISTER sip:bell-tel.com SIP/2.0 5131 Via: SIP/2.0/UDP saturn.bell-tel.com 5132 From: sip:watson@bell-tel.com 5133 To: sip:watson@bell-tel.com 5134 Call-ID: 70710@saturn.bell-tel.com 5135 CSeq: 3 REGISTER 5136 Contact: sip:tawatson@example.com 5138 Now, the server will forward any request for Watson to the server at 5139 example.com, using the Request-URI tawatson@example.com. For the 5140 server at example.com to reach Watson, he will need to send a 5141 REGISTER there, or inform the server of his current location through 5142 some other means. 5144 It is possible to use third-party registration. Here, the secretary 5145 jon.diligent registers his boss, T. Watson: 5147 C->S: REGISTER sip:bell-tel.com SIP/2.0 5148 Via: SIP/2.0/UDP pluto.bell-tel.com 5149 From: sip:jon.diligent@bell-tel.com 5150 To: sip:watson@bell-tel.com 5151 Call-ID: 17320@pluto.bell-tel.com 5152 CSeq: 1 REGISTER 5153 Contact: sip:tawatson@example.com 5155 The request could be sent to either the registrar at bell-tel.com or 5156 the server at example.com. In the latter case, the server at 5157 example.com would proxy the request to the address indicated in the 5158 Request-URI. Then, Max-Forwards header could be used to restrict the 5159 registration to that server. 5161 16.2 Invitation to a Multicast Conference 5163 The first example invites schooler@vlsi.cs.caltech.edu to a multicast 5164 session. All examples use the Session Description Protocol (SDP) (RFC 5165 2327 [6]) as the session description format. 5167 16.2.1 Request 5169 C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0 5170 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 5171 ;maddr=239.128.16.254;ttl=16 5172 Via: SIP/2.0/UDP north.east.isi.edu 5173 From: Mark Handley 5174 To: Eve Schooler 5175 Call-ID: 2963313058@north.east.isi.edu 5176 CSeq: 1 INVITE 5177 Subject: SIP will be discussed, too 5178 Content-Type: application/sdp 5179 Content-Length: 187 5181 v=0 5182 o=user1 53655765 2353687637 IN IP4 128.3.4.5 5183 s=Mbone Audio 5184 i=Discussion of Mbone Engineering Issues 5185 e=mbone@somewhere.com 5186 c=IN IP4 224.2.0.1/127 5187 t=0 0 5188 m=audio 3456 RTP/AVP 0 5190 The From request header above states that the request was initiated 5191 by mjh@isi.edu and addressed to schooler@caltech.edu (From header 5192 fields). The Via fields list the hosts along the path from invitation 5193 initiator (the last element of the list) towards the callee. In the 5194 example above, the message was last multicast to the administratively 5195 scoped group 239.128.16.254 with a ttl of 16 from the host 5196 csvax.cs.caltech.edu. The second Via header field indicates that it 5197 was originally sent from the host north.east.isi.edu. The Request-URI 5198 indicates that the request is currently being being addressed to 5199 schooler@cs.caltech.edu, the local address that csvax looked up for 5200 the callee. 5202 In this case, the session description is using the Session 5203 Description Protocol (SDP), as stated in the Content-Type header. 5205 The header is terminated by an empty line and is followed by a 5206 message body containing the session description. 5208 16.2.2 Response 5210 The called user agent, directly or indirectly through proxy servers, 5211 indicates that it is alerting ("ringing") the called party: 5213 S->C: SIP/2.0 180 Ringing 5214 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 5215 ;maddr=239.128.16.254;ttl=16 5216 Via: SIP/2.0/UDP north.east.isi.edu 5217 From: Mark Handley 5218 To: Eve Schooler ;tag=9883472 5219 Call-ID: 2963313058@north.east.isi.edu 5220 CSeq: 1 INVITE 5222 A sample response to the invitation is given below. The first line of 5223 the response states the SIP version number, that it is a 200 (OK) 5224 response, which means the request was successful. The Via headers are 5225 taken from the request, and entries are removed hop by hop as the 5226 response retraces the path of the request. A new authentication field 5227 MAY be added by the invited user's agent if required. The Call-ID is 5228 taken directly from the original request, along with the remaining 5229 fields of the request message. The original sense of From field is 5230 preserved (i.e., it is the session initiator). 5232 In addition, the Contact header gives details of the host where the 5233 user was located, or alternatively the relevant proxy contact point 5234 which should be reachable from the caller's host. 5236 S->C: SIP/2.0 200 OK 5237 Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348 5238 ;maddr=239.128.16.254;ttl=16 5239 Via: SIP/2.0/UDP north.east.isi.edu 5240 From: Mark Handley 5241 To: Eve Schooler ;tag=9883472 5242 Call-ID: 2963313058@north.east.isi.edu 5243 CSeq: 1 INVITE 5244 Contact: sip:es@jove.cs.caltech.edu 5246 The caller confirms the invitation by sending an ACK request to the 5247 location named in the Contact header: 5249 C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0 5250 Via: SIP/2.0/UDP north.east.isi.edu 5251 From: Mark Handley 5252 To: Eve Schooler ;tag=9883472 5253 Call-ID: 2963313058@north.east.isi.edu 5254 CSeq: 1 ACK 5256 16.3 Two-party Call 5258 For two-party Internet phone calls, the response must contain a 5259 description of where to send the data. In the example below, Bell 5260 calls Watson. Bell indicates that he can receive RTP audio codings 0 5261 (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4). 5263 C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 5264 Via: SIP/2.0/UDP kton.bell-tel.com 5265 From: A. Bell 5266 To: T. Watson 5267 Call-ID: 3298420296@kton.bell-tel.com 5268 CSeq: 1 INVITE 5269 Subject: Mr. Watson, come here. 5270 Content-Type: application/sdp 5271 Content-Length: ... 5273 v=0 5274 o=bell 53655765 2353687637 IN IP4 128.3.4.5 5275 s=Mr. Watson, come here. 5276 c=IN IP4 kton.bell-tel.com 5277 m=audio 3456 RTP/AVP 0 3 4 5 5279 S->C: SIP/2.0 100 Trying 5280 Via: SIP/2.0/UDP kton.bell-tel.com 5281 From: A. Bell 5282 To: T. Watson ;tag=37462311 5283 Call-ID: 3298420296@kton.bell-tel.com 5284 CSeq: 1 INVITE 5285 Content-Length: 0 5287 S->C: SIP/2.0 180 Ringing 5288 Via: SIP/2.0/UDP kton.bell-tel.com 5289 From: A. Bell 5290 To: T. Watson ;tag=37462311 5291 Call-ID: 3298420296@kton.bell-tel.com 5292 CSeq: 1 INVITE 5293 Content-Length: 0 5295 S->C: SIP/2.0 182 Queued, 2 callers ahead 5296 Via: SIP/2.0/UDP kton.bell-tel.com 5297 From: A. Bell 5298 To: T. Watson ;tag=37462311 5299 Call-ID: 3298420296@kton.bell-tel.com 5300 CSeq: 1 INVITE 5301 Content-Length: 0 5303 S->C: SIP/2.0 182 Queued, 1 caller ahead 5304 Via: SIP/2.0/UDP kton.bell-tel.com 5305 From: A. Bell 5306 To: T. Watson ;tag=37462311 5307 Call-ID: 3298420296@kton.bell-tel.com 5308 CSeq: 1 INVITE 5309 Content-Length: 0 5311 S->C: SIP/2.0 200 OK 5312 Via: SIP/2.0/UDP kton.bell-tel.com 5313 From: A. Bell 5314 To: ;tag=37462311 5315 Call-ID: 3298420296@kton.bell-tel.com 5316 CSeq: 1 INVITE 5317 Contact: sip:watson@boston.bell-tel.com 5318 Content-Type: application/sdp 5319 Content-Length: ... 5321 v=0 5322 o=watson 4858949 4858949 IN IP4 192.1.2.3 5323 s=I'm on my way 5324 c=IN IP4 boston.bell-tel.com 5325 m=audio 5004 RTP/AVP 0 3 5327 The example illustrates the use of informational status responses. 5328 Here, the reception of the call is confirmed immediately (100), then, 5329 possibly after some database mapping delay, the call rings (180) and 5330 is then queued, with periodic status updates. 5332 Watson can only receive PCMU and GSM. Note that Watson's list of 5333 codecs may or may not be a subset of the one offered by Bell, as each 5334 party indicates the data types it is willing to receive. Watson will 5335 send audio data to port 3456 at c.bell-tel.com, Bell will send to 5336 port 5004 at boston.bell-tel.com. 5338 By default, the media session is one RTP session. Watson will receive 5339 RTCP packets on port 5005, while Bell will receive them on port 3457. 5341 Since the two sides have agreed on the set of media, Bell confirms 5342 the call without enclosing another session description: 5344 C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0 5345 Via: SIP/2.0/UDP kton.bell-tel.com 5346 From: A. Bell 5347 To: T. Watson ;tag=37462311 5348 Call-ID: 3298420296@kton.bell-tel.com 5349 CSeq: 1 ACK 5351 16.4 Terminating a Call 5353 To terminate a call, caller or callee can send a BYE request: 5355 C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0 5356 Via: SIP/2.0/UDP kton.bell-tel.com 5357 From: A. Bell 5358 To: T. A. Watson ;tag=37462311 5359 Call-ID: 3298420296@kton.bell-tel.com 5360 CSeq: 2 BYE 5362 If the callee wants to abort the call, it simply reverses the To and 5363 From fields. Note that it is unlikely that a BYE from the callee will 5364 traverse the same proxies as the original INVITE. 5366 16.5 Forking Proxy 5368 In this example, Bell (a.g.bell@bell-tel.com) (C), currently seated 5369 at host c.bell-tel.com wants to call Watson (t.watson@ieee.org). At 5370 the time of the call, Watson is logged in at two workstations, 5371 t.watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has 5372 registered with the IEEE proxy server (P) called sip.ieee.org. The 5373 IEEE server also has a registration for the home machine of Watson, 5374 at watson@h.bell-tel.com (H), as well as a permanent registration at 5375 watson@acm.org (A). For brevity, the examples omit the session 5376 description and Via header fields. 5378 Bell's user agent sends the invitation to the SIP server for the 5379 ieee.org domain: 5381 C->P: INVITE sip:t.watson@ieee.org SIP/2.0 5382 Via: SIP/2.0/UDP c.bell-tel.com 5383 From: A. Bell 5384 To: T. Watson 5385 Call-ID: 31415@c.bell-tel.com 5386 CSeq: 1 INVITE 5388 The SIP server at ieee.org tries the four addresses in parallel. It 5389 sends the following message to the home machine: 5391 P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0 5392 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 5393 Via: SIP/2.0/UDP c.bell-tel.com 5394 From: A. Bell 5395 To: T. Watson 5396 Call-ID: 31415@c.bell-tel.com 5397 CSeq: 1 INVITE 5399 This request immediately yields a 404 (Not Found) response, since 5400 Watson is not currently logged in at home: 5402 H->P: SIP/2.0 404 Not Found 5403 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 5404 Via: SIP/2.0/UDP c.bell-tel.com 5405 From: A. Bell 5406 To: T. Watson ;tag=87454273 5407 Call-ID: 31415@c.bell-tel.com 5408 CSeq: 1 INVITE 5410 The proxy ACKs the response so that host H can stop retransmitting 5411 it: 5413 P->H: ACK sip:watson@h.bell-tel.com SIP/2.0 5414 Via: SIP/2.0/UDP sip.ieee.org ;branch=1 5415 From: A. Bell 5416 To: T. Watson ;tag=87454273 5417 Call-ID: 31415@c.bell-tel.com 5418 CSeq: 1 ACK 5420 Also, P attempts to reach Watson through the ACM server: 5422 P->A: INVITE sip:watson@acm.org SIP/2.0 5423 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 5424 Via: SIP/2.0/UDP c.bell-tel.com 5425 From: A. Bell 5426 To: T. Watson 5427 Call-ID: 31415@c.bell-tel.com 5428 CSeq: 1 INVITE 5430 In parallel, the next attempt proceeds, with an INVITE to X and Y: 5432 P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0 5433 Via: SIP/2.0/UDP sip.ieee.org ;branch=3 5434 Via: SIP/2.0/UDP c.bell-tel.com 5435 From: A. Bell 5436 To: T. Watson 5437 Call-ID: 31415@c.bell-tel.com 5438 CSeq: 1 INVITE 5440 P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0 5441 Via: SIP/2.0/UDP sip.ieee.org ;branch=4 5442 Via: SIP/2.0/UDP c.bell-tel.com 5443 From: A. Bell 5444 To: T. Watson 5445 Call-ID: 31415@c.bell-tel.com 5446 CSeq: 1 INVITE 5448 As it happens, both Watson at X and a colleague in the other lab at 5449 host Y hear the phones ringing and pick up. Both X and Y return 200s 5450 via the proxy to Bell. 5452 X->P: SIP/2.0 200 OK 5453 Via: SIP/2.0/UDP sip.ieee.org ;branch=3 5454 Via: SIP/2.0/UDP c.bell-tel.com 5455 From: A. Bell 5456 To: T. Watson ;tag=192137601 5457 Call-ID: 31415@c.bell-tel.com 5458 CSeq: 1 INVITE 5459 Contact: sip:t.watson@x.bell-tel.com 5461 Y->P: SIP/2.0 200 OK 5462 Via: SIP/2.0/UDP sip.ieee.org ;branch=4 5463 Via: SIP/2.0/UDP c.bell-tel.com 5464 Contact: sip:t.watson@y.bell-tel.com 5465 From: A. Bell 5466 To: T. Watson ;tag=35253448 5467 Call-ID: 31415@c.bell-tel.com 5468 CSeq: 1 INVITE 5470 Both responses are forwarded to Bell, using the Via information. At 5471 this point, the ACM server is still searching its database. P can now 5472 cancel this attempt: 5474 P->A: CANCEL sip:watson@acm.org SIP/2.0 5475 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 5476 From: A. Bell 5477 To: T. Watson 5478 Call-ID: 31415@c.bell-tel.com 5479 CSeq: 1 CANCEL 5481 The ACM server gladly stops its neural-network database search and 5482 responds with a 200. The 200 will not travel any further, since P is 5483 the last Via stop. 5485 A->P: SIP/2.0 200 OK 5486 Via: SIP/2.0/UDP sip.ieee.org ;branch=2 5487 From: A. Bell 5488 To: T. Watson 5489 Call-ID: 31415@c.bell-tel.com 5490 CSeq: 1 CANCEL 5492 Bell gets the two 200 responses from X and Y in short order. Bell's 5493 reaction now depends on his software. He can either send an ACK to 5494 both if human intelligence is needed to determine who he wants to 5495 talk to or he can automatically reject one of the two calls. Here, he 5496 acknowledges both, separately and directly to the final destination: 5498 C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0 5499 Via: SIP/2.0/UDP c.bell-tel.com 5500 From: A. Bell 5501 To: T. Watson ;tag=192137601 5502 Call-ID: 31415@c.bell-tel.com 5503 CSeq: 1 ACK 5505 C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0 5506 Via: SIP/2.0/UDP c.bell-tel.com 5507 From: A. Bell 5508 To: T. Watson ;tag=35253448 5509 Call-ID: 31415@c.bell-tel.com 5510 CSeq: 1 ACK 5512 After a brief discussion between Bell with X and Y, it becomes clear 5513 that Watson is at X. (Note that this is not a three-way call; only 5514 Bell can talk to X and Y, but X and Y cannot talk to each other.) 5515 Thus, Bell sends a BYE to Y, which is replied to: 5517 C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0 5518 Via: SIP/2.0/UDP c.bell-tel.com 5519 From: A. Bell 5520 To: T. Watson ;tag=35253448 5521 Call-ID: 31415@c.bell-tel.com 5522 CSeq: 2 BYE 5524 Y->C: SIP/2.0 200 OK 5525 Via: SIP/2.0/UDP c.bell-tel.com 5526 From: A. Bell 5527 To: T. Watson ;tag=35253448 5528 Call-ID: 31415@c.bell-tel.com 5529 CSeq: 2 BYE 5531 16.6 Redirects 5533 Replies with status codes 301 (Moved Permanently) or 302 (Moved 5534 Temporarily) specify another location using the Contact field. 5535 Continuing our earlier example, the server P at ieee.org decides to 5536 redirect rather than proxy the request: 5538 P->C: SIP/2.0 302 Moved temporarily 5539 Via: SIP/2.0/UDP c.bell-tel.com 5540 From: A. Bell 5541 To: T. Watson ;tag=72538263 5542 Call-ID: 31415@c.bell-tel.com 5543 CSeq: 1 INVITE 5544 Contact: sip:watson@h.bell-tel.com, 5545 sip:watson@acm.org, sip:t.watson@x.bell-tel.com, 5546 sip:watson@y.bell-tel.com 5547 CSeq: 1 INVITE 5549 As another example, assume Alice (A) wants to delegate her calls to 5550 Bob (B) while she is on vacation until July 29th, 1998. Any calls 5551 meant for her will reach Bob with Alice's To field, indicating to him 5552 what role he is to play. Charlie (C) calls Alice (A), whose server 5553 returns: 5555 A->C: SIP/2.0 302 Moved temporarily 5556 From: Charlie 5557 To: Alice ;tag=2332462 5558 Call-ID: 27182@caller.com 5559 Contact: sip:bob@anywhere.com 5560 Expires: Wed, 29 Jul 1998 9:00:00 GMT 5561 CSeq: 1 INVITE 5563 Charlie then sends the following request to the SIP server of the 5564 anywhere.com domain. Note that the server at anywhere.com forwards 5565 the request to Bob based on the Request-URI. 5567 C->B: INVITE sip:bob@anywhere.com SIP/2.0 5568 From: sip:charlie@caller.com 5569 To: sip:alice@anywhere.com 5570 Call-ID: 27182@caller.com 5571 CSeq: 2 INVITE 5573 In the third redirection example, we assume that all outgoing 5574 requests are directed through a local firewall F at caller.com, with 5575 Charlie again inviting Alice: 5577 C->F: INVITE sip:alice@anywhere.com SIP/2.0 5578 From: sip:charlie@caller.com 5579 To: Alice 5580 Call-ID: 27182@caller.com 5581 CSeq: 1 INVITE 5583 The local firewall at caller.com happens to be overloaded and thus 5584 redirects the call from Charlie to a secondary server S: 5586 F->C: SIP/2.0 302 Moved temporarily 5587 From: sip:charlie@caller.com 5588 To: Alice 5589 Call-ID: 27182@caller.com 5590 CSeq: 1 INVITE 5591 Contact: 5593 Based on this response, Charlie directs the same invitation to the 5594 secondary server spare.caller.com at port 5080, but maintains the 5595 same Request-URI as before: 5597 C->S: INVITE sip:alice@anywhere.com SIP/2.0 5598 From: sip:charlie@caller.com 5599 To: Alice 5600 Call-ID: 27182@caller.com 5601 CSeq: 2 INVITE 5603 16.7 Negotiation 5605 An example of a 606 (Not Acceptable) response is: 5607 S->C: SIP/2.0 606 Not Acceptable 5608 From: sip:mjh@isi.edu 5609 To: ;tag=7434264 5610 Call-ID: 14142@north.east.isi.edu 5611 CSeq: 1 INVITE 5612 Contact: sip:mjh@north.east.isi.edu 5613 Warning: 370 "Insufficient bandwidth (only have ISDN)", 5614 305 "Incompatible media format", 5615 330 "Multicast not available" 5616 Content-Type: application/sdp 5617 Content-Length: 50 5619 v=0 5620 s=Let's talk 5621 b=CT:128 5622 c=IN IP4 north.east.isi.edu 5623 m=audio 3456 RTP/AVP 5 0 7 5624 m=video 2232 RTP/AVP 31 5626 In this example, the original request specified a bandwidth that was 5627 higher than the access link could support, requested multicast, and 5628 requested a set of media encodings. The response states that only 128 5629 kb/s is available and that (only) DVI, PCM or LPC audio could be 5630 supported in order of preference. 5632 The response also states that multicast is not available. In such a 5633 case, it might be appropriate to set up a transcoding gateway and 5634 re-invite the user. 5636 16.8 OPTIONS Request 5638 A caller Alice can use an OPTIONS request to find out the 5639 capabilities of a potential callee Bob, without "ringing" the 5640 designated address. Bob returns a description indicating that he is 5641 capable of receiving audio encodings PCM Ulaw (payload type 0), 1016 5642 (payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic 5643 payload type 99), and video encodings H.261 (payload type 31) and 5644 H.263 (payload type 34). 5646 C->S: OPTIONS sip:bob@example.com SIP/2.0 5647 From: Alice 5648 To: Bob 5649 Call-ID: 6378@host.anywhere.org 5650 CSeq: 1 OPTIONS 5651 Accept: application/sdp 5653 S->C: SIP/2.0 200 OK 5654 From: Alice 5655 To: Bob ;tag=376364382 5656 Call-ID: 6378@host.anywhere.org 5657 Content-Length: 81 5658 Content-Type: application/sdp 5660 v=0 5661 m=audio 0 RTP/AVP 0 1 3 99 5662 m=video 0 RTP/AVP 31 34 5663 a=rtpmap:99 SX7300/8000 5665 A Minimal Implementation 5667 A.1 Client 5669 All clients MUST be able to generate the INVITE and ACK requests. 5670 Clients MUST generate and parse the Call-ID, Content-Length, 5671 Content-Type, CSeq, From and To headers. Clients MUST also parse the 5672 Require header. A minimal implementation MUST understand SDP (RFC 5673 2327, [6]). It MUST be able to recognize the status code classes 1 5674 through 6 and act accordingly. 5676 The following capability sets build on top of the minimal 5677 implementation described in the previous paragraph. In general, each 5678 capability listed below builds on the ones above it: 5680 Basic: A basic implementation adds support for the BYE method to 5681 allow the interruption of a pending call attempt. It includes a 5682 User-Agent header in its requests and indicate its preferred 5683 language in the Accept-Language header. 5685 Redirection: To support call forwarding, a client needs to be able to 5686 understand the Contact header, but only the SIP-URL part, not 5687 the parameters. 5689 Firewall-friendly: A firewall-friendly client understands the Route 5690 and Record-Route header fields and can be configured to use a 5691 local proxy for all outgoing requests. 5693 Negotiation: A client MUST be able to request the OPTIONS method and 5694 understand the 380 (Alternative Service) status and the Contact 5695 parameters to participate in terminal and media negotiation. It 5696 SHOULD be able to parse the Warning response header to provide 5697 useful feedback to the caller. 5699 Authentication: If a client wishes to invite callees that require 5700 caller authentication, it MUST be able to recognize the 401 5701 (Unauthorized) status code, MUST be able to generate the 5702 Authorization request header and MUST understand the WWW- 5703 Authenticate response header. 5705 If a client wishes to use proxies that require caller authentication, 5706 it MUST be able to recognize the 407 (Proxy Authentication Required) 5707 status code, MUST be able to generate the Proxy-Authorization request 5708 header and understand the Proxy-Authenticate response header. 5710 A.2 Server 5712 A minimally compliant server implementation MUST understand the 5713 INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also 5714 understand CANCEL. It MUST parse and generate, as appropriate, the 5715 Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max- 5716 Forwards, Require, To and Via headers. It MUST echo the CSeq and 5717 Timestamp headers in the response. It SHOULD include the Server 5718 header in its responses. 5720 A.3 Header Processing 5722 Table 6 lists the headers that different implementations support. UAC 5723 refers to a user-agent client (calling user agent), UAS to a user- 5724 agent server (called user-agent). 5726 The fields in the table have the following meaning. Type is as in 5727 Table 4 and 5. "-" indicates the field is not meaningful to this 5728 system (although it might be generated by it). "m" indicates the 5729 field MUST be understood. "b" indicates the field SHOULD be 5730 understood by a Basic implementation. "r" indicates the field SHOULD 5731 be understood if the system claims to understand redirection. "a" 5732 indicates the field SHOULD be understood if the system claims to 5733 support authentication. "e" indicates the field SHOULD be understood 5734 if the system claims to support encryption. "o" indicates support of 5735 the field is purely optional. Headers whose support is optional for 5736 all implementations are not shown. 5738 B Usage of the Session Description Protocol (SDP) 5740 This section describes the use of the Session Description Protocol 5741 (SDP) (RFC 2327 [6]). 5743 B.1 Configuring Media Streams 5745 The caller and callee align their media descriptions so that the nth 5746 media stream ("m=" line) in the caller's session description 5747 corresponds to the nth media stream in the callee's description. 5749 type UAC proxy UAS registrar 5750 _____________________________________________________ 5751 Accept R - o m m 5752 Accept-Encoding R - - m m 5753 Accept-Language R - b b b 5754 Allow 405 o - - - 5755 Authorization R a o a a 5756 Call-ID g m m m m 5757 Content-Encoding g m - m m 5758 Content-Length g m m m m 5759 Content-Type g m - m m 5760 CSeq g m m m m 5761 Encryption g e - e e 5762 Expires g - o o m 5763 From g m o m m 5764 Hide R - m - - 5765 Contact R - - - m 5766 Contact r r r - - 5767 Max-Forwards R - b - - 5768 Proxy-Authenticate 407 a - - - 5769 Proxy-Authorization R - a - - 5770 Proxy-Require R - m - - 5771 Require R m - m m 5772 Response-Key R - - e e 5773 Route R - m - - 5774 Timestamp g o o m m 5775 To g m m m m 5776 Unsupported r b b - - 5777 User-Agent g b - b - 5778 Via g m m m m 5779 WWW-Authenticate 401 a - - - 5781 Table 6: Header Field Processing Requirements 5783 All media descriptions SHOULD contain "a=rtpmap" mappings from RTP 5784 payload types to encodings. 5786 This allows easier migration away from static payload 5787 types. 5789 If the callee wants to neither send nor receive a stream offered by 5790 the caller, the callee sets the port number of that stream to zero in 5791 its media description. 5793 There currently is no other way than port zero for the 5794 callee to refuse a bidirectional stream offered by the 5795 caller. Both caller and callee need to be aware what media 5796 tools are to be started. 5798 For example, assume that the caller Alice has included the following 5799 description in her INVITE request. It includes an audio stream and 5800 two bidirectional video streams, using H.261 (payload type 31) and 5801 MPEG (payload type 32). 5803 v=0 5804 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 5805 c=IN IP4 host.anywhere.com 5806 m=audio 49170 RTP/AVP 0 5807 a=rtpmap:0 PCMU/8000 5808 m=video 51372 RTP/AVP 31 5809 a=rtpmap:31 H261/90000 5810 m=video 53000 RTP/AVP 32 5811 a=rtpmap:32 MPV/90000 5813 The callee, Bob, does not want to receive or send the first video 5814 stream, so it returns the media description below: 5816 v=0 5817 o=bob 2890844730 2890844730 IN IP4 host.example.com 5818 c=IN IP4 host.example.com 5819 m=audio 47920 RTP/AVP 0 1 5820 a=rtpmap:0 PCMU/8000 5821 a=rtpmap:1 1016/8000 5822 m=video 0 RTP/AVP 31 5823 m=video 53000 RTP/AVP 32 5824 a=rtpmap:32 MPV/90000 5826 B.2 Setting SDP Values for Unicast 5828 If a session description from a caller contains a media stream which 5829 is listed as send (receive) only, it means that the caller is only 5830 willing to send (receive) this stream, not receive (send). The same 5831 is true for the callee. 5833 For receive-only and send-or-receive streams, the port number and 5834 address in the session description indicate where the media stream 5835 should be sent to by the recipient of the session description, either 5836 caller or callee. For send-only streams, the address and port number 5837 have no significance and SHOULD be set to zero. 5839 The list of payload types for each media stream conveys two pieces of 5840 information, namely the set of codecs that the caller or callee is 5841 capable of sending or receiving, and the RTP payload type numbers 5842 used to identify those codecs. For receive-only or send-and-receive 5843 media streams, a caller SHOULD list all of the codecs it is capable 5844 of supporting in the session description in an INVITE or ACK. For 5845 send-only streams, the caller SHOULD indicate only those it wishes to 5846 send for this session. For receive-only streams, the payload type 5847 numbers indicate the value of the payload type field in RTP packets 5848 the caller is expecting to receive for that codec type. For send-only 5849 streams, the payload type numbers indicate the value of the payload 5850 type field in RTP packets the caller is planning to send for that 5851 codec type. For send-and-receive streams, the payload type numbers 5852 indicate the value of the payload type field the caller expects to 5853 both send and receive. 5855 If a media stream is listed as receive-only by the caller, the callee 5856 lists, in the response, those codecs it intends to use from among the 5857 ones listed in the request. If a media stream is listed as send-only 5858 by the caller, the callee lists, in the response, those codecs it is 5859 willing to receive among the ones listed in the the request. If the 5860 media stream is listed as both send and receive, the callee lists 5861 those codecs it is capable of sending or receiving among the ones 5862 listed by the caller in the INVITE. The actual payload type numbers 5863 in the callee's session description corresponding to a particular 5864 codec MUST be the same as the caller's session description. 5866 If caller and callee have no media formats in common for a particular 5867 stream, the callee MUST return a session description containing the 5868 particular "m=" line, but with the port number set to zero, and no 5869 payload types listed. 5871 If there are no media formats in common for all streams, the callee 5872 SHOULD return a 400 response, with a 304 Warning header field. 5874 B.3 Multicast Operation 5876 The interpretation of send-only and receive-only for multicast media 5877 sessions differs from that for unicast sessions. For multicast, 5878 send-only means that the recipient of the session description (caller 5879 or callee) SHOULD only send media streams to the address and port 5880 indicated. Receive-only means that the recipient of the session 5881 description SHOULD only receive media on the address and port 5882 indicated. 5884 For multicast, receive and send multicast addresses are the same and 5885 all parties use the same port numbers to receive media data. If the 5886 session description provided by the caller is acceptable to the 5887 callee, the callee can choose not to include a session description or 5888 MAY echo the description in the response. 5890 A callee MAY, in the response, return a session description with some 5891 of the payload types removed, or port numbers set to zero (but no 5892 other value). This indicates to the caller that the callee does not 5893 support the given stream or media types which were removed. A callee 5894 MUST NOT change whether a given stream is send-only, receive-only, or 5895 send-and-receive. 5897 If a callee does not support multicast at all, it SHOULD return a 400 5898 status response and include a 330 Warning. 5900 B.4 Delayed Media Streams 5902 In some cases, a caller may not know the set of media formats which 5903 it can support at the time it would like to issue an invitation. This 5904 is the case when the caller is actually a gateway to another protocol 5905 which performs media format negotiation after call setup. When this 5906 occurs, a caller MAY issue an INVITE with a session description that 5907 contains no media lines. The callee SHOULD interpret this to mean 5908 that the caller wishes to participate in a multimedia session 5909 described by the session description, but that the media streams are 5910 not yet known. The callee SHOULD return a session description 5911 indicating the streams and media formats it is willing to support, 5912 however. The caller MAY update the session description either in the 5913 ACK request or in a re-INVITE at a later time, once the streams are 5914 known. 5916 B.5 Putting Media Streams on Hold 5918 If a party in a call wants to put the other party "on hold", i.e., 5919 request that it temporarily stops sending one or more media streams, 5920 a party re-invites the other by sending an INVITE request with a 5921 modified session description. The session description is the same as 5922 in the original invitation (or response), but the "c" destination 5923 addresses for the media streams to be put on hold are set to zero 5924 (0.0.0.0). 5926 B.6 Subject and SDP "s=" Line 5928 The SDP "s=" line and the SIP Subject header field have different 5929 meanings when inviting to a multicast session. The session 5930 description line describes the subject of the multicast session, 5931 while the SIP Subject header field describes the reason for the 5932 invitation. The example in Section 16.2 illustrates this point. For 5933 invitations to two-party sessions, the SDP "s=" line MAY be left 5934 empty. 5936 B.7 The SDP "o=" Line 5938 The "o=" line is not strictly necessary for two-party sessions, but 5939 MUST be present to allow re-use of SDP-based tools. 5941 C Summary of Augmented BNF 5943 All of the mechanisms specified in this document are described in 5944 both prose and an augmented Backus-Naur Form (BNF) similar to that 5945 used by RFC 822 [9]. Implementors will need to be familiar with the 5946 notation in order to understand this specification. The augmented BNF 5947 includes the following constructs: 5949 name = definition 5951 The name of a rule is simply the name itself (without any enclosing 5952 "<" and ">") and is separated from its definition by the equal "=" 5953 character. White space is only significant in that indentation of 5954 continuation lines is used to indicate a rule definition that spans 5955 more than one line. Certain basic rules are in uppercase, such as SP, 5956 LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within 5957 definitions whenever their presence will facilitate discerning the 5958 use of rule names. 5960 "literal" 5962 Quotation marks surround literal text. Unless stated otherwise, the 5963 text is case-insensitive. 5965 rule1 | rule2 5967 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" 5968 will accept yes or no. 5970 (rule1 rule2) 5971 Elements enclosed in parentheses are treated as a single element. 5972 Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo 5973 elem" and "elem bar elem". 5975 *rule 5977 The character "*" preceding an element indicates repetition. The full 5978 form is "*element" indicating at least and at most 5979 occurrences of element. Default values are 0 and infinity so that 5980 "*(element)" allows any number, including zero; "1*element" requires 5981 at least one; and "1*2element" allows one or two. 5983 [rule] 5985 Square brackets enclose optional elements; "[foo bar]" is equivalent 5986 to "*1(foo bar)". 5988 N rule 5990 Specific repetition: "(element)" is equivalent to 5991 "*(element)"; that is, exactly occurrences of (element). 5992 Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three 5993 alphabetic characters. 5995 #rule 5997 A construct "#" is defined, similar to "*", for defining lists of 5998 elements. The full form is "# element" indicating at least 5999 and at most elements, each separated by one or more commas (",") 6000 and OPTIONAL linear white space (LWS). This makes the usual form of 6001 lists very easy; a rule such as 6003 ( *LWS element *( *LWS "," *LWS element )) 6005 can be shown as 1# element. Wherever this construct is used, null 6006 elements are allowed, but do not contribute to the count of elements 6007 present. That is, "(element), , (element)" is permitted, but counts 6008 as only two elements. Therefore, where at least one element is 6009 required, at least one non-null element MUST be present. Default 6010 values are 0 and infinity so that "#element" allows any number, 6011 including zero; "1#element" requires at least one; and "1#2element" 6012 allows one or two. 6014 ; comment 6016 A semi-colon, set off some distance to the right of rule text, starts 6017 a comment that continues to the end of line. This is a simple way of 6018 including useful notes in parallel with the specifications. 6020 implied *LWS 6022 The grammar described by this specification is word-based. Except 6023 where noted otherwise, linear white space (LWS) can be included 6024 between any two adjacent words (token or quoted-string), and between 6025 adjacent tokens and separators, without changing the interpretation 6026 of a field. At least one delimiter (LWS and/or separators) MUST exist 6027 between any two tokens (for the definition of "token" below), since 6028 they would otherwise be interpreted as a single token. 6030 C.1 Basic Rules 6032 The following rules are used throughout this specification to 6033 describe basic parsing constructs. The US-ASCII coded character set 6034 is defined by ANSI X3.4-1986. 6036 OCTET = 6037 CHAR = 6038 upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | 6039 "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | 6040 "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" 6041 lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | 6042 "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | 6043 "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" 6044 alpha = lowalpha | upalpha 6045 digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 6046 "8" | "9" 6047 alphanum = alpha | digit 6048 CTL = 6050 CR = %d13 ; US-ASCII CR, carriage return character 6051 LF = %d10 ; US-ASCII LF, line feed character 6052 SP = %d32 ; US-ASCII SP, space character 6053 HT = %d09 ; US-ASCII HT, horizontal tab character 6054 CRLF = CR LF ; typically the end of a line 6056 The following are defined in RFC 2396 [12] for the SIP URI: 6058 unreserved = alphanum | mark 6059 mark = "-" | "_" | "." | "!" | "~" | "*" | "'" 6060 | "(" | ")" 6061 escaped = "%" hex hex 6063 SIP header field values can be folded onto multiple lines if the 6064 continuation line begins with a space or horizontal tab. All linear 6065 white space, including folding, has the same semantics as SP. A 6066 recipient MAY replace any linear white space with a single SP before 6067 interpreting the field value or forwarding the message downstream. 6069 LWS = [CRLF] 1*( SP | HT ) ; linear whitespace 6071 The TEXT-UTF8 rule is only used for descriptive field contents and 6072 values that are not intended to be interpreted by the message parser. 6073 Words of *TEXT-UTF8 contain characters from the UTF-8 character set 6074 (RFC 2279 [21]). In this regard, SIP differs from HTTP, which uses 6075 the ISO 8859-1 character set. 6077 TEXT-UTF8 = 6080 A CRLF is allowed in the definition of TEXT-UTF8 only as part of a 6081 header field continuation. It is expected that the folding LWS will 6082 be replaced with a single SP before interpretation of the TEXT-UTF8 6083 value. 6085 Hexadecimal numeric characters are used in several protocol elements. 6087 hex = "A" | "B" | "C" | "D" | "E" | "F" 6088 | "a" | "b" | "c" | "d" | "e" | "f" | digit 6090 Many SIP header field values consist of words separated by LWS or 6091 special characters. These special characters MUST be in a quoted 6092 string to be used within a parameter value. 6094 token = 1*< any CHAR except CTL's or separators> 6095 separators = "(" | ")" | "<" | ">" | "@" | 6096 "," | ";" | ":" | "\" | <"> | 6097 "/" | "[" | "]" | "?" | "=" | 6098 "{" | "}" | SP | HT 6100 Comments can be included in some SIP header fields by surrounding the 6101 comment text with parentheses. Comments are only allowed in fields 6102 containing "comment" as part of their field value definition. In all 6103 other fields, parentheses are considered part of the field value. 6105 comment = "(" *(ctext | quoted-pair | comment) ")" 6106 ctext = < any TEXT-UTF8 excluding "(" and ")"> 6108 A string of text is parsed as a single word if it is quoted using 6109 double-quote marks. 6111 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) 6112 qdtext = > 6114 The backslash character ("\") MAY be used as a single-character 6115 quoting mechanism only within quoted-string and comment constructs. 6117 quoted-pair = " \ " CHAR 6119 D Using SRV DNS Records 6121 The following procedure is experimental and relies on DNS SRV records 6122 (RFC 2052 [14]). The steps listed below are used in place of the two 6123 steps in section 1.4.2. 6125 If a step elicits no addresses, the client continues to the next 6126 step. However if a step elicits one or more addresses, but no SIP 6127 server at any of those addresses responds, then the client concludes 6128 the server is down and doesn't continue on to the next step. 6130 When SRV records are to be used, the protocol to use when querying 6131 for the SRV record is "sip". SRV records contain port numbers for 6132 servers, in addition to IP addresses; the client always uses this 6133 port number when contacting the SIP server. Otherwise, the port 6134 number in the SIP URI is used, if present. If there is no port in the 6135 URI, the default port, 5060, is used. 6137 1. If the host portion of the Request-URI is an IP address, 6138 the client contacts the server at the given address. If the 6139 host portion of the Request-URI is not an IP address, the 6140 client proceeds to the next step. 6142 2. The Request-URI is examined. If it contains an explicit 6143 port number, the next two steps are skipped. 6145 3. The Request-URI is examined. If it does not specify a 6146 protocol (TCP or UDP), the client queries the name server 6147 for SRV records for both UDP (if supported by the client) 6148 and TCP (if supported by the client) SIP servers. The 6149 format of these queries is defined in RFC 2052 [14]. The 6150 results of the query or queries are merged together and 6151 ordered based on priority. Then, the searching technique 6152 outlined in RFC 2052 [14] is used to select servers in 6153 order. If DNS doesn't return any records, the user goes to 6154 the last step. Otherwise, the user attempts to contact each 6155 server in the order listed. If no server is contacted, the 6156 user gives up. 6158 4. If the Request-URI specifies a protocol (TCP or UDP) that 6159 is supported by the client, the client queries the name 6160 server for SRV records for SIP servers of that protocol 6161 type only. If the client does not support the protocol 6162 specified in the Request-URI, it gives up. The searching 6163 technique outlined in RFC 2052 [14] is used to select 6164 servers from the DNS response in order. If DNS doesn't 6165 return any records, the user goes to the last step. 6166 Otherwise, the user attempts to contact each server in the 6167 order listed. If no server is contacted, the user gives up. 6169 5. The client queries the name server for address records for 6170 the host portion of the Request-URI. If there were no 6171 address records, the client stops, as it has been unable to 6172 locate a server. By address record, we mean A RR's, AAAA 6173 RR's, or their most modern equivalent. 6175 A client MAY cache a successful DNS query result. A successful query 6176 is one which contained records in the answer, and a server was 6177 contacted at one of the addresses from the answer. When the client 6178 wishes to send a request to the same host, it starts the search as if 6179 it had just received this answer from the name server. The server 6180 uses the procedures specified in RFC1035 [15] regarding cache 6181 invalidation when the time-to-live of the DNS result expires. If the 6182 client does not find a SIP server among the addresses listed in the 6183 cached answer, it starts the search at the beginning of the sequence 6184 described above. 6186 For example, consider a client that wishes to send a SIP request. The 6187 Request-URI for the destination is sip:user@company.com. The client 6188 only supports UDP. It would follow these steps: 6190 1. The host portion is not an IP address, so the client goes 6191 to step 2 above. 6193 2. The client does a DNS query of QNAME="sip.udp.company.com", 6194 QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it 6195 omits the TCP query. There were no addresses in the DNS 6196 response, so the client goes to the next step. 6198 3. The client does a DNS query for A records for 6199 "company.com". An address is found, so that client attempts 6200 to contact a server at that address at port 5060. 6202 E IANA Considerations 6204 Section 4.4 describes a name space and mechanism for registering SIP 6205 options. 6207 Section 6.41 describes the name space for registering SIP warn-codes. 6209 F Changes in Version -12 6211 Since version -11, the following changes have been made. These 6212 changes reflect IESG comments. 6214 o Section 16.3 was missing Content-Type header. 6216 o The DNS search procedure has changed. Reference to CNAME 6217 lookups has been removed since their usage is implicit in 6218 normal DNS procedures. Also, automatically appending a sip. to 6219 the domain name in the URL before lookup has been removed. A 6220 note has been added discussing the creating of SIP URL's from 6221 email addresses and encourages the usage of rfc2219. 6223 o Semicolon removed from user and password BNF in SIP URL. 6225 o An email address for IANA registrations is now listed. 6227 o For the Moved Temporarily redirect response, no default value 6228 for the expiration of this address is specified. This has been 6229 clarified; the redirected address is only valid for the 6230 duration of the call. This is consistent with exising text 6231 under the Contact header description which indicates that the 6232 values should not be cached. 6234 o Clarification that CANCEL and ACK's should have the same Via 6235 branch parameter as the request they cancel or acknowledge. 6237 G Acknowledgments 6239 We wish to thank the members of the IETF MMUSIC WG for their comments 6240 and suggestions. Detailed comments were provided by Anders 6241 Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian 6242 Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe 6243 J. Sambol, and Eric Tremblay. 6245 This work is based, inter alia, on [37,38]. 6247 H Authors' Addresses 6249 Mark Handley 6250 USC Information Sciences Institute 6251 c/o MIT Laboratory for Computer Science 6252 545 Technology Square 6253 Cambridge, MA 02139 6254 USA 6255 electronic mail: mjh@isi.edu 6257 Henning Schulzrinne 6258 Dept. of Computer Science 6259 Columbia University 6260 1214 Amsterdam Avenue 6261 New York, NY 10027 6262 USA 6263 electronic mail: schulzrinne@cs.columbia.edu 6265 Eve Schooler 6266 Computer Science Department 256-80 6267 California Institute of Technology 6268 Pasadena, CA 91125 6269 USA 6270 electronic mail: schooler@cs.caltech.edu 6272 Jonathan Rosenberg 6273 Lucent Technologies, Bell Laboratories 6274 Rm. 4C-526 6275 101 Crawfords Corner Road 6276 Holmdel, NJ 07733 6277 USA 6278 electronic mail: jdrosen@bell-labs.com 6280 I Bibliography 6282 [1] R. Pandya, "Emerging mobile and personal communication systems," 6283 IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995. 6285 [2] B. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 6286 "Resource ReSerVation protocol (RSVP) -- version 1 functional 6287 specification," RFC 2205, Internet Engineering Task Force, Oct. 1997. 6289 [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 6290 transport protocol for real-time applications," RFC 1889, Internet 6291 Engineering Task Force, Jan. 1996. 6293 [4] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming 6294 protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 6295 1998. 6297 [5] M. Handley, "SAP: Session announcement protocol," Internet Draft, 6298 Internet Engineering Task Force, Nov. 1996. Work in progress. 6300 [6] M. Handley and V. Jacobson, "SDP: session description protocol," 6301 RFC 2327, Internet Engineering Task Force, Apr. 1998. 6303 [7] International Telecommunication Union, "Visual telephone systems 6304 and equipment for local area networks which provide a non-guaranteed 6305 quality of service," Recommendation H.323, Telecommunication 6306 Standardization Sector of ITU, Geneva, Switzerland, May 1996. 6308 [8] International Telecommunication Union, "Control protocol for 6309 multimedia communication," Recommendation H.245, Telecommunication 6310 Standardization Sector of ITU, Geneva, Switzerland, Feb. 1998. 6312 [9] International Telecommunication Union, "Media stream 6313 packetization and synchronization on non-guaranteed quality of 6314 service LANs," Recommendation H.225.0, Telecommunication 6315 Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996. 6317 [10] S. Bradner, "Key words for use in RFCs to indicate requirement 6318 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 6320 [11] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, and T. Berners- 6321 Lee, "Hypertext transfer protocol -- HTTP/1.1," RFC 2068, Internet 6322 Engineering Task Force, Jan. 1997. 6324 [12] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 6325 identifiers (URI): generic syntax," RFC 2396, Internet Engineering 6326 Task Force, Aug. 1998. 6328 [13] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform resource 6329 locators (URL)," RFC 1738, Internet Engineering Task Force, Dec. 6330 1994. 6332 [14] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the 6333 location of services (DNS SRV)," RFC 2052, Internet Engineering Task 6334 Force, Oct. 1996. 6336 [15] P. Mockapetris, "Domain names - implementation and 6337 specification," RFC STD 13, 1035, Internet Engineering Task Force, 6338 Nov. 1987. 6340 [16] M. Hamilton and R. Wright, "Use of DNS aliases for network 6341 services," RFC 2219, Internet Engineering Task Force, Oct. 1997. 6343 [17] D. Zimmerman, "The finger user information protocol," RFC 1288, 6344 Internet Engineering Task Force, Dec. 1991. 6346 [18] S. Williamson, M. Kosters, D. Blacka, J. Singh, and K. Zeilstra, 6347 "Referral whois (rwhois) protocol V1.5," RFC 2167, Internet 6348 Engineering Task Force, June 1997. 6350 [19] W. Yeong, T. Howes, and S. Kille, "Lightweight directory access 6351 protocol," RFC 1777, Internet Engineering Task Force, Mar. 1995. 6353 [20] E. M. Schooler, "A multicast user directory service for 6354 synchronous rendezvous," Master's Thesis CS-TR-96-18, Department of 6355 Computer Science, California Institute of Technology, Pasadena, 6356 California, Aug. 1996. 6358 [21] F. Yergeau, "UTF-8, a transformation format of ISO 10646," RFC 6359 2279, Internet Engineering Task Force, Jan. 1998. 6361 [22] W. R. Stevens, TCP/IP illustrated: the protocols , vol. 1. 6362 Reading, Massachusetts: Addison-Wesley, 1994. 6364 [23] J. Mogul and S. Deering, "Path MTU discovery," RFC 1191, 6365 Internet Engineering Task Force, Nov. 1990. 6367 [24] D. Crocker, "Standard for the format of ARPA internet text 6368 messages," RFC STD 11, 822, Internet Engineering Task Force, Aug. 6369 1982. 6371 [25] D. Meyer, "Administratively scoped IP multicast," RFC 2365, 6372 Internet Engineering Task Force, July 1998. 6374 [26] H. Schulzrinne, "RTP profile for audio and video conferences 6375 with minimal control," RFC 1890, Internet Engineering Task Force, 6376 Jan. 1996. 6378 [27] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 6379 recommendations for security," RFC 1750, Internet Engineering Task 6380 Force, Dec. 1994. 6382 [28] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL 6383 scheme," RFC 2368, Internet Engineering Task Force, July 1998. 6385 [29] B. Braden, "Requirements for internet hosts - application and 6386 support," RFC STD 3, 1123, Internet Engineering Task Force, Oct. 6387 1989. 6389 [30] J. Palme, "Common internet message headers," RFC 2076, Internet 6390 Engineering Task Force, Feb. 1997. 6392 [31] H. Alvestrand, "IETF policy on character sets and languages," 6393 RFC 2277, Internet Engineering Task Force, Jan. 1998. 6395 [32] M. Elkins, "MIME security with pretty good privacy (PGP)," RFC 6396 2015, Internet Engineering Task Force, Oct. 1996. 6398 [33] D. Atkins, W. Stallings, and P. Zimmermann, "PGP message 6399 exchange formats," RFC 1991, Internet Engineering Task Force, Aug. 6400 1996. 6402 [34] R. Atkinson, "Security architecture for the internet protocol," 6403 RFC 1825, Internet Engineering Task Force, Aug. 1995. 6405 [35] C. Allen and T. Dierks, "The TLS protocol version 1.0," Internet 6406 Draft, Internet Engineering Task Force, Nov. 1997. Work in progress. 6408 [36] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, 6409 A. Luotonen, and L. Stewart, "HTTP authentication: Basic and digest 6410 access authentication," Internet Draft, Internet Engineering Task 6411 Force, Sept. 1998. Work in progress. 6413 [37] E. M. Schooler, "Case study: multimedia conference control in a 6414 packet-switched teleconferencing system," Journal of Internetworking: 6415 Research and Experience , vol. 4, pp. 99--120, June 1993. ISI 6416 reprint series ISI/RS-93-359. 6418 [38] H. Schulzrinne, "Personal mobility for multimedia services in 6419 the Internet," in European Workshop on Interactive Distributed 6420 Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar. 6421 1996. 6423 Full Copyright Statement 6425 Copyright (c) The Internet Society (1999). All Rights Reserved. 6427 This document and translations of it may be copied and furnished to 6428 others, and derivative works that comment on or otherwise explain it 6429 or assist in its implementation may be prepared, copied, published 6430 and distributed, in whole or in part, without restriction of any 6431 kind, provided that the above copyright notice and this paragraph are 6432 included on all such copies and derivative works. However, this 6433 document itself may not be modified in any way, such as by removing 6434 the copyright notice or references to the Internet Society or other 6435 Internet organizations, except as needed for the purpose of 6436 developing Internet standards in which case the procedures for 6437 copyrights defined in the Internet Standards process must be 6438 followed, or as required to translate it into languages other than 6439 English. 6441 The limited permissions granted above are perpetual and will not be 6442 revoked by the Internet Society or its successors or assigns. 6444 This document and the information contained herein is provided on an 6445 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 6446 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 6447 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 6448 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 6449 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6451 Table of Contents 6453 1 Introduction ........................................ 2 6454 1.1 Overview of SIP Functionality ....................... 2 6455 1.2 Terminology ......................................... 4 6456 1.3 Definitions ......................................... 4 6457 1.4 Overview of SIP Operation ........................... 7 6458 1.4.1 SIP Addressing ...................................... 7 6459 1.4.2 Locating a SIP Server ............................... 8 6460 1.4.3 SIP Transaction ..................................... 9 6461 1.4.4 SIP Invitation ...................................... 10 6462 1.4.5 Locating a User ..................................... 12 6463 1.4.6 Changing an Existing Session ........................ 13 6464 1.4.7 Registration Services ............................... 13 6465 1.5 Protocol Properties ................................. 13 6466 1.5.1 Minimal State ....................................... 13 6467 1.5.2 Lower-Layer-Protocol Neutral ........................ 13 6468 1.5.3 Text-Based .......................................... 15 6469 2 SIP Uniform Resource Locators ....................... 15 6470 3 SIP Message Overview ................................ 19 6471 4 Request ............................................. 21 6472 4.1 Request-Line ........................................ 21 6473 4.2 Methods ............................................. 21 6474 4.2.1 INVITE .............................................. 22 6475 4.2.2 ACK ................................................. 23 6476 4.2.3 OPTIONS ............................................. 24 6477 4.2.4 BYE ................................................. 24 6478 4.2.5 CANCEL .............................................. 25 6479 4.2.6 REGISTER ............................................ 26 6480 4.3 Request-URI ......................................... 28 6481 4.3.1 SIP Version ......................................... 29 6482 4.4 Option Tags ......................................... 29 6483 4.4.1 Registering New Option Tags with IANA ............... 30 6484 5 Response ............................................ 31 6485 5.1 Status-Line ......................................... 31 6486 5.1.1 Status Codes and Reason Phrases ..................... 31 6487 6 Header Field Definitions ............................ 33 6488 6.1 General Header Fields ............................... 35 6489 6.2 Entity Header Fields ................................ 36 6490 6.3 Request Header Fields ............................... 37 6491 6.4 Response Header Fields .............................. 38 6492 6.5 End-to-end and Hop-by-hop Headers ................... 38 6493 6.6 Header Field Format ................................. 38 6494 6.7 Accept .............................................. 39 6495 6.8 Accept-Encoding ..................................... 39 6496 6.9 Accept-Language ..................................... 39 6497 6.10 Allow ............................................... 40 6498 6.11 Authorization ....................................... 40 6499 6.12 Call-ID ............................................. 40 6500 6.13 Contact ............................................. 42 6501 6.14 Content-Encoding .................................... 45 6502 6.15 Content-Length ...................................... 45 6503 6.16 Content-Type ........................................ 46 6504 6.17 CSeq ................................................ 47 6505 6.18 Date ................................................ 48 6506 6.19 Encryption .......................................... 49 6507 6.20 Expires ............................................. 50 6508 6.21 From ................................................ 51 6509 6.22 Hide ................................................ 52 6510 6.23 Max-Forwards ........................................ 53 6511 6.24 Organization ........................................ 54 6512 6.25 Priority ............................................ 54 6513 6.26 Proxy-Authenticate .................................. 55 6514 6.27 Proxy-Authorization ................................. 56 6515 6.28 Proxy-Require ....................................... 56 6516 6.29 Record-Route ........................................ 56 6517 6.30 Require ............................................. 57 6518 6.31 Response-Key ........................................ 58 6519 6.32 Retry-After ......................................... 59 6520 6.33 Route ............................................... 59 6521 6.34 Server .............................................. 60 6522 6.35 Subject ............................................. 60 6523 6.36 Timestamp ........................................... 60 6524 6.37 To .................................................. 61 6525 6.38 Unsupported ......................................... 62 6526 6.39 User-Agent .......................................... 63 6527 6.40 Via ................................................. 63 6528 6.40.1 Requests ............................................ 63 6529 6.40.2 Receiver-tagged Via Header Fields ................... 64 6530 6.40.3 Responses ........................................... 64 6531 6.40.4 User Agent and Redirect Servers ..................... 65 6532 6.40.5 Syntax .............................................. 66 6533 6.41 Warning ............................................. 67 6534 6.42 WWW-Authenticate .................................... 69 6535 7 Status Code Definitions ............................. 69 6536 7.1 Informational 1xx ................................... 70 6537 7.1.1 100 Trying .......................................... 70 6538 7.1.2 180 Ringing ......................................... 70 6539 7.1.3 181 Call Is Being Forwarded ......................... 70 6540 7.1.4 182 Queued .......................................... 70 6541 7.2 Successful 2xx ...................................... 70 6542 7.2.1 200 OK .............................................. 71 6543 7.3 Redirection 3xx ..................................... 71 6544 7.3.1 300 Multiple Choices ................................ 71 6545 7.3.2 301 Moved Permanently ............................... 72 6546 7.3.3 302 Moved Temporarily ............................... 72 6547 7.3.4 305 Use Proxy ....................................... 72 6548 7.3.5 380 Alternative Service ............................. 72 6549 7.4 Request Failure 4xx ................................. 72 6550 7.4.1 400 Bad Request ..................................... 72 6551 7.4.2 401 Unauthorized .................................... 73 6552 7.4.3 402 Payment Required ................................ 73 6553 7.4.4 403 Forbidden ....................................... 73 6554 7.4.5 404 Not Found ....................................... 73 6555 7.4.6 405 Method Not Allowed .............................. 73 6556 7.4.7 406 Not Acceptable .................................. 73 6557 7.4.8 407 Proxy Authentication Required ................... 73 6558 7.4.9 408 Request Timeout ................................. 74 6559 7.4.10 409 Conflict ........................................ 74 6560 7.4.11 410 Gone ............................................ 74 6561 7.4.12 411 Length Required ................................. 74 6562 7.4.13 413 Request Entity Too Large ........................ 74 6563 7.4.14 414 Request-URI Too Long ............................ 74 6564 7.4.15 415 Unsupported Media Type .......................... 74 6565 7.4.16 420 Bad Extension ................................... 75 6566 7.4.17 480 Temporarily Unavailable ......................... 75 6567 7.4.18 481 Call Leg/Transaction Does Not Exist ............. 75 6568 7.4.19 482 Loop Detected ................................... 75 6569 7.4.20 483 Too Many Hops ................................... 75 6570 7.4.21 484 Address Incomplete .............................. 75 6571 7.4.22 485 Ambiguous ....................................... 76 6572 7.4.23 486 Busy Here ....................................... 76 6573 7.5 Server Failure 5xx .................................. 77 6574 7.5.1 500 Server Internal Error ........................... 77 6575 7.5.2 501 Not Implemented ................................. 77 6576 7.5.3 502 Bad Gateway ..................................... 77 6577 7.5.4 503 Service Unavailable ............................. 77 6578 7.5.5 504 Gateway Time-out ................................ 77 6579 7.5.6 505 Version Not Supported ........................... 77 6580 7.6 Global Failures 6xx ................................. 78 6581 7.6.1 600 Busy Everywhere ................................. 78 6582 7.6.2 603 Decline ......................................... 78 6583 7.6.3 604 Does Not Exist Anywhere ......................... 78 6584 7.6.4 606 Not Acceptable .................................. 78 6585 8 SIP Message Body .................................... 79 6586 8.1 Body Inclusion ...................................... 79 6587 8.2 Message Body Type ................................... 79 6588 8.3 Message Body Length ................................. 79 6589 9 Compact Form ........................................ 80 6590 10 Behavior of SIP Clients and Servers ................. 81 6591 10.1 General Remarks ..................................... 81 6592 10.1.1 Requests ............................................ 81 6593 10.1.2 Responses ........................................... 81 6594 10.2 Source Addresses, Destination Addresses and 6595 Connections .................................................... 82 6596 10.2.1 Unicast UDP ......................................... 82 6597 10.2.2 Multicast UDP ....................................... 82 6598 10.3 TCP ................................................. 83 6599 10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER 6600 Requests ....................................................... 84 6601 10.4.1 UDP ................................................. 84 6602 10.4.2 TCP ................................................. 85 6603 10.5 Reliability for INVITE Requests ..................... 85 6604 10.5.1 UDP ................................................. 86 6605 10.5.2 TCP ................................................. 87 6606 10.6 Reliability for ACK Requests ........................ 87 6607 10.7 ICMP Handling ....................................... 90 6608 11 Behavior of SIP User Agents ......................... 90 6609 11.1 Caller Issues Initial INVITE Request ................ 90 6610 11.2 Callee Issues Response .............................. 90 6611 11.3 Caller Receives Response to Initial Request ......... 90 6612 11.4 Caller or Callee Generate Subsequent Requests ....... 91 6613 11.5 Receiving Subsequent Requests ....................... 91 6614 12 Behavior of SIP Proxy and Redirect Servers .......... 92 6615 12.1 Redirect Server ..................................... 92 6616 12.2 User Agent Server ................................... 92 6617 12.3 Proxy Server ........................................ 92 6618 12.3.1 Proxying Requests ................................... 93 6619 12.3.2 Proxying Responses .................................. 93 6620 12.3.3 Stateless Proxy: Proxying Responses ................. 93 6621 12.3.4 Stateful Proxy: Receiving Requests .................. 93 6622 12.3.5 Stateful Proxy: Receiving ACKs ...................... 93 6623 12.3.6 Stateful Proxy: Receiving Responses ................. 94 6624 12.3.7 Stateless, Non-Forking Proxy ........................ 94 6625 12.4 Forking Proxy ....................................... 95 6626 13 Security Considerations ............................. 98 6627 13.1 Confidentiality and Privacy: Encryption ............. 99 6628 13.1.1 End-to-End Encryption ............................... 99 6629 13.1.2 Privacy of SIP Responses ............................ 101 6630 13.1.3 Encryption by Proxies ............................... 102 6631 13.1.4 Hop-by-Hop Encryption ............................... 102 6632 13.1.5 Via field encryption ................................ 102 6633 13.2 Message Integrity and Access Control: 6634 Authentication ................................................. 103 6635 13.2.1 Trusting responses .................................. 106 6636 13.3 Callee Privacy ...................................... 107 6637 13.4 Known Security Problems ............................. 107 6638 14 SIP Authentication using HTTP Basic and Digest 6639 Schemes ........................................................ 107 6640 14.1 Framework ........................................... 107 6641 14.2 Basic Authentication ................................ 108 6642 14.3 Digest Authentication ............................... 108 6643 14.4 Proxy-Authentication ................................ 109 6644 15 SIP Security Using PGP .............................. 109 6645 15.1 PGP Authentication Scheme ........................... 109 6646 15.1.1 The WWW-Authenticate Response Header ................ 110 6647 15.1.2 The Authorization Request Header .................... 111 6648 15.2 PGP Encryption Scheme ............................... 112 6649 15.3 Response-Key Header Field for PGP ................... 113 6650 16 Examples ............................................ 113 6651 16.1 Registration ........................................ 113 6652 16.2 Invitation to a Multicast Conference ................ 115 6653 16.2.1 Request ............................................. 115 6654 16.2.2 Response ............................................ 116 6655 16.3 Two-party Call ...................................... 117 6656 16.4 Terminating a Call .................................. 119 6657 16.5 Forking Proxy ....................................... 119 6658 16.6 Redirects ........................................... 123 6659 16.7 Negotiation ......................................... 125 6660 16.8 OPTIONS Request ..................................... 126 6661 A Minimal Implementation .............................. 127 6662 A.1 Client .............................................. 127 6663 A.2 Server .............................................. 128 6664 A.3 Header Processing ................................... 128 6665 B Usage of the Session Description Protocol (SDP) 6666 ................................................................ 128 6667 B.1 Configuring Media Streams ........................... 128 6668 B.2 Setting SDP Values for Unicast ...................... 130 6669 B.3 Multicast Operation ................................. 131 6670 B.4 Delayed Media Streams ............................... 132 6671 B.5 Putting Media Streams on Hold ....................... 132 6672 B.6 Subject and SDP "s=" Line ........................... 132 6673 B.7 The SDP "o=" Line ................................... 133 6674 C Summary of Augmented BNF ............................ 133 6675 C.1 Basic Rules ......................................... 135 6676 D Using SRV DNS Records ............................... 137 6677 E IANA Considerations ................................. 139 6678 F Changes in Version -12 .............................. 139 6679 G Acknowledgments ..................................... 140 6680 H Authors' Addresses .................................. 140 6681 I Bibliography ........................................ 141