--- a/tests/auto/qtextstream/rfc3261.txt Mon Mar 15 12:43:09 2010 +0200
+++ b/tests/auto/qtextstream/rfc3261.txt Thu Apr 08 14:19:33 2010 +0300
@@ -1,15067 +1,15067 @@
-
-
-
-
-
-
-Network Working Group J. Rosenberg
-Request for Comments: 3261 dynamicsoft
-Obsoletes: 2543 H. Schulzrinne
-Category: Standards Track Columbia U.
- G. Camarillo
- Ericsson
- A. Johnston
- WorldCom
- J. Peterson
- Neustar
- R. Sparks
- dynamicsoft
- M. Handley
- ICIR
- E. Schooler
- AT&T
- June 2002
-
- SIP: Session Initiation Protocol
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document describes Session Initiation Protocol (SIP), an
- application-layer control (signaling) protocol for creating,
- modifying, and terminating sessions with one or more participants.
- These sessions include Internet telephone calls, multimedia
- distribution, and multimedia conferences.
-
- SIP invitations used to create sessions carry session descriptions
- that allow participants to agree on a set of compatible media types.
- SIP makes use of elements called proxy servers to help route requests
- to the user's current location, authenticate and authorize users for
- services, implement provider call-routing policies, and provide
- features to users. SIP also provides a registration function that
- allows users to upload their current locations for use by proxy
- servers. SIP runs on top of several different transport protocols.
-
-
-
-Rosenberg, et. al. Standards Track [Page 1]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Table of Contents
-
- 1 Introduction ........................................ 8
- 2 Overview of SIP Functionality ....................... 9
- 3 Terminology ......................................... 10
- 4 Overview of Operation ............................... 10
- 5 Structure of the Protocol ........................... 18
- 6 Definitions ......................................... 20
- 7 SIP Messages ........................................ 26
- 7.1 Requests ............................................ 27
- 7.2 Responses ........................................... 28
- 7.3 Header Fields ....................................... 29
- 7.3.1 Header Field Format ................................. 30
- 7.3.2 Header Field Classification ......................... 32
- 7.3.3 Compact Form ........................................ 32
- 7.4 Bodies .............................................. 33
- 7.4.1 Message Body Type ................................... 33
- 7.4.2 Message Body Length ................................. 33
- 7.5 Framing SIP Messages ................................ 34
- 8 General User Agent Behavior ......................... 34
- 8.1 UAC Behavior ........................................ 35
- 8.1.1 Generating the Request .............................. 35
- 8.1.1.1 Request-URI ......................................... 35
- 8.1.1.2 To .................................................. 36
- 8.1.1.3 From ................................................ 37
- 8.1.1.4 Call-ID ............................................. 37
- 8.1.1.5 CSeq ................................................ 38
- 8.1.1.6 Max-Forwards ........................................ 38
- 8.1.1.7 Via ................................................. 39
- 8.1.1.8 Contact ............................................. 40
- 8.1.1.9 Supported and Require ............................... 40
- 8.1.1.10 Additional Message Components ....................... 41
- 8.1.2 Sending the Request ................................. 41
- 8.1.3 Processing Responses ................................ 42
- 8.1.3.1 Transaction Layer Errors ............................ 42
- 8.1.3.2 Unrecognized Responses .............................. 42
- 8.1.3.3 Vias ................................................ 43
- 8.1.3.4 Processing 3xx Responses ............................ 43
- 8.1.3.5 Processing 4xx Responses ............................ 45
- 8.2 UAS Behavior ........................................ 46
- 8.2.1 Method Inspection ................................... 46
- 8.2.2 Header Inspection ................................... 46
- 8.2.2.1 To and Request-URI .................................. 46
- 8.2.2.2 Merged Requests ..................................... 47
- 8.2.2.3 Require ............................................. 47
- 8.2.3 Content Processing .................................. 48
- 8.2.4 Applying Extensions ................................. 49
- 8.2.5 Processing the Request .............................. 49
-
-
-
-Rosenberg, et. al. Standards Track [Page 2]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 8.2.6 Generating the Response ............................. 49
- 8.2.6.1 Sending a Provisional Response ...................... 49
- 8.2.6.2 Headers and Tags .................................... 50
- 8.2.7 Stateless UAS Behavior .............................. 50
- 8.3 Redirect Servers .................................... 51
- 9 Canceling a Request ................................. 53
- 9.1 Client Behavior ..................................... 53
- 9.2 Server Behavior ..................................... 55
- 10 Registrations ....................................... 56
- 10.1 Overview ............................................ 56
- 10.2 Constructing the REGISTER Request ................... 57
- 10.2.1 Adding Bindings ..................................... 59
- 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60
- 10.2.1.2 Preferences among Contact Addresses ................. 61
- 10.2.2 Removing Bindings ................................... 61
- 10.2.3 Fetching Bindings ................................... 61
- 10.2.4 Refreshing Bindings ................................. 61
- 10.2.5 Setting the Internal Clock .......................... 62
- 10.2.6 Discovering a Registrar ............................. 62
- 10.2.7 Transmitting a Request .............................. 62
- 10.2.8 Error Responses ..................................... 63
- 10.3 Processing REGISTER Requests ........................ 63
- 11 Querying for Capabilities ........................... 66
- 11.1 Construction of OPTIONS Request ..................... 67
- 11.2 Processing of OPTIONS Request ....................... 68
- 12 Dialogs ............................................. 69
- 12.1 Creation of a Dialog ................................ 70
- 12.1.1 UAS behavior ........................................ 70
- 12.1.2 UAC Behavior ........................................ 71
- 12.2 Requests within a Dialog ............................ 72
- 12.2.1 UAC Behavior ........................................ 73
- 12.2.1.1 Generating the Request .............................. 73
- 12.2.1.2 Processing the Responses ............................ 75
- 12.2.2 UAS Behavior ........................................ 76
- 12.3 Termination of a Dialog ............................. 77
- 13 Initiating a Session ................................ 77
- 13.1 Overview ............................................ 77
- 13.2 UAC Processing ...................................... 78
- 13.2.1 Creating the Initial INVITE ......................... 78
- 13.2.2 Processing INVITE Responses ......................... 81
- 13.2.2.1 1xx Responses ....................................... 81
- 13.2.2.2 3xx Responses ....................................... 81
- 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81
- 13.2.2.4 2xx Responses ....................................... 82
- 13.3 UAS Processing ...................................... 83
- 13.3.1 Processing of the INVITE ............................ 83
- 13.3.1.1 Progress ............................................ 84
- 13.3.1.2 The INVITE is Redirected ............................ 84
-
-
-
-Rosenberg, et. al. Standards Track [Page 3]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 13.3.1.3 The INVITE is Rejected .............................. 85
- 13.3.1.4 The INVITE is Accepted .............................. 85
- 14 Modifying an Existing Session ....................... 86
- 14.1 UAC Behavior ........................................ 86
- 14.2 UAS Behavior ........................................ 88
- 15 Terminating a Session ............................... 89
- 15.1 Terminating a Session with a BYE Request ............ 90
- 15.1.1 UAC Behavior ........................................ 90
- 15.1.2 UAS Behavior ........................................ 91
- 16 Proxy Behavior ...................................... 91
- 16.1 Overview ............................................ 91
- 16.2 Stateful Proxy ...................................... 92
- 16.3 Request Validation .................................. 94
- 16.4 Route Information Preprocessing ..................... 96
- 16.5 Determining Request Targets ......................... 97
- 16.6 Request Forwarding .................................. 99
- 16.7 Response Processing ................................. 107
- 16.8 Processing Timer C .................................. 114
- 16.9 Handling Transport Errors ........................... 115
- 16.10 CANCEL Processing ................................... 115
- 16.11 Stateless Proxy ..................................... 116
- 16.12 Summary of Proxy Route Processing ................... 118
- 16.12.1 Examples ............................................ 118
- 16.12.1.1 Basic SIP Trapezoid ................................. 118
- 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120
- 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121
- 17 Transactions ........................................ 122
- 17.1 Client Transaction .................................. 124
- 17.1.1 INVITE Client Transaction ........................... 125
- 17.1.1.1 Overview of INVITE Transaction ...................... 125
- 17.1.1.2 Formal Description .................................. 125
- 17.1.1.3 Construction of the ACK Request ..................... 129
- 17.1.2 Non-INVITE Client Transaction ....................... 130
- 17.1.2.1 Overview of the non-INVITE Transaction .............. 130
- 17.1.2.2 Formal Description .................................. 131
- 17.1.3 Matching Responses to Client Transactions ........... 132
- 17.1.4 Handling Transport Errors ........................... 133
- 17.2 Server Transaction .................................. 134
- 17.2.1 INVITE Server Transaction ........................... 134
- 17.2.2 Non-INVITE Server Transaction ....................... 137
- 17.2.3 Matching Requests to Server Transactions ............ 138
- 17.2.4 Handling Transport Errors ........................... 141
- 18 Transport ........................................... 141
- 18.1 Clients ............................................. 142
- 18.1.1 Sending Requests .................................... 142
- 18.1.2 Receiving Responses ................................. 144
- 18.2 Servers ............................................. 145
- 18.2.1 Receiving Requests .................................. 145
-
-
-
-Rosenberg, et. al. Standards Track [Page 4]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 18.2.2 Sending Responses ................................... 146
- 18.3 Framing ............................................. 147
- 18.4 Error Handling ...................................... 147
- 19 Common Message Components ........................... 147
- 19.1 SIP and SIPS Uniform Resource Indicators ............ 148
- 19.1.1 SIP and SIPS URI Components ......................... 148
- 19.1.2 Character Escaping Requirements ..................... 152
- 19.1.3 Example SIP and SIPS URIs ........................... 153
- 19.1.4 URI Comparison ...................................... 153
- 19.1.5 Forming Requests from a URI ......................... 156
- 19.1.6 Relating SIP URIs and tel URLs ...................... 157
- 19.2 Option Tags ......................................... 158
- 19.3 Tags ................................................ 159
- 20 Header Fields ....................................... 159
- 20.1 Accept .............................................. 161
- 20.2 Accept-Encoding ..................................... 163
- 20.3 Accept-Language ..................................... 164
- 20.4 Alert-Info .......................................... 164
- 20.5 Allow ............................................... 165
- 20.6 Authentication-Info ................................. 165
- 20.7 Authorization ....................................... 165
- 20.8 Call-ID ............................................. 166
- 20.9 Call-Info ........................................... 166
- 20.10 Contact ............................................. 167
- 20.11 Content-Disposition ................................. 168
- 20.12 Content-Encoding .................................... 169
- 20.13 Content-Language .................................... 169
- 20.14 Content-Length ...................................... 169
- 20.15 Content-Type ........................................ 170
- 20.16 CSeq ................................................ 170
- 20.17 Date ................................................ 170
- 20.18 Error-Info .......................................... 171
- 20.19 Expires ............................................. 171
- 20.20 From ................................................ 172
- 20.21 In-Reply-To ......................................... 172
- 20.22 Max-Forwards ........................................ 173
- 20.23 Min-Expires ......................................... 173
- 20.24 MIME-Version ........................................ 173
- 20.25 Organization ........................................ 174
- 20.26 Priority ............................................ 174
- 20.27 Proxy-Authenticate .................................. 174
- 20.28 Proxy-Authorization ................................. 175
- 20.29 Proxy-Require ....................................... 175
- 20.30 Record-Route ........................................ 175
- 20.31 Reply-To ............................................ 176
- 20.32 Require ............................................. 176
- 20.33 Retry-After ......................................... 176
- 20.34 Route ............................................... 177
-
-
-
-Rosenberg, et. al. Standards Track [Page 5]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 20.35 Server .............................................. 177
- 20.36 Subject ............................................. 177
- 20.37 Supported ........................................... 178
- 20.38 Timestamp ........................................... 178
- 20.39 To .................................................. 178
- 20.40 Unsupported ......................................... 179
- 20.41 User-Agent .......................................... 179
- 20.42 Via ................................................. 179
- 20.43 Warning ............................................. 180
- 20.44 WWW-Authenticate .................................... 182
- 21 Response Codes ...................................... 182
- 21.1 Provisional 1xx ..................................... 182
- 21.1.1 100 Trying .......................................... 183
- 21.1.2 180 Ringing ......................................... 183
- 21.1.3 181 Call Is Being Forwarded ......................... 183
- 21.1.4 182 Queued .......................................... 183
- 21.1.5 183 Session Progress ................................ 183
- 21.2 Successful 2xx ...................................... 183
- 21.2.1 200 OK .............................................. 183
- 21.3 Redirection 3xx ..................................... 184
- 21.3.1 300 Multiple Choices ................................ 184
- 21.3.2 301 Moved Permanently ............................... 184
- 21.3.3 302 Moved Temporarily ............................... 184
- 21.3.4 305 Use Proxy ....................................... 185
- 21.3.5 380 Alternative Service ............................. 185
- 21.4 Request Failure 4xx ................................. 185
- 21.4.1 400 Bad Request ..................................... 185
- 21.4.2 401 Unauthorized .................................... 185
- 21.4.3 402 Payment Required ................................ 186
- 21.4.4 403 Forbidden ....................................... 186
- 21.4.5 404 Not Found ....................................... 186
- 21.4.6 405 Method Not Allowed .............................. 186
- 21.4.7 406 Not Acceptable .................................. 186
- 21.4.8 407 Proxy Authentication Required ................... 186
- 21.4.9 408 Request Timeout ................................. 186
- 21.4.10 410 Gone ............................................ 187
- 21.4.11 413 Request Entity Too Large ........................ 187
- 21.4.12 414 Request-URI Too Long ............................ 187
- 21.4.13 415 Unsupported Media Type .......................... 187
- 21.4.14 416 Unsupported URI Scheme .......................... 187
- 21.4.15 420 Bad Extension ................................... 187
- 21.4.16 421 Extension Required .............................. 188
- 21.4.17 423 Interval Too Brief .............................. 188
- 21.4.18 480 Temporarily Unavailable ......................... 188
- 21.4.19 481 Call/Transaction Does Not Exist ................. 188
- 21.4.20 482 Loop Detected ................................... 188
- 21.4.21 483 Too Many Hops ................................... 189
- 21.4.22 484 Address Incomplete .............................. 189
-
-
-
-Rosenberg, et. al. Standards Track [Page 6]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 21.4.23 485 Ambiguous ....................................... 189
- 21.4.24 486 Busy Here ....................................... 189
- 21.4.25 487 Request Terminated .............................. 190
- 21.4.26 488 Not Acceptable Here ............................. 190
- 21.4.27 491 Request Pending ................................. 190
- 21.4.28 493 Undecipherable .................................. 190
- 21.5 Server Failure 5xx .................................. 190
- 21.5.1 500 Server Internal Error ........................... 190
- 21.5.2 501 Not Implemented ................................. 191
- 21.5.3 502 Bad Gateway ..................................... 191
- 21.5.4 503 Service Unavailable ............................. 191
- 21.5.5 504 Server Time-out ................................. 191
- 21.5.6 505 Version Not Supported ........................... 192
- 21.5.7 513 Message Too Large ............................... 192
- 21.6 Global Failures 6xx ................................. 192
- 21.6.1 600 Busy Everywhere ................................. 192
- 21.6.2 603 Decline ......................................... 192
- 21.6.3 604 Does Not Exist Anywhere ......................... 192
- 21.6.4 606 Not Acceptable .................................. 192
- 22 Usage of HTTP Authentication ........................ 193
- 22.1 Framework ........................................... 193
- 22.2 User-to-User Authentication ......................... 195
- 22.3 Proxy-to-User Authentication ........................ 197
- 22.4 The Digest Authentication Scheme .................... 199
- 23 S/MIME .............................................. 201
- 23.1 S/MIME Certificates ................................. 201
- 23.2 S/MIME Key Exchange ................................. 202
- 23.3 Securing MIME bodies ................................ 205
- 23.4 SIP Header Privacy and Integrity using S/MIME:
- Tunneling SIP ....................................... 207
- 23.4.1 Integrity and Confidentiality Properties of SIP
- Headers ............................................. 207
- 23.4.1.1 Integrity ........................................... 207
- 23.4.1.2 Confidentiality ..................................... 208
- 23.4.2 Tunneling Integrity and Authentication .............. 209
- 23.4.3 Tunneling Encryption ................................ 211
- 24 Examples ............................................ 213
- 24.1 Registration ........................................ 213
- 24.2 Session Setup ....................................... 214
- 25 Augmented BNF for the SIP Protocol .................. 219
- 25.1 Basic Rules ......................................... 219
- 26 Security Considerations: Threat Model and Security
- Usage Recommendations ............................... 232
- 26.1 Attacks and Threat Models ........................... 233
- 26.1.1 Registration Hijacking .............................. 233
- 26.1.2 Impersonating a Server .............................. 234
- 26.1.3 Tampering with Message Bodies ....................... 235
- 26.1.4 Tearing Down Sessions ............................... 235
-
-
-
-Rosenberg, et. al. Standards Track [Page 7]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 26.1.5 Denial of Service and Amplification ................. 236
- 26.2 Security Mechanisms ................................. 237
- 26.2.1 Transport and Network Layer Security ................ 238
- 26.2.2 SIPS URI Scheme ..................................... 239
- 26.2.3 HTTP Authentication ................................. 240
- 26.2.4 S/MIME .............................................. 240
- 26.3 Implementing Security Mechanisms .................... 241
- 26.3.1 Requirements for Implementers of SIP ................ 241
- 26.3.2 Security Solutions .................................. 242
- 26.3.2.1 Registration ........................................ 242
- 26.3.2.2 Interdomain Requests ................................ 243
- 26.3.2.3 Peer-to-Peer Requests ............................... 245
- 26.3.2.4 DoS Protection ...................................... 246
- 26.4 Limitations ......................................... 247
- 26.4.1 HTTP Digest ......................................... 247
- 26.4.2 S/MIME .............................................. 248
- 26.4.3 TLS ................................................. 249
- 26.4.4 SIPS URIs ........................................... 249
- 26.5 Privacy ............................................. 251
- 27 IANA Considerations ................................. 252
- 27.1 Option Tags ......................................... 252
- 27.2 Warn-Codes .......................................... 252
- 27.3 Header Field Names .................................. 253
- 27.4 Method and Response Codes ........................... 253
- 27.5 The "message/sip" MIME type. ....................... 254
- 27.6 New Content-Disposition Parameter Registrations ..... 255
- 28 Changes From RFC 2543 ............................... 255
- 28.1 Major Functional Changes ............................ 255
- 28.2 Minor Functional Changes ............................ 260
- 29 Normative References ................................ 261
- 30 Informative References .............................. 262
- A Table of Timer Values ............................... 265
- Acknowledgments ................................................ 266
- Authors' Addresses ............................................. 267
- Full Copyright Statement ....................................... 269
-
-1 Introduction
-
- There are many applications of the Internet that require the creation
- and management of a session, where a session is considered an
- exchange of data between an association of participants. The
- implementation of these applications is complicated by the practices
- of participants: users may move between endpoints, they may be
- addressable by multiple names, and they may communicate in several
- different media - sometimes simultaneously. Numerous protocols have
- been authored that carry various forms of real-time multimedia
- session data such as voice, video, or text messages. The Session
- Initiation Protocol (SIP) works in concert with these protocols by
-
-
-
-Rosenberg, et. al. Standards Track [Page 8]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- enabling Internet endpoints (called user agents) to discover one
- another and to agree on a characterization of a session they would
- like to share. For locating prospective session participants, and
- for other functions, SIP enables the creation of an infrastructure of
- network hosts (called proxy servers) to which user agents can send
- registrations, invitations to sessions, and other requests. SIP is
- an agile, general-purpose tool for creating, modifying, and
- terminating sessions that works independently of underlying transport
- protocols and without dependency on the type of session that is being
- established.
-
-2 Overview of SIP Functionality
-
- SIP is an application-layer control protocol that can establish,
- modify, and terminate multimedia sessions (conferences) such as
- Internet telephony calls. SIP can also invite participants to
- already existing sessions, such as multicast conferences. Media can
- be added to (and removed from) an existing session. SIP
- transparently supports name mapping and redirection services, which
- supports personal mobility [27] - users can maintain a single
- externally visible identifier regardless of their network location.
-
- SIP supports five facets of establishing and terminating multimedia
- communications:
-
- User location: determination of the end system to be used for
- communication;
-
- User availability: determination of the willingness of the called
- party to engage in communications;
-
- User capabilities: determination of the media and media parameters
- to be used;
-
- Session setup: "ringing", establishment of session parameters at
- both called and calling party;
-
- Session management: including transfer and termination of
- sessions, modifying session parameters, and invoking
- services.
-
- SIP is not a vertically integrated communications system. SIP is
- rather a component that can be used with other IETF protocols to
- build a complete multimedia architecture. Typically, these
- architectures will include protocols such as the Real-time Transport
- Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
- providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
- 2326 [29]) for controlling delivery of streaming media, the Media
-
-
-
-Rosenberg, et. al. Standards Track [Page 9]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
- gateways to the Public Switched Telephone Network (PSTN), and the
- Session Description Protocol (SDP) (RFC 2327 [1]) for describing
- multimedia sessions. Therefore, SIP should be used in conjunction
- with other protocols in order to provide complete services to the
- users. However, the basic functionality and operation of SIP does
- not depend on any of these protocols.
-
- SIP does not provide services. Rather, SIP provides primitives that
- can be used to implement different services. For example, SIP can
- locate a user and deliver an opaque object to his current location.
- If this primitive is used to deliver a session description written in
- SDP, for instance, the endpoints can agree on the parameters of a
- session. If the same primitive is used to deliver a photo of the
- caller as well as the session description, a "caller ID" service can
- be easily implemented. As this example shows, a single primitive is
- typically used to provide several different services.
-
- SIP does not offer conference control services such as floor control
- or voting and does not prescribe how a conference is to be managed.
- SIP can be used to initiate a session that uses some other conference
- control protocol. Since SIP messages and the sessions they establish
- can pass through entirely different networks, SIP cannot, and does
- not, provide any kind of network resource reservation capabilities.
-
- The nature of the services provided make security particularly
- important. To that end, SIP provides a suite of security services,
- which include denial-of-service prevention, authentication (both user
- to user and proxy to user), integrity protection, and encryption and
- privacy services.
-
- SIP works with both IPv4 and IPv6.
-
-3 Terminology
-
- In this document, the key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
- RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
- described in BCP 14, RFC 2119 [2] and indicate requirement levels for
- compliant SIP implementations.
-
-4 Overview of Operation
-
- This section introduces the basic operations of SIP using simple
- examples. This section is tutorial in nature and does not contain
- any normative statements.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 10]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The first example shows the basic functions of SIP: location of an
- end point, signal of a desire to communicate, negotiation of session
- parameters to establish the session, and teardown of the session once
- established.
-
- Figure 1 shows a typical example of a SIP message exchange between
- two users, Alice and Bob. (Each message is labeled with the letter
- "F" and a number for reference by the text.) In this example, Alice
- uses a SIP application on her PC (referred to as a softphone) to call
- Bob on his SIP phone over the Internet. Also shown are two SIP proxy
- servers that act on behalf of Alice and Bob to facilitate the session
- establishment. This typical arrangement is often referred to as the
- "SIP trapezoid" as shown by the geometric shape of the dotted lines
- in Figure 1.
-
- Alice "calls" Bob using his SIP identity, a type of Uniform Resource
- Identifier (URI) called a SIP URI. SIP URIs are defined in Section
- 19.1. It has a similar form to an email address, typically
- containing a username and a host name. In this case, it is
- sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP
- service provider. Alice has a SIP URI of sip:alice@atlanta.com.
- Alice might have typed in Bob's URI or perhaps clicked on a hyperlink
- or an entry in an address book. SIP also provides a secure URI,
- called a SIPS URI. An example would be sips:bob@biloxi.com. A call
- made to a SIPS URI guarantees that secure, encrypted transport
- (namely TLS) is used to carry all SIP messages from the caller to the
- domain of the callee. From there, the request is sent securely to
- the callee, but with security mechanisms that depend on the policy of
- the domain of the callee.
-
- SIP is based on an HTTP-like request/response transaction model.
- Each transaction consists of a request that invokes a particular
- method, or function, on the server and at least one response. In
- this example, the transaction begins with Alice's softphone sending
- an INVITE request addressed to Bob's SIP URI. INVITE is an example
- of a SIP method that specifies the action that the requestor (Alice)
- wants the server (Bob) to take. The INVITE request contains a number
- of header fields. Header fields are named attributes that provide
- additional information about a message. The ones present in an
- INVITE include a unique identifier for the call, the destination
- address, Alice's address, and information about the type of session
- that Alice wishes to establish with Bob. The INVITE (message F1 in
- Figure 1) might look like this:
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 11]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- atlanta.com . . . biloxi.com
- . proxy proxy .
- . .
- Alice's . . . . . . . . . . . . . . . . . . . . Bob's
- softphone SIP Phone
- | | | |
- | INVITE F1 | | |
- |--------------->| INVITE F2 | |
- | 100 Trying F3 |--------------->| INVITE F4 |
- |<---------------| 100 Trying F5 |--------------->|
- | |<-------------- | 180 Ringing F6 |
- | | 180 Ringing F7 |<---------------|
- | 180 Ringing F8 |<---------------| 200 OK F9 |
- |<---------------| 200 OK F10 |<---------------|
- | 200 OK F11 |<---------------| |
- |<---------------| | |
- | ACK F12 |
- |------------------------------------------------->|
- | Media Session |
- |<================================================>|
- | BYE F13 |
- |<-------------------------------------------------|
- | 200 OK F14 |
- |------------------------------------------------->|
- | |
-
- Figure 1: SIP session setup example with SIP trapezoid
-
- INVITE sip:bob@biloxi.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
- Max-Forwards: 70
- To: Bob <sip:bob@biloxi.com>
- From: Alice <sip:alice@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710@pc33.atlanta.com
- CSeq: 314159 INVITE
- Contact: <sip:alice@pc33.atlanta.com>
- Content-Type: application/sdp
- Content-Length: 142
-
- (Alice's SDP not shown)
-
- The first line of the text-encoded message contains the method name
- (INVITE). The lines that follow are a list of header fields. This
- example contains a minimum required set. The header fields are
- briefly described below:
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 12]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Via contains the address (pc33.atlanta.com) at which Alice is
- expecting to receive responses to this request. It also contains a
- branch parameter that identifies this transaction.
-
- To contains a display name (Bob) and a SIP or SIPS URI
- (sip:bob@biloxi.com) towards which the request was originally
- directed. Display names are described in RFC 2822 [3].
-
- From also contains a display name (Alice) and a SIP or SIPS URI
- (sip:alice@atlanta.com) that indicate the originator of the request.
- This header field also has a tag parameter containing a random string
- (1928301774) that was added to the URI by the softphone. It is used
- for identification purposes.
-
- Call-ID contains a globally unique identifier for this call,
- generated by the combination of a random string and the softphone's
- host name or IP address. The combination of the To tag, From tag,
- and Call-ID completely defines a peer-to-peer SIP relationship
- between Alice and Bob and is referred to as a dialog.
-
- CSeq or Command Sequence contains an integer and a method name. The
- CSeq number is incremented for each new request within a dialog and
- is a traditional sequence number.
-
- Contact contains a SIP or SIPS URI that represents a direct route to
- contact Alice, usually composed of a username at a fully qualified
- domain name (FQDN). While an FQDN is preferred, many end systems do
- not have registered domain names, so IP addresses are permitted.
- While the Via header field tells other elements where to send the
- response, the Contact header field tells other elements where to send
- future requests.
-
- Max-Forwards serves to limit the number of hops a request can make on
- the way to its destination. It consists of an integer that is
- decremented by one at each hop.
-
- Content-Type contains a description of the message body (not shown).
-
- Content-Length contains an octet (byte) count of the message body.
-
- The complete set of SIP header fields is defined in Section 20.
-
- The details of the session, such as the type of media, codec, or
- sampling rate, are not described using SIP. Rather, the body of a
- SIP message contains a description of the session, encoded in some
- other protocol format. One such format is the Session Description
- Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 13]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- example) is carried by the SIP message in a way that is analogous to
- a document attachment being carried by an email message, or a web
- page being carried in an HTTP message.
-
- Since the softphone does not know the location of Bob or the SIP
- server in the biloxi.com domain, the softphone sends the INVITE to
- the SIP server that serves Alice's domain, atlanta.com. The address
- of the atlanta.com SIP server could have been configured in Alice's
- softphone, or it could have been discovered by DHCP, for example.
-
- The atlanta.com SIP server is a type of SIP server known as a proxy
- server. A proxy server receives SIP requests and forwards them on
- behalf of the requestor. In this example, the proxy server receives
- the INVITE request and sends a 100 (Trying) response back to Alice's
- softphone. The 100 (Trying) response indicates that the INVITE has
- been received and that the proxy is working on her behalf to route
- the INVITE to the destination. Responses in SIP use a three-digit
- code followed by a descriptive phrase. This response contains the
- same To, From, Call-ID, CSeq and branch parameter in the Via as the
- INVITE, which allows Alice's softphone to correlate this response to
- the sent INVITE. The atlanta.com proxy server locates the proxy
- server at biloxi.com, possibly by performing a particular type of DNS
- (Domain Name Service) lookup to find the SIP server that serves the
- biloxi.com domain. This is described in [4]. As a result, it
- obtains the IP address of the biloxi.com proxy server and forwards,
- or proxies, the INVITE request there. Before forwarding the request,
- the atlanta.com proxy server adds an additional Via header field
- value that contains its own address (the INVITE already contains
- Alice's address in the first Via). The biloxi.com proxy server
- receives the INVITE and responds with a 100 (Trying) response back to
- the atlanta.com proxy server to indicate that it has received the
- INVITE and is processing the request. The proxy server consults a
- database, generically called a location service, that contains the
- current IP address of Bob. (We shall see in the next section how
- this database can be populated.) The biloxi.com proxy server adds
- another Via header field value with its own address to the INVITE and
- proxies it to Bob's SIP phone.
-
- Bob's SIP phone receives the INVITE and alerts Bob to the incoming
- call from Alice so that Bob can decide whether to answer the call,
- that is, Bob's phone rings. Bob's SIP phone indicates this in a 180
- (Ringing) response, which is routed back through the two proxies in
- the reverse direction. Each proxy uses the Via header field to
- determine where to send the response and removes its own address from
- the top. As a result, although DNS and location service lookups were
- required to route the initial INVITE, the 180 (Ringing) response can
- be returned to the caller without lookups or without state being
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 14]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- maintained in the proxies. This also has the desirable property that
- each proxy that sees the INVITE will also see all responses to the
- INVITE.
-
- When Alice's softphone receives the 180 (Ringing) response, it passes
- this information to Alice, perhaps using an audio ringback tone or by
- displaying a message on Alice's screen.
-
- In this example, Bob decides to answer the call. When he picks up
- the handset, his SIP phone sends a 200 (OK) response to indicate that
- the call has been answered. The 200 (OK) contains a message body
- with the SDP media description of the type of session that Bob is
- willing to establish with Alice. As a result, there is a two-phase
- exchange of SDP messages: Alice sent one to Bob, and Bob sent one
- back to Alice. This two-phase exchange provides basic negotiation
- capabilities and is based on a simple offer/answer model of SDP
- exchange. If Bob did not wish to answer the call or was busy on
- another call, an error response would have been sent instead of the
- 200 (OK), which would have resulted in no media session being
- established. The complete list of SIP response codes is in Section
- 21. The 200 (OK) (message F9 in Figure 1) might look like this as
- Bob sends it out:
-
- SIP/2.0 200 OK
- Via: SIP/2.0/UDP server10.biloxi.com
- ;branch=z9hG4bKnashds8;received=192.0.2.3
- Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
- ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
- Via: SIP/2.0/UDP pc33.atlanta.com
- ;branch=z9hG4bK776asdhds ;received=192.0.2.1
- To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
- From: Alice <sip:alice@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710@pc33.atlanta.com
- CSeq: 314159 INVITE
- Contact: <sip:bob@192.0.2.4>
- Content-Type: application/sdp
- Content-Length: 131
-
- (Bob's SDP not shown)
-
- The first line of the response contains the response code (200) and
- the reason phrase (OK). The remaining lines contain header fields.
- The Via, To, From, Call-ID, and CSeq header fields are copied from
- the INVITE request. (There are three Via header field values - one
- added by Alice's SIP phone, one added by the atlanta.com proxy, and
- one added by the biloxi.com proxy.) Bob's SIP phone has added a tag
- parameter to the To header field. This tag will be incorporated by
- both endpoints into the dialog and will be included in all future
-
-
-
-Rosenberg, et. al. Standards Track [Page 15]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- requests and responses in this call. The Contact header field
- contains a URI at which Bob can be directly reached at his SIP phone.
- The Content-Type and Content-Length refer to the message body (not
- shown) that contains Bob's SDP media information.
-
- In addition to DNS and location service lookups shown in this
- example, proxy servers can make flexible "routing decisions" to
- decide where to send a request. For example, if Bob's SIP phone
- returned a 486 (Busy Here) response, the biloxi.com proxy server
- could proxy the INVITE to Bob's voicemail server. A proxy server can
- also send an INVITE to a number of locations at the same time. This
- type of parallel search is known as forking.
-
- In this case, the 200 (OK) is routed back through the two proxies and
- is received by Alice's softphone, which then stops the ringback tone
- and indicates that the call has been answered. Finally, Alice's
- softphone sends an acknowledgement message, ACK, to Bob's SIP phone
- to confirm the reception of the final response (200 (OK)). In this
- example, the ACK is sent directly from Alice's softphone to Bob's SIP
- phone, bypassing the two proxies. This occurs because the endpoints
- have learned each other's address from the Contact header fields
- through the INVITE/200 (OK) exchange, which was not known when the
- initial INVITE was sent. The lookups performed by the two proxies
- are no longer needed, so the proxies drop out of the call flow. This
- completes the INVITE/200/ACK three-way handshake used to establish
- SIP sessions. Full details on session setup are in Section 13.
-
- Alice and Bob's media session has now begun, and they send media
- packets using the format to which they agreed in the exchange of SDP.
- In general, the end-to-end media packets take a different path from
- the SIP signaling messages.
-
- During the session, either Alice or Bob may decide to change the
- characteristics of the media session. This is accomplished by
- sending a re-INVITE containing a new media description. This re-
- INVITE references the existing dialog so that the other party knows
- that it is to modify an existing session instead of establishing a
- new session. The other party sends a 200 (OK) to accept the change.
- The requestor responds to the 200 (OK) with an ACK. If the other
- party does not accept the change, he sends an error response such as
- 488 (Not Acceptable Here), which also receives an ACK. However, the
- failure of the re-INVITE does not cause the existing call to fail -
- the session continues using the previously negotiated
- characteristics. Full details on session modification are in Section
- 14.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 16]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- At the end of the call, Bob disconnects (hangs up) first and
- generates a BYE message. This BYE is routed directly to Alice's
- softphone, again bypassing the proxies. Alice confirms receipt of
- the BYE with a 200 (OK) response, which terminates the session and
- the BYE transaction. No ACK is sent - an ACK is only sent in
- response to a response to an INVITE request. The reasons for this
- special handling for INVITE will be discussed later, but relate to
- the reliability mechanisms in SIP, the length of time it can take for
- a ringing phone to be answered, and forking. For this reason,
- request handling in SIP is often classified as either INVITE or non-
- INVITE, referring to all other methods besides INVITE. Full details
- on session termination are in Section 15.
-
- Section 24.2 describes the messages shown in Figure 1 in full.
-
- In some cases, it may be useful for proxies in the SIP signaling path
- to see all the messaging between the endpoints for the duration of
- the session. For example, if the biloxi.com proxy server wished to
- remain in the SIP messaging path beyond the initial INVITE, it would
- add to the INVITE a required routing header field known as Record-
- Route that contained a URI resolving to the hostname or IP address of
- the proxy. This information would be received by both Bob's SIP
- phone and (due to the Record-Route header field being passed back in
- the 200 (OK)) Alice's softphone and stored for the duration of the
- dialog. The biloxi.com proxy server would then receive and proxy the
- ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently
- decide to receive subsequent messages, and those messages will pass
- through all proxies that elect to receive it. This capability is
- frequently used for proxies that are providing mid-call features.
-
- Registration is another common operation in SIP. Registration is one
- way that the biloxi.com server can learn the current location of Bob.
- Upon initialization, and at periodic intervals, Bob's SIP phone sends
- REGISTER messages to a server in the biloxi.com domain known as a SIP
- registrar. The REGISTER messages associate Bob's SIP or SIPS URI
- (sip:bob@biloxi.com) with the machine into which he is currently
- logged (conveyed as a SIP or SIPS URI in the Contact header field).
- The registrar writes this association, also called a binding, to a
- database, called the location service, where it can be used by the
- proxy in the biloxi.com domain. Often, a registrar server for a
- domain is co-located with the proxy for that domain. It is an
- important concept that the distinction between types of SIP servers
- is logical, not physical.
-
- Bob is not limited to registering from a single device. For example,
- both his SIP phone at home and the one in the office could send
- registrations. This information is stored together in the location
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 17]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- service and allows a proxy to perform various types of searches to
- locate Bob. Similarly, more than one user can be registered on a
- single device at the same time.
-
- The location service is just an abstract concept. It generally
- contains information that allows a proxy to input a URI and receive a
- set of zero or more URIs that tell the proxy where to send the
- request. Registrations are one way to create this information, but
- not the only way. Arbitrary mapping functions can be configured at
- the discretion of the administrator.
-
- Finally, it is important to note that in SIP, registration is used
- for routing incoming SIP requests and has no role in authorizing
- outgoing requests. Authorization and authentication are handled in
- SIP either on a request-by-request basis with a challenge/response
- mechanism, or by using a lower layer scheme as discussed in Section
- 26.
-
- The complete set of SIP message details for this registration example
- is in Section 24.1.
-
- Additional operations in SIP, such as querying for the capabilities
- of a SIP server or client using OPTIONS, or canceling a pending
- request using CANCEL, will be introduced in later sections.
-
-5 Structure of the Protocol
-
- SIP is structured as a layered protocol, which means that its
- behavior is described in terms of a set of fairly independent
- processing stages with only a loose coupling between each stage. The
- protocol behavior is described as layers for the purpose of
- presentation, allowing the description of functions common across
- elements in a single section. It does not dictate an implementation
- in any way. When we say that an element "contains" a layer, we mean
- it is compliant to the set of rules defined by that layer.
-
- Not every element specified by the protocol contains every layer.
- Furthermore, the elements specified by SIP are logical elements, not
- physical ones. A physical realization can choose to act as different
- logical elements, perhaps even on a transaction-by-transaction basis.
-
- The lowest layer of SIP is its syntax and encoding. Its encoding is
- specified using an augmented Backus-Naur Form grammar (BNF). The
- complete BNF is specified in Section 25; an overview of a SIP
- message's structure can be found in Section 7.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 18]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The second layer is the transport layer. It defines how a client
- sends requests and receives responses and how a server receives
- requests and sends responses over the network. All SIP elements
- contain a transport layer. The transport layer is described in
- Section 18.
-
- The third layer is the transaction layer. Transactions are a
- fundamental component of SIP. A transaction is a request sent by a
- client transaction (using the transport layer) to a server
- transaction, along with all responses to that request sent from the
- server transaction back to the client. The transaction layer handles
- application-layer retransmissions, matching of responses to requests,
- and application-layer timeouts. Any task that a user agent client
- (UAC) accomplishes takes place using a series of transactions.
- Discussion of transactions can be found in Section 17. User agents
- contain a transaction layer, as do stateful proxies. Stateless
- proxies do not contain a transaction layer. The transaction layer
- has a client component (referred to as a client transaction) and a
- server component (referred to as a server transaction), each of which
- are represented by a finite state machine that is constructed to
- process a particular request.
-
- The layer above the transaction layer is called the transaction user
- (TU). Each of the SIP entities, except the stateless proxy, is a
- transaction user. When a TU wishes to send a request, it creates a
- client transaction instance and passes it the request along with the
- destination IP address, port, and transport to which to send the
- request. A TU that creates a client transaction can also cancel it.
- When a client cancels a transaction, it requests that the server stop
- further processing, revert to the state that existed before the
- transaction was initiated, and generate a specific error response to
- that transaction. This is done with a CANCEL request, which
- constitutes its own transaction, but references the transaction to be
- cancelled (Section 9).
-
- The SIP elements, that is, user agent clients and servers, stateless
- and stateful proxies and registrars, contain a core that
- distinguishes them from each other. Cores, except for the stateless
- proxy, are transaction users. While the behavior of the UAC and UAS
- cores depends on the method, there are some common rules for all
- methods (Section 8). For a UAC, these rules govern the construction
- of a request; for a UAS, they govern the processing of a request and
- generating a response. Since registrations play an important role in
- SIP, a UAS that handles a REGISTER is given the special name
- registrar. Section 10 describes UAC and UAS core behavior for the
- REGISTER method. Section 11 describes UAC and UAS core behavior for
- the OPTIONS method, used for determining the capabilities of a UA.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 19]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Certain other requests are sent within a dialog. A dialog is a
- peer-to-peer SIP relationship between two user agents that persists
- for some time. The dialog facilitates sequencing of messages and
- proper routing of requests between the user agents. The INVITE
- method is the only way defined in this specification to establish a
- dialog. When a UAC sends a request that is within the context of a
- dialog, it follows the common UAC rules as discussed in Section 8 but
- also the rules for mid-dialog requests. Section 12 discusses dialogs
- and presents the procedures for their construction and maintenance,
- in addition to construction of requests within a dialog.
-
- The most important method in SIP is the INVITE method, which is used
- to establish a session between participants. A session is a
- collection of participants, and streams of media between them, for
- the purposes of communication. Section 13 discusses how sessions are
- initiated, resulting in one or more SIP dialogs. Section 14
- discusses how characteristics of that session are modified through
- the use of an INVITE request within a dialog. Finally, section 15
- discusses how a session is terminated.
-
- The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
- entirely with the UA core (Section 9 describes cancellation, which
- applies to both UA core and proxy core). Section 16 discusses the
- proxy element, which facilitates routing of messages between user
- agents.
-
-6 Definitions
-
- The following terms have special significance for SIP.
-
- Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
- that points to a domain with a location service that can map
- the URI to another URI where the user might be available.
- Typically, the location service is populated through
- registrations. An AOR is frequently thought of as the "public
- address" of the user.
-
- Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
- logical entity that receives a request and processes it as a
- user agent server (UAS). In order to determine how the request
- should be answered, it acts as a user agent client (UAC) and
- generates requests. Unlike a proxy server, it maintains dialog
- state and must participate in all requests sent on the dialogs
- it has established. Since it is a concatenation of a UAC and
- UAS, no explicit definitions are needed for its behavior.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 20]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Call: A call is an informal term that refers to some communication
- between peers, generally set up for the purposes of a
- multimedia conversation.
-
- Call Leg: Another name for a dialog [31]; no longer used in this
- specification.
-
- Call Stateful: A proxy is call stateful if it retains state for a
- dialog from the initiating INVITE to the terminating BYE
- request. A call stateful proxy is always transaction stateful,
- but the converse is not necessarily true.
-
- Client: A client is any network element that sends SIP requests
- and receives SIP responses. Clients may or may not interact
- directly with a human user. User agent clients and proxies are
- clients.
-
- Conference: A multimedia session (see below) that contains
- multiple participants.
-
- Core: Core designates the functions specific to a particular type
- of SIP entity, i.e., specific to either a stateful or stateless
- proxy, a user agent or registrar. All cores, except those for
- the stateless proxy, are transaction users.
-
- Dialog: A dialog is a peer-to-peer SIP relationship between two
- UAs that persists for some time. A dialog is established by
- SIP messages, such as a 2xx response to an INVITE request. A
- dialog is identified by a call identifier, local tag, and a
- remote tag. A dialog was formerly known as a call leg in RFC
- 2543.
-
- Downstream: A direction of message forwarding within a transaction
- that refers to the direction that requests flow from the user
- agent client to user agent server.
-
- Final Response: A response that terminates a SIP transaction, as
- opposed to a provisional response that does not. All 2xx, 3xx,
- 4xx, 5xx and 6xx responses are final.
-
- Header: A header is a component of a SIP message that conveys
- information about the message. It is structured as a sequence
- of header fields.
-
- Header Field: A header field is a component of the SIP message
- header. A header field can appear as one or more header field
- rows. Header field rows consist of a header field name and zero
- or more header field values. Multiple header field values on a
-
-
-
-Rosenberg, et. al. Standards Track [Page 21]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- given header field row are separated by commas. Some header
- fields can only have a single header field value, and as a
- result, always appear as a single header field row.
-
- Header Field Value: A header field value is a single value; a
- header field consists of zero or more header field values.
-
- Home Domain: The domain providing service to a SIP user.
- Typically, this is the domain present in the URI in the
- address-of-record of a registration.
-
- Informational Response: Same as a provisional response.
-
- Initiator, Calling Party, Caller: The party initiating a session
- (and dialog) with an INVITE request. A caller retains this
- role from the time it sends the initial INVITE that established
- a dialog until the termination of that dialog.
-
- Invitation: An INVITE request.
-
- Invitee, Invited User, Called Party, Callee: The party that
- receives an INVITE request for the purpose of establishing a
- new session. A callee retains this role from the time it
- receives the INVITE until the termination of the dialog
- established by that INVITE.
-
- Location Service: A location service is used by a SIP redirect or
- proxy server to obtain information about a callee's possible
- location(s). It contains a list of bindings of address-of-
- record keys to zero or more contact addresses. The bindings
- can be created and removed in many ways; this specification
- defines a REGISTER method that updates the bindings.
-
- Loop: A request that arrives at a proxy, is forwarded, and later
- arrives back at the same proxy. When it arrives the second
- time, its Request-URI is identical to the first time, and other
- header fields that affect proxy operation are unchanged, so
- that the proxy would make the same processing decision on the
- request it made the first time. Looped requests are errors,
- and the procedures for detecting them and handling them are
- described by the protocol.
-
- Loose Routing: A proxy is said to be loose routing if it follows
- the procedures defined in this specification for processing of
- the Route header field. These procedures separate the
- destination of the request (present in the Request-URI) from
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 22]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- the set of proxies that need to be visited along the way
- (present in the Route header field). A proxy compliant to
- these mechanisms is also known as a loose router.
-
- Message: Data sent between SIP elements as part of the protocol.
- SIP messages are either requests or responses.
-
- Method: The method is the primary function that a request is meant
- to invoke on a server. The method is carried in the request
- message itself. Example methods are INVITE and BYE.
-
- Outbound Proxy: A proxy that receives requests from a client, even
- though it may not be the server resolved by the Request-URI.
- Typically, a UA is manually configured with an outbound proxy,
- or can learn about one through auto-configuration protocols.
-
- Parallel Search: In a parallel search, a proxy issues several
- requests to possible user locations upon receiving an incoming
- request. Rather than issuing one request and then waiting for
- the final response before issuing the next request as in a
- sequential search, a parallel search issues requests without
- waiting for the result of previous requests.
-
- Provisional Response: A response used by the server to indicate
- progress, but that does not terminate a SIP transaction. 1xx
- responses are provisional, other responses are considered
- final.
-
- Proxy, Proxy Server: An intermediary entity that acts as both a
- server and a client for the purpose of making requests on
- behalf of other clients. A proxy server primarily plays the
- role of routing, which means its job is to ensure that a
- request is sent to another entity "closer" to the targeted
- user. Proxies are also useful for enforcing policy (for
- example, making sure a user is allowed to make a call). A
- proxy interprets, and, if necessary, rewrites specific parts of
- a request message before forwarding it.
-
- Recursion: A client recurses on a 3xx response when it generates a
- new request to one or more of the URIs in the Contact header
- field in the response.
-
- Redirect Server: A redirect server is a user agent server that
- generates 3xx responses to requests it receives, directing the
- client to contact an alternate set of URIs.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 23]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Registrar: A registrar is a server that accepts REGISTER requests
- and places the information it receives in those requests into
- the location service for the domain it handles.
-
- Regular Transaction: A regular transaction is any transaction with
- a method other than INVITE, ACK, or CANCEL.
-
- Request: A SIP message sent from a client to a server, for the
- purpose of invoking a particular operation.
-
- Response: A SIP message sent from a server to a client, for
- indicating the status of a request sent from the client to the
- server.
-
- Ringback: Ringback is the signaling tone produced by the calling
- party's application indicating that a called party is being
- alerted (ringing).
-
- Route Set: A route set is a collection of ordered SIP or SIPS URI
- which represent a list of proxies that must be traversed when
- sending a particular request. A route set can be learned,
- through headers like Record-Route, or it can be configured.
-
- Server: A server is a network element that receives requests in
- order to service them and sends back responses to those
- requests. Examples of servers are proxies, user agent servers,
- redirect servers, and registrars.
-
- Sequential Search: In a sequential search, a proxy server attempts
- each contact address in sequence, proceeding to the next one
- only after the previous has generated a final response. A 2xx
- or 6xx class final response always terminates a sequential
- search.
-
- Session: From the SDP specification: "A multimedia session is a
- set of multimedia senders and receivers and the data streams
- flowing from senders to receivers. A multimedia conference is
- an example of a multimedia session." (RFC 2327 [1]) (A session
- as defined for SDP can comprise one or more RTP sessions.) As
- defined, a callee can be invited several times, by different
- calls, to the same session. If SDP is used, a session is
- defined by the concatenation of the SDP user name, session id,
- network type, address type, and address elements in the origin
- field.
-
- SIP Transaction: A SIP transaction occurs between a client and a
- server and comprises all messages from the first request sent
- from the client to the server up to a final (non-1xx) response
-
-
-
-Rosenberg, et. al. Standards Track [Page 24]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- sent from the server to the client. If the request is INVITE
- and the final response is a non-2xx, the transaction also
- includes an ACK to the response. The ACK for a 2xx response to
- an INVITE request is a separate transaction.
-
- Spiral: A spiral is a SIP request that is routed to a proxy,
- forwarded onwards, and arrives once again at that proxy, but
- this time differs in a way that will result in a different
- processing decision than the original request. Typically, this
- means that the request's Request-URI differs from its previous
- arrival. A spiral is not an error condition, unlike a loop. A
- typical cause for this is call forwarding. A user calls
- joe@example.com. The example.com proxy forwards it to Joe's
- PC, which in turn, forwards it to bob@example.com. This
- request is proxied back to the example.com proxy. However,
- this is not a loop. Since the request is targeted at a
- different user, it is considered a spiral, and is a valid
- condition.
-
- Stateful Proxy: A logical entity that maintains the client and
- server transaction state machines defined by this specification
- during the processing of a request, also known as a transaction
- stateful proxy. The behavior of a stateful proxy is further
- defined in Section 16. A (transaction) stateful proxy is not
- the same as a call stateful proxy.
-
- Stateless Proxy: A logical entity that does not maintain the
- client or server transaction state machines defined in this
- specification when it processes requests. A stateless proxy
- forwards every request it receives downstream and every
- response it receives upstream.
-
- Strict Routing: A proxy is said to be strict routing if it follows
- the Route processing rules of RFC 2543 and many prior work in
- progress versions of this RFC. That rule caused proxies to
- destroy the contents of the Request-URI when a Route header
- field was present. Strict routing behavior is not used in this
- specification, in favor of a loose routing behavior. Proxies
- that perform strict routing are also known as strict routers.
-
- Target Refresh Request: A target refresh request sent within a
- dialog is defined as a request that can modify the remote
- target of the dialog.
-
- Transaction User (TU): The layer of protocol processing that
- resides above the transaction layer. Transaction users include
- the UAC core, UAS core, and proxy core.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 25]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Upstream: A direction of message forwarding within a transaction
- that refers to the direction that responses flow from the user
- agent server back to the user agent client.
-
- URL-encoded: A character string encoded according to RFC 2396,
- Section 2.4 [5].
-
- User Agent Client (UAC): A user agent client is a logical entity
- that creates a new request, and then uses the client
- transaction state machinery to send it. The role of UAC lasts
- only for the duration of that transaction. In other words, if
- a piece of software initiates a request, it acts as a UAC for
- the duration of that transaction. If it receives a request
- later, it assumes the role of a user agent server for the
- processing of that transaction.
-
- UAC Core: The set of processing functions required of a UAC that
- reside above the transaction and transport layers.
-
- User Agent Server (UAS): A user agent server is a logical entity
- that generates a response to a SIP request. The response
- accepts, rejects, or redirects the request. This role lasts
- only for the duration of that transaction. In other words, if
- a piece of software responds to a request, it acts as a UAS for
- the duration of that transaction. If it generates a request
- later, it assumes the role of a user agent client for the
- processing of that transaction.
-
- UAS Core: The set of processing functions required at a UAS that
- resides above the transaction and transport layers.
-
- User Agent (UA): A logical entity that can act as both a user
- agent client and user agent server.
-
- The role of UAC and UAS, as well as proxy and redirect servers, are
- defined on a transaction-by-transaction basis. For example, the user
- agent initiating a call acts as a UAC when sending the initial INVITE
- request and as a UAS when receiving a BYE request from the callee.
- Similarly, the same software can act as a proxy server for one
- request and as a redirect server for the next request.
-
- Proxy, location, and registrar servers defined above are logical
- entities; implementations MAY combine them into a single application.
-
-7 SIP Messages
-
- SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
- [7]).
-
-
-
-Rosenberg, et. al. Standards Track [Page 26]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- A SIP message is either a request from a client to a server, or a
- response from a server to a client.
-
- Both Request (section 7.1) and Response (section 7.2) messages use
- the basic format of RFC 2822 [3], even though the syntax differs in
- character set and syntax specifics. (SIP allows header fields that
- would not be valid RFC 2822 header fields, for example.) Both types
- of messages consist of a start-line, one or more header fields, an
- empty line indicating the end of the header fields, and an optional
- message-body.
-
- generic-message = start-line
- *message-header
- CRLF
- [ message-body ]
- start-line = Request-Line / Status-Line
-
- The start-line, each message-header line, and the empty line MUST be
- terminated by a carriage-return line-feed sequence (CRLF). Note that
- the empty line MUST be present even if the message-body is not.
-
- Except for the above difference in character sets, much of SIP's
- message and header field syntax is identical to HTTP/1.1. Rather
- than repeating the syntax and semantics here, we use [HX.Y] to refer
- to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).
-
- However, SIP is not an extension of HTTP.
-
-7.1 Requests
-
- SIP requests are distinguished by having a Request-Line for a start-
- line. A Request-Line contains a method name, a Request-URI, and the
- protocol version separated by a single space (SP) character.
-
- The Request-Line ends with CRLF. No CR or LF are allowed except in
- the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed
- in any of the elements.
-
- Request-Line = Method SP Request-URI SP SIP-Version CRLF
-
- Method: This specification defines six methods: REGISTER for
- registering contact information, INVITE, ACK, and CANCEL for
- setting up sessions, BYE for terminating sessions, and
- OPTIONS for querying servers about their capabilities. SIP
- extensions, documented in standards track RFCs, may define
- additional methods.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 27]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Request-URI: The Request-URI is a SIP or SIPS URI as described in
- Section 19.1 or a general URI (RFC 2396 [5]). It indicates
- the user or service to which this request is being addressed.
- The Request-URI MUST NOT contain unescaped spaces or control
- characters and MUST NOT be enclosed in "<>".
-
- SIP elements MAY support Request-URIs with schemes other than
- "sip" and "sips", for example the "tel" URI scheme of RFC
- 2806 [9]. SIP elements MAY translate non-SIP URIs using any
- mechanism at their disposal, resulting in SIP URI, SIPS URI,
- or some other scheme.
-
- SIP-Version: Both request and response messages include the
- version of SIP in use, and follow [H3.1] (with HTTP replaced
- by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version
- ordering, compliance requirements, and upgrading of version
- numbers. To be compliant with this specification,
- applications sending SIP messages MUST include a SIP-Version
- of "SIP/2.0". The SIP-Version string is case-insensitive,
- but implementations MUST send upper-case.
-
- Unlike HTTP/1.1, SIP treats the version number as a literal
- string. In practice, this should make no difference.
-
-7.2 Responses
-
- SIP responses are distinguished from requests by having a Status-Line
- as their start-line. A Status-Line consists of the protocol version
- followed by a numeric Status-Code and its associated textual phrase,
- with each element separated by a single SP character.
-
- No CR or LF is allowed except in the final CRLF sequence.
-
- Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
-
- The Status-Code is a 3-digit integer result code that indicates the
- outcome of an attempt to understand and satisfy a request. The
- Reason-Phrase is intended to give a short textual description of the
- Status-Code. The Status-Code is intended for use by automata,
- whereas the Reason-Phrase is intended for the human user. A client
- is not required to examine or display the Reason-Phrase.
-
- While this specification suggests specific wording for the reason
- phrase, implementations MAY choose other text, for example, in the
- language indicated in the Accept-Language header field of the
- request.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 28]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The first digit of the Status-Code defines the class of response.
- The last two digits do not have any categorization role. For this
- reason, any response with a status code between 100 and 199 is
- referred to as a "1xx response", any response with a status code
- between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows
- six values for the first digit:
-
- 1xx: Provisional -- request received, continuing to process the
- request;
-
- 2xx: Success -- the action was successfully received, understood,
- and accepted;
-
- 3xx: Redirection -- further action needs to be taken in order to
- complete the request;
-
- 4xx: Client Error -- the request contains bad syntax or cannot be
- fulfilled at this server;
-
- 5xx: Server Error -- the server failed to fulfill an apparently
- valid request;
-
- 6xx: Global Failure -- the request cannot be fulfilled at any
- server.
-
- Section 21 defines these classes and describes the individual codes.
-
-7.3 Header Fields
-
- SIP header fields are similar to HTTP header fields in both syntax
- and semantics. In particular, SIP header fields follow the [H4.2]
- definitions of syntax for the message-header and the rules for
- extending header fields over multiple lines. However, the latter is
- specified in HTTP with implicit whitespace and folding. This
- specification conforms to RFC 2234 [10] and uses only explicit
- whitespace and folding as an integral part of the grammar.
-
- [H4.2] also specifies that multiple header fields of the same field
- name whose value is a comma-separated list can be combined into one
- header field. That applies to SIP as well, but the specific rule is
- different because of the different grammars. Specifically, any SIP
- header whose grammar is of the form
-
- header = "header-name" HCOLON header-value *(COMMA header-value)
-
- allows for combining header fields of the same name into a comma-
- separated list. The Contact header field allows a comma-separated
- list unless the header field value is "*".
-
-
-
-Rosenberg, et. al. Standards Track [Page 29]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-7.3.1 Header Field Format
-
- Header fields follow the same generic header format as that given in
- Section 2.2 of RFC 2822 [3]. Each header field consists of a field
- name followed by a colon (":") and the field value.
-
- field-name: field-value
-
- The formal grammar for a message-header specified in Section 25
- allows for an arbitrary amount of whitespace on either side of the
- colon; however, implementations should avoid spaces between the field
- name and the colon and use a single space (SP) between the colon and
- the field-value.
-
- Subject: lunch
- Subject : lunch
- Subject :lunch
- Subject: lunch
-
- Thus, the above are all valid and equivalent, but the last is the
- preferred form.
-
- Header fields can be extended over multiple lines by preceding each
- extra line with at least one SP or horizontal tab (HT). The line
- break and the whitespace at the beginning of the next line are
- treated as a single SP character. Thus, the following are
- equivalent:
-
- Subject: I know you're there, pick up the phone and talk to me!
- Subject: I know you're there,
- pick up the phone
- and talk to me!
-
- The relative order of header fields with different field names is not
- significant. However, it is RECOMMENDED that header fields which are
- needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
- Max-Forwards, and Proxy-Authorization, for example) appear towards
- the top of the message to facilitate rapid parsing. The relative
- order of header field rows with the same field name is important.
- Multiple header field rows with the same field-name MAY be present in
- a message if and only if the entire field-value for that header field
- is defined as a comma-separated list (that is, if follows the grammar
- defined in Section 7.3). It MUST be possible to combine the multiple
- header field rows into one "field-name: field-value" pair, without
- changing the semantics of the message, by appending each subsequent
- field-value to the first, each separated by a comma. The exceptions
- to this rule are the WWW-Authenticate, Authorization, Proxy-
- Authenticate, and Proxy-Authorization header fields. Multiple header
-
-
-
-Rosenberg, et. al. Standards Track [Page 30]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- field rows with these names MAY be present in a message, but since
- their grammar does not follow the general form listed in Section 7.3,
- they MUST NOT be combined into a single header field row.
-
- Implementations MUST be able to process multiple header field rows
- with the same name in any combination of the single-value-per-line or
- comma-separated value forms.
-
- The following groups of header field rows are valid and equivalent:
-
- Route: <sip:alice@atlanta.com>
- Subject: Lunch
- Route: <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
-
- Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
- Subject: Lunch
-
- Subject: Lunch
- Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
- <sip:carol@chicago.com>
-
- Each of the following blocks is valid but not equivalent to the
- others:
-
- Route: <sip:alice@atlanta.com>
- Route: <sip:bob@biloxi.com>
- Route: <sip:carol@chicago.com>
-
- Route: <sip:bob@biloxi.com>
- Route: <sip:alice@atlanta.com>
- Route: <sip:carol@chicago.com>
-
- Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
- <sip:bob@biloxi.com>
-
- The format of a header field-value is defined per header-name. It
- will always be either an opaque sequence of TEXT-UTF8 octets, or a
- combination of whitespace, tokens, separators, and quoted strings.
- Many existing header fields will adhere to the general form of a
- value followed by a semi-colon separated sequence of parameter-name,
- parameter-value pairs:
-
- field-name: field-value *(;parameter-name=parameter-value)
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 31]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Even though an arbitrary number of parameter pairs may be attached to
- a header field value, any given parameter-name MUST NOT appear more
- than once.
-
- When comparing header fields, field names are always case-
- insensitive. Unless otherwise stated in the definition of a
- particular header field, field values, parameter names, and parameter
- values are case-insensitive. Tokens are always case-insensitive.
- Unless specified otherwise, values expressed as quoted strings are
- case-sensitive. For example,
-
- Contact: <sip:alice@atlanta.com>;expires=3600
-
- is equivalent to
-
- CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
-
- and
-
- Content-Disposition: session;handling=optional
-
- is equivalent to
-
- content-disposition: Session;HANDLING=OPTIONAL
-
- The following two header fields are not equivalent:
-
- Warning: 370 devnull "Choose a bigger pipe"
- Warning: 370 devnull "CHOOSE A BIGGER PIPE"
-
-7.3.2 Header Field Classification
-
- Some header fields only make sense in requests or responses. These
- are called request header fields and response header fields,
- respectively. If a header field appears in a message not matching
- its category (such as a request header field in a response), it MUST
- be ignored. Section 20 defines the classification of each header
- field.
-
-7.3.3 Compact Form
-
- SIP provides a mechanism to represent common header field names in an
- abbreviated form. This may be useful when messages would otherwise
- become too large to be carried on the transport available to it
- (exceeding the maximum transmission unit (MTU) when using UDP, for
- example). These compact forms are defined in Section 20. A compact
- form MAY be substituted for the longer form of a header field name at
- any time without changing the semantics of the message. A header
-
-
-
-Rosenberg, et. al. Standards Track [Page 32]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- field name MAY appear in both long and short forms within the same
- message. Implementations MUST accept both the long and short forms
- of each header name.
-
-7.4 Bodies
-
- Requests, including new requests defined in extensions to this
- specification, MAY contain message bodies unless otherwise noted.
- The interpretation of the body depends on the request method.
-
- For response messages, the request method and the response status
- code determine the type and interpretation of any message body. All
- responses MAY include a body.
-
-7.4.1 Message Body Type
-
- The Internet media type of the message body MUST be given by the
- Content-Type header field. If the body has undergone any encoding
- such as compression, then this MUST be indicated by the Content-
- Encoding header field; otherwise, Content-Encoding MUST be omitted.
- If applicable, the character set of the message body is indicated as
- part of the Content-Type header-field value.
-
- The "multipart" MIME type defined in RFC 2046 [11] MAY be used within
- the body of the message. Implementations that send requests
- containing multipart message bodies MUST send a session description
- as a non-multipart message body if the remote implementation requests
- this through an Accept header field that does not contain multipart.
-
- SIP messages MAY contain binary bodies or body parts. When no
- explicit charset parameter is provided by the sender, media subtypes
- of the "text" type are defined to have a default charset value of
- "UTF-8".
-
-7.4.2 Message Body Length
-
- The body length in bytes is provided by the Content-Length header
- field. Section 20.14 describes the necessary contents of this header
- field in detail.
-
- The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
- (Note: The chunked encoding modifies the body of a message in order
- to transfer it as a series of chunks, each with its own size
- indicator.)
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 33]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-7.5 Framing SIP Messages
-
- Unlike HTTP, SIP implementations can use UDP or other unreliable
- datagram protocols. Each such datagram carries one request or
- response. See Section 18 on constraints on usage of unreliable
- transports.
-
- Implementations processing SIP messages over stream-oriented
- transports MUST ignore any CRLF appearing before the start-line
- [H4.1].
-
- The Content-Length header field value is used to locate the end of
- each SIP message in a stream. It will always be present when SIP
- messages are sent over stream-oriented transports.
-
-8 General User Agent Behavior
-
- A user agent represents an end system. It contains a user agent
- client (UAC), which generates requests, and a user agent server
- (UAS), which responds to them. A UAC is capable of generating a
- request based on some external stimulus (the user clicking a button,
- or a signal on a PSTN line) and processing a response. A UAS is
- capable of receiving a request and generating a response based on
- user input, external stimulus, the result of a program execution, or
- some other mechanism.
-
- When a UAC sends a request, the request passes through some number of
- proxy servers, which forward the request towards the UAS. When the
- UAS generates a response, the response is forwarded towards the UAC.
-
- UAC and UAS procedures depend strongly on two factors. First, based
- on whether the request or response is inside or outside of a dialog,
- and second, based on the method of a request. Dialogs are discussed
- thoroughly in Section 12; they represent a peer-to-peer relationship
- between user agents and are established by specific SIP methods, such
- as INVITE.
-
- In this section, we discuss the method-independent rules for UAC and
- UAS behavior when processing requests that are outside of a dialog.
- This includes, of course, the requests which themselves establish a
- dialog.
-
- Security procedures for requests and responses outside of a dialog
- are described in Section 26. Specifically, mechanisms exist for the
- UAS and UAC to mutually authenticate. A limited set of privacy
- features are also supported through encryption of bodies using
- S/MIME.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 34]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-8.1 UAC Behavior
-
- This section covers UAC behavior outside of a dialog.
-
-8.1.1 Generating the Request
-
- A valid SIP request formulated by a UAC MUST, at a minimum, contain
- the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
- and Via; all of these header fields are mandatory in all SIP
- requests. These six header fields are the fundamental building
- blocks of a SIP message, as they jointly provide for most of the
- critical message routing services including the addressing of
- messages, the routing of responses, limiting message propagation,
- ordering of messages, and the unique identification of transactions.
- These header fields are in addition to the mandatory request line,
- which contains the method, Request-URI, and SIP version.
-
- Examples of requests sent outside of a dialog include an INVITE to
- establish a session (Section 13) and an OPTIONS to query for
- capabilities (Section 11).
-
-8.1.1.1 Request-URI
-
- The initial Request-URI of the message SHOULD be set to the value of
- the URI in the To field. One notable exception is the REGISTER
- method; behavior for setting the Request-URI of REGISTER is given in
- Section 10. It may also be undesirable for privacy reasons or
- convenience to set these fields to the same value (especially if the
- originating UA expects that the Request-URI will be changed during
- transit).
-
- In some special circumstances, the presence of a pre-existing route
- set can affect the Request-URI of the message. A pre-existing route
- set is an ordered set of URIs that identify a chain of servers, to
- which a UAC will send outgoing requests that are outside of a dialog.
- Commonly, they are configured on the UA by a user or service provider
- manually, or through some other non-SIP mechanism. When a provider
- wishes to configure a UA with an outbound proxy, it is RECOMMENDED
- that this be done by providing it with a pre-existing route set with
- a single URI, that of the outbound proxy.
-
- When a pre-existing route set is present, the procedures for
- populating the Request-URI and Route header field detailed in Section
- 12.2.1.1 MUST be followed (even though there is no dialog), using the
- desired Request-URI as the remote target URI.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 35]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-8.1.1.2 To
-
- The To header field first and foremost specifies the desired
- "logical" recipient of the request, or the address-of-record of the
- user or resource that is the target of this request. This may or may
- not be the ultimate recipient of the request. The To header field
- MAY contain a SIP or SIPS URI, but it may also make use of other URI
- schemes (the tel URL (RFC 2806 [9]), for example) when appropriate.
- All SIP implementations MUST support the SIP URI scheme. Any
- implementation that supports TLS MUST support the SIPS URI scheme.
- The To header field allows for a display name.
-
- A UAC may learn how to populate the To header field for a particular
- request in a number of ways. Usually the user will suggest the To
- header field through a human interface, perhaps inputting the URI
- manually or selecting it from some sort of address book. Frequently,
- the user will not enter a complete URI, but rather a string of digits
- or letters (for example, "bob"). It is at the discretion of the UA
- to choose how to interpret this input. Using the string to form the
- user part of a SIP URI implies that the UA wishes the name to be
- resolved in the domain to the right-hand side (RHS) of the at-sign in
- the SIP URI (for instance, sip:bob@example.com). Using the string to
- form the user part of a SIPS URI implies that the UA wishes to
- communicate securely, and that the name is to be resolved in the
- domain to the RHS of the at-sign. The RHS will frequently be the
- home domain of the requestor, which allows for the home domain to
- process the outgoing request. This is useful for features like
- "speed dial" that require interpretation of the user part in the home
- domain. The tel URL may be used when the UA does not wish to specify
- the domain that should interpret a telephone number that has been
- input by the user. Rather, each domain through which the request
- passes would be given that opportunity. As an example, a user in an
- airport might log in and send requests through an outbound proxy in
- the airport. If they enter "411" (this is the phone number for local
- directory assistance in the United States), that needs to be
- interpreted and processed by the outbound proxy in the airport, not
- the user's home domain. In this case, tel:411 would be the right
- choice.
-
- A request outside of a dialog MUST NOT contain a To tag; the tag in
- the To field of a request identifies the peer of the dialog. Since
- no dialog is established, no tag is present.
-
- For further information on the To header field, see Section 20.39.
- The following is an example of a valid To header field:
-
- To: Carol <sip:carol@chicago.com>
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 36]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-8.1.1.3 From
-
- The From header field indicates the logical identity of the initiator
- of the request, possibly the user's address-of-record. Like the To
- header field, it contains a URI and optionally a display name. It is
- used by SIP elements to determine which processing rules to apply to
- a request (for example, automatic call rejection). As such, it is
- very important that the From URI not contain IP addresses or the FQDN
- of the host on which the UA is running, since these are not logical
- names.
-
- The From header field allows for a display name. A UAC SHOULD use
- the display name "Anonymous", along with a syntactically correct, but
- otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
- identity of the client is to remain hidden.
-
- Usually, the value that populates the From header field in requests
- generated by a particular UA is pre-provisioned by the user or by the
- administrators of the user's local domain. If a particular UA is
- used by multiple users, it might have switchable profiles that
- include a URI corresponding to the identity of the profiled user.
- Recipients of requests can authenticate the originator of a request
- in order to ascertain that they are who their From header field
- claims they are (see Section 22 for more on authentication).
-
- The From field MUST contain a new "tag" parameter, chosen by the UAC.
- See Section 19.3 for details on choosing a tag.
-
- For further information on the From header field, see Section 20.20.
- Examples:
-
- From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
- From: sip:+12125551212@phone2net.com;tag=887s
- From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
-
-8.1.1.4 Call-ID
-
- The Call-ID header field acts as a unique identifier to group
- together a series of messages. It MUST be the same for all requests
- and responses sent by either UA in a dialog. It SHOULD be the same
- in each registration from a UA.
-
- In a new request created by a UAC outside of any dialog, the Call-ID
- header field MUST be selected by the UAC as a globally unique
- identifier over space and time unless overridden by method-specific
- behavior. All SIP UAs must have a means to guarantee that the Call-
- ID header fields they produce will not be inadvertently generated by
- any other UA. Note that when requests are retried after certain
-
-
-
-Rosenberg, et. al. Standards Track [Page 37]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- failure responses that solicit an amendment to a request (for
- example, a challenge for authentication), these retried requests are
- not considered new requests, and therefore do not need new Call-ID
- header fields; see Section 8.1.3.5.
-
- Use of cryptographically random identifiers (RFC 1750 [12]) in the
- generation of Call-IDs is RECOMMENDED. Implementations MAY use the
- form "localid@host". Call-IDs are case-sensitive and are simply
- compared byte-by-byte.
-
- Using cryptographically random identifiers provides some
- protection against session hijacking and reduces the likelihood of
- unintentional Call-ID collisions.
-
- No provisioning or human interface is required for the selection of
- the Call-ID header field value for a request.
-
- For further information on the Call-ID header field, see Section
- 20.8.
-
- Example:
-
- Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
-
-8.1.1.5 CSeq
-
- The CSeq header field serves as a way to identify and order
- transactions. It consists of a sequence number and a method. The
- method MUST match that of the request. For non-REGISTER requests
- outside of a dialog, the sequence number value is arbitrary. The
- sequence number value MUST be expressible as a 32-bit unsigned
- integer and MUST be less than 2**31. As long as it follows the above
- guidelines, a client may use any mechanism it would like to select
- CSeq header field values.
-
- Section 12.2.1.1 discusses construction of the CSeq for requests
- within a dialog.
-
- Example:
-
- CSeq: 4711 INVITE
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 38]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-8.1.1.6 Max-Forwards
-
- The Max-Forwards header field serves to limit the number of hops a
- request can transit on the way to its destination. It consists of an
- integer that is decremented by one at each hop. If the Max-Forwards
- value reaches 0 before the request reaches its destination, it will
- be rejected with a 483(Too Many Hops) error response.
-
- A UAC MUST insert a Max-Forwards header field into each request it
- originates with a value that SHOULD be 70. This number was chosen to
- be sufficiently large to guarantee that a request would not be
- dropped in any SIP network when there were no loops, but not so large
- as to consume proxy resources when a loop does occur. Lower values
- should be used with caution and only in networks where topologies are
- known by the UA.
-
-8.1.1.7 Via
-
- The Via header field indicates the transport used for the transaction
- and identifies the location where the response is to be sent. A Via
- header field value is added only after the transport that will be
- used to reach the next hop has been selected (which may involve the
- usage of the procedures in [4]).
-
- When the UAC creates a request, it MUST insert a Via into that
- request. The protocol name and protocol version in the header field
- MUST be SIP and 2.0, respectively. The Via header field value MUST
- contain a branch parameter. This parameter is used to identify the
- transaction created by that request. This parameter is used by both
- the client and the server.
-
- The branch parameter value MUST be unique across space and time for
- all requests sent by the UA. The exceptions to this rule are CANCEL
- and ACK for non-2xx responses. As discussed below, a CANCEL request
- will have the same value of the branch parameter as the request it
- cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx
- response will also have the same branch ID as the INVITE whose
- response it acknowledges.
-
- The uniqueness property of the branch ID parameter, to facilitate
- its use as a transaction ID, was not part of RFC 2543.
-
- The branch ID inserted by an element compliant with this
- specification MUST always begin with the characters "z9hG4bK". These
- 7 characters are used as a magic cookie (7 is deemed sufficient to
- ensure that an older RFC 2543 implementation would not pick such a
- value), so that servers receiving the request can determine that the
- branch ID was constructed in the fashion described by this
-
-
-
-Rosenberg, et. al. Standards Track [Page 39]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- specification (that is, globally unique). Beyond this requirement,
- the precise format of the branch token is implementation-defined.
-
- The Via header maddr, ttl, and sent-by components will be set when
- the request is processed by the transport layer (Section 18).
-
- Via processing for proxies is described in Section 16.6 Item 8 and
- Section 16.7 Item 3.
-
-8.1.1.8 Contact
-
- The Contact header field provides a SIP or SIPS URI that can be used
- to contact that specific instance of the UA for subsequent requests.
- The Contact header field MUST be present and contain exactly one SIP
- or SIPS URI in any request that can result in the establishment of a
- dialog. For the methods defined in this specification, that includes
- only the INVITE request. For these requests, the scope of the
- Contact is global. That is, the Contact header field value contains
- the URI at which the UA would like to receive requests, and this URI
- MUST be valid even if used in subsequent requests outside of any
- dialogs.
-
- If the Request-URI or top Route header field value contains a SIPS
- URI, the Contact header field MUST contain a SIPS URI as well.
-
- For further information on the Contact header field, see Section
- 20.10.
-
-8.1.1.9 Supported and Require
-
- If the UAC supports extensions to SIP that can be applied by the
- server to the response, the UAC SHOULD include a Supported header
- field in the request listing the option tags (Section 19.2) for those
- extensions.
-
- The option tags listed MUST only refer to extensions defined in
- standards-track RFCs. This is to prevent servers from insisting that
- clients implement non-standard, vendor-defined features in order to
- receive service. Extensions defined by experimental and
- informational RFCs are explicitly excluded from usage with the
- Supported header field in a request, since they too are often used to
- document vendor-defined extensions.
-
- If the UAC wishes to insist that a UAS understand an extension that
- the UAC will apply to the request in order to process the request, it
- MUST insert a Require header field into the request listing the
- option tag for that extension. If the UAC wishes to apply an
- extension to the request and insist that any proxies that are
-
-
-
-Rosenberg, et. al. Standards Track [Page 40]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- traversed understand that extension, it MUST insert a Proxy-Require
- header field into the request listing the option tag for that
- extension.
-
- As with the Supported header field, the option tags in the Require
- and Proxy-Require header fields MUST only refer to extensions defined
- in standards-track RFCs.
-
-8.1.1.10 Additional Message Components
-
- After a new request has been created, and the header fields described
- above have been properly constructed, any additional optional header
- fields are added, as are any header fields specific to the method.
-
- SIP requests MAY contain a MIME-encoded message-body. Regardless of
- the type of body that a request contains, certain header fields must
- be formulated to characterize the contents of the body. For further
- information on these header fields, see Sections 20.11 through 20.15.
-
-8.1.2 Sending the Request
-
- The destination for the request is then computed. Unless there is
- local policy specifying otherwise, the destination MUST be determined
- by applying the DNS procedures described in [4] as follows. If the
- first element in the route set indicated a strict router (resulting
- in forming the request as described in Section 12.2.1.1), the
- procedures MUST be applied to the Request-URI of the request.
- Otherwise, the procedures are applied to the first Route header field
- value in the request (if one exists), or to the request's Request-URI
- if there is no Route header field present. These procedures yield an
- ordered set of address, port, and transports to attempt. Independent
- of which URI is used as input to the procedures of [4], if the
- Request-URI specifies a SIPS resource, the UAC MUST follow the
- procedures of [4] as if the input URI were a SIPS URI.
-
- Local policy MAY specify an alternate set of destinations to attempt.
- If the Request-URI contains a SIPS URI, any alternate destinations
- MUST be contacted with TLS. Beyond that, there are no restrictions
- on the alternate destinations if the request contains no Route header
- field. This provides a simple alternative to a pre-existing route
- set as a way to specify an outbound proxy. However, that approach
- for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
- route set with a single URI SHOULD be used instead. If the request
- contains a Route header field, the request SHOULD be sent to the
- locations derived from its topmost value, but MAY be sent to any
- server that the UA is certain will honor the Route and Request-URI
- policies specified in this document (as opposed to those in RFC
- 2543). In particular, a UAC configured with an outbound proxy SHOULD
-
-
-
-Rosenberg, et. al. Standards Track [Page 41]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- attempt to send the request to the location indicated in the first
- Route header field value instead of adopting the policy of sending
- all messages to the outbound proxy.
-
- This ensures that outbound proxies that do not add Record-Route
- header field values will drop out of the path of subsequent
- requests. It allows endpoints that cannot resolve the first Route
- URI to delegate that task to an outbound proxy.
-
- The UAC SHOULD follow the procedures defined in [4] for stateful
- elements, trying each address until a server is contacted. Each try
- constitutes a new transaction, and therefore each carries a different
- topmost Via header field value with a new branch parameter.
- Furthermore, the transport value in the Via header field is set to
- whatever transport was determined for the target server.
-
-8.1.3 Processing Responses
-
- Responses are first processed by the transport layer and then passed
- up to the transaction layer. The transaction layer performs its
- processing and then passes the response up to the TU. The majority
- of response processing in the TU is method specific. However, there
- are some general behaviors independent of the method.
-
-8.1.3.1 Transaction Layer Errors
-
- In some cases, the response returned by the transaction layer will
- not be a SIP message, but rather a transaction layer error. When a
- timeout error is received from the transaction layer, it MUST be
- treated as if a 408 (Request Timeout) status code has been received.
- If a fatal transport error is reported by the transport layer
- (generally, due to fatal ICMP errors in UDP or connection failures in
- TCP), the condition MUST be treated as a 503 (Service Unavailable)
- status code.
-
-8.1.3.2 Unrecognized Responses
-
- A UAC MUST treat any final response it does not recognize as being
- equivalent to the x00 response code of that class, and MUST be able
- to process the x00 response code for all classes. For example, if a
- UAC receives an unrecognized response code of 431, it can safely
- assume that there was something wrong with its request and treat the
- response as if it had received a 400 (Bad Request) response code. A
- UAC MUST treat any provisional response different than 100 that it
- does not recognize as 183 (Session Progress). A UAC MUST be able to
- process 100 and 183 responses.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 42]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-8.1.3.3 Vias
-
- If more than one Via header field value is present in a response, the
- UAC SHOULD discard the message.
-
- The presence of additional Via header field values that precede
- the originator of the request suggests that the message was
- misrouted or possibly corrupted.
-
-8.1.3.4 Processing 3xx Responses
-
- Upon receipt of a redirection response (for example, a 301 response
- status code), clients SHOULD use the URI(s) in the Contact header
- field to formulate one or more new requests based on the redirected
- request. This process is similar to that of a proxy recursing on a
- 3xx class response as detailed in Sections 16.5 and 16.6. A client
- starts with an initial target set containing exactly one URI, the
- Request-URI of the original request. If a client wishes to formulate
- new requests based on a 3xx class response to that request, it places
- the URIs to try into the target set. Subject to the restrictions in
- this specification, a client can choose which Contact URIs it places
- into the target set. As with proxy recursion, a client processing
- 3xx class responses MUST NOT add any given URI to the target set more
- than once. If the original request had a SIPS URI in the Request-
- URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD
- inform the user of the redirection to an insecure URI.
-
- Any new request may receive 3xx responses themselves containing
- the original URI as a contact. Two locations can be configured to
- redirect to each other. Placing any given URI in the target set
- only once prevents infinite redirection loops.
-
- As the target set grows, the client MAY generate new requests to the
- URIs in any order. A common mechanism is to order the set by the "q"
- parameter value from the Contact header field value. Requests to the
- URIs MAY be generated serially or in parallel. One approach is to
- process groups of decreasing q-values serially and process the URIs
- in each q-value group in parallel. Another is to perform only serial
- processing in decreasing q-value order, arbitrarily choosing between
- contacts of equal q-value.
-
- If contacting an address in the list results in a failure, as defined
- in the next paragraph, the element moves to the next address in the
- list, until the list is exhausted. If the list is exhausted, then
- the request has failed.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 43]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Failures SHOULD be detected through failure response codes (codes
- greater than 399); for network errors the client transaction will
- report any transport layer failures to the transaction user. Note
- that some response codes (detailed in 8.1.3.5) indicate that the
- request can be retried; requests that are reattempted should not be
- considered failures.
-
- When a failure for a particular contact address is received, the
- client SHOULD try the next contact address. This will involve
- creating a new client transaction to deliver a new request.
-
- In order to create a request based on a contact address in a 3xx
- response, a UAC MUST copy the entire URI from the target set into the
- Request-URI, except for the "method-param" and "header" URI
- parameters (see Section 19.1.1 for a definition of these parameters).
- It uses the "header" parameters to create header field values for the
- new request, overwriting header field values associated with the
- redirected request in accordance with the guidelines in Section
- 19.1.5.
-
- Note that in some instances, header fields that have been
- communicated in the contact address may instead append to existing
- request header fields in the original redirected request. As a
- general rule, if the header field can accept a comma-separated list
- of values, then the new header field value MAY be appended to any
- existing values in the original redirected request. If the header
- field does not accept multiple values, the value in the original
- redirected request MAY be overwritten by the header field value
- communicated in the contact address. For example, if a contact
- address is returned with the following value:
-
- sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
-
- Then any Subject header field in the original redirected request is
- overwritten, but the HTTP URL is merely appended to any existing
- Call-Info header field values.
-
- It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID
- used in the original redirected request, but the UAC MAY also choose
- to update the Call-ID header field value for new requests, for
- example.
-
- Finally, once the new request has been constructed, it is sent using
- a new client transaction, and therefore MUST have a new branch ID in
- the top Via field as discussed in Section 8.1.1.7.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 44]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- In all other respects, requests sent upon receipt of a redirect
- response SHOULD re-use the header fields and bodies of the original
- request.
-
- In some instances, Contact header field values may be cached at UAC
- temporarily or permanently depending on the status code received and
- the presence of an expiration interval; see Sections 21.3.2 and
- 21.3.3.
-
-8.1.3.5 Processing 4xx Responses
-
- Certain 4xx response codes require specific UA processing,
- independent of the method.
-
- If a 401 (Unauthorized) or 407 (Proxy Authentication Required)
- response is received, the UAC SHOULD follow the authorization
- procedures of Section 22.2 and Section 22.3 to retry the request with
- credentials.
-
- If a 413 (Request Entity Too Large) response is received (Section
- 21.4.11), the request contained a body that was longer than the UAS
- was willing to accept. If possible, the UAC SHOULD retry the
- request, either omitting the body or using one of a smaller length.
-
- If a 415 (Unsupported Media Type) response is received (Section
- 21.4.13), the request contained media types not supported by the UAS.
- The UAC SHOULD retry sending the request, this time only using
- content with types listed in the Accept header field in the response,
- with encodings listed in the Accept-Encoding header field in the
- response, and with languages listed in the Accept-Language in the
- response.
-
- If a 416 (Unsupported URI Scheme) response is received (Section
- 21.4.14), the Request-URI used a URI scheme not supported by the
- server. The client SHOULD retry the request, this time, using a SIP
- URI.
-
- If a 420 (Bad Extension) response is received (Section 21.4.15), the
- request contained a Require or Proxy-Require header field listing an
- option-tag for a feature not supported by a proxy or UAS. The UAC
- SHOULD retry the request, this time omitting any extensions listed in
- the Unsupported header field in the response.
-
- In all of the above cases, the request is retried by creating a new
- request with the appropriate modifications. This new request
- constitutes a new transaction and SHOULD have the same value of the
- Call-ID, To, and From of the previous request, but the CSeq should
- contain a new sequence number that is one higher than the previous.
-
-
-
-Rosenberg, et. al. Standards Track [Page 45]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- With other 4xx responses, including those yet to be defined, a retry
- may or may not be possible depending on the method and the use case.
-
-8.2 UAS Behavior
-
- When a request outside of a dialog is processed by a UAS, there is a
- set of processing rules that are followed, independent of the method.
- Section 12 gives guidance on how a UAS can tell whether a request is
- inside or outside of a dialog.
-
- Note that request processing is atomic. If a request is accepted,
- all state changes associated with it MUST be performed. If it is
- rejected, all state changes MUST NOT be performed.
-
- UASs SHOULD process the requests in the order of the steps that
- follow in this section (that is, starting with authentication, then
- inspecting the method, the header fields, and so on throughout the
- remainder of this section).
-
-8.2.1 Method Inspection
-
- Once a request is authenticated (or authentication is skipped), the
- UAS MUST inspect the method of the request. If the UAS recognizes
- but does not support the method of a request, it MUST generate a 405
- (Method Not Allowed) response. Procedures for generating responses
- are described in Section 8.2.6. The UAS MUST also add an Allow
- header field to the 405 (Method Not Allowed) response. The Allow
- header field MUST list the set of methods supported by the UAS
- generating the message. The Allow header field is presented in
- Section 20.5.
-
- If the method is one supported by the server, processing continues.
-
-8.2.2 Header Inspection
-
- If a UAS does not understand a header field in a request (that is,
- the header field is not defined in this specification or in any
- supported extension), the server MUST ignore that header field and
- continue processing the message. A UAS SHOULD ignore any malformed
- header fields that are not necessary for processing requests.
-
-8.2.2.1 To and Request-URI
-
- The To header field identifies the original recipient of the request
- designated by the user identified in the From field. The original
- recipient may or may not be the UAS processing the request, due to
- call forwarding or other proxy operations. A UAS MAY apply any
- policy it wishes to determine whether to accept requests when the To
-
-
-
-Rosenberg, et. al. Standards Track [Page 46]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- header field is not the identity of the UAS. However, it is
- RECOMMENDED that a UAS accept requests even if they do not recognize
- the URI scheme (for example, a tel: URI) in the To header field, or
- if the To header field does not address a known or current user of
- this UAS. If, on the other hand, the UAS decides to reject the
- request, it SHOULD generate a response with a 403 (Forbidden) status
- code and pass it to the server transaction for transmission.
-
- However, the Request-URI identifies the UAS that is to process the
- request. If the Request-URI uses a scheme not supported by the UAS,
- it SHOULD reject the request with a 416 (Unsupported URI Scheme)
- response. If the Request-URI does not identify an address that the
- UAS is willing to accept requests for, it SHOULD reject the request
- with a 404 (Not Found) response. Typically, a UA that uses the
- REGISTER method to bind its address-of-record to a specific contact
- address will see requests whose Request-URI equals that contact
- address. Other potential sources of received Request-URIs include
- the Contact header fields of requests and responses sent by the UA
- that establish or refresh dialogs.
-
-8.2.2.2 Merged Requests
-
- If the request has no tag in the To header field, the UAS core MUST
- check the request against ongoing transactions. If the From tag,
- Call-ID, and CSeq exactly match those associated with an ongoing
- transaction, but the request does not match that transaction (based
- on the matching rules in Section 17.2.3), the UAS core SHOULD
- generate a 482 (Loop Detected) response and pass it to the server
- transaction.
-
- The same request has arrived at the UAS more than once, following
- different paths, most likely due to forking. The UAS processes
- the first such request received and responds with a 482 (Loop
- Detected) to the rest of them.
-
-8.2.2.3 Require
-
- Assuming the UAS decides that it is the proper element to process the
- request, it examines the Require header field, if present.
-
- The Require header field is used by a UAC to tell a UAS about SIP
- extensions that the UAC expects the UAS to support in order to
- process the request properly. Its format is described in Section
- 20.32. If a UAS does not understand an option-tag listed in a
- Require header field, it MUST respond by generating a response with
- status code 420 (Bad Extension). The UAS MUST add an Unsupported
- header field, and list in it those options it does not understand
- amongst those in the Require header field of the request.
-
-
-
-Rosenberg, et. al. Standards Track [Page 47]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL
- request, or in an ACK request sent for a non-2xx response. These
- header fields MUST be ignored if they are present in these requests.
-
- An ACK request for a 2xx response MUST contain only those Require and
- Proxy-Require values that were present in the initial request.
-
- Example:
-
- UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
- Require: 100rel
-
- UAS->UAC: SIP/2.0 420 Bad Extension
- Unsupported: 100rel
-
- This behavior ensures that the client-server interaction will
- proceed without delay when all options are understood by both
- sides, and only slow down if options are not understood (as in the
- example above). For a well-matched client-server pair, the
- interaction proceeds quickly, saving a round-trip often required
- by negotiation mechanisms. In addition, it also removes ambiguity
- when the client requires features that the server does not
- understand. Some features, such as call handling fields, are only
- of interest to end systems.
-
-8.2.3 Content Processing
-
- Assuming the UAS understands any extensions required by the client,
- the UAS examines the body of the message, and the header fields that
- describe it. If there are any bodies whose type (indicated by the
- Content-Type), language (indicated by the Content-Language) or
- encoding (indicated by the Content-Encoding) are not understood, and
- that body part is not optional (as indicated by the Content-
- Disposition header field), the UAS MUST reject the request with a 415
- (Unsupported Media Type) response. The response MUST contain an
- Accept header field listing the types of all bodies it understands,
- in the event the request contained bodies of types not supported by
- the UAS. If the request contained content encodings not understood
- by the UAS, the response MUST contain an Accept-Encoding header field
- listing the encodings understood by the UAS. If the request
- contained content with languages not understood by the UAS, the
- response MUST contain an Accept-Language header field indicating the
- languages understood by the UAS. Beyond these checks, body handling
- depends on the method and type. For further information on the
- processing of content-specific header fields, see Section 7.4 as well
- as Section 20.11 through 20.15.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 48]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-8.2.4 Applying Extensions
-
- A UAS that wishes to apply some extension when generating the
- response MUST NOT do so unless support for that extension is
- indicated in the Supported header field in the request. If the
- desired extension is not supported, the server SHOULD rely only on
- baseline SIP and any other extensions supported by the client. In
- rare circumstances, where the server cannot process the request
- without the extension, the server MAY send a 421 (Extension Required)
- response. This response indicates that the proper response cannot be
- generated without support of a specific extension. The needed
- extension(s) MUST be included in a Require header field in the
- response. This behavior is NOT RECOMMENDED, as it will generally
- break interoperability.
-
- Any extensions applied to a non-421 response MUST be listed in a
- Require header field included in the response. Of course, the server
- MUST NOT apply extensions not listed in the Supported header field in
- the request. As a result of this, the Require header field in a
- response will only ever contain option tags defined in standards-
- track RFCs.
-
-8.2.5 Processing the Request
-
- Assuming all of the checks in the previous subsections are passed,
- the UAS processing becomes method-specific. Section 10 covers the
- REGISTER request, Section 11 covers the OPTIONS request, Section 13
- covers the INVITE request, and Section 15 covers the BYE request.
-
-8.2.6 Generating the Response
-
- When a UAS wishes to construct a response to a request, it follows
- the general procedures detailed in the following subsections.
- Additional behaviors specific to the response code in question, which
- are not detailed in this section, may also be required.
-
- Once all procedures associated with the creation of a response have
- been completed, the UAS hands the response back to the server
- transaction from which it received the request.
-
-8.2.6.1 Sending a Provisional Response
-
- One largely non-method-specific guideline for the generation of
- responses is that UASs SHOULD NOT issue a provisional response for a
- non-INVITE request. Rather, UASs SHOULD generate a final response to
- a non-INVITE request as soon as possible.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 49]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- When a 100 (Trying) response is generated, any Timestamp header field
- present in the request MUST be copied into this 100 (Trying)
- response. If there is a delay in generating the response, the UAS
- SHOULD add a delay value into the Timestamp value in the response.
- This value MUST contain the difference between the time of sending of
- the response and receipt of the request, measured in seconds.
-
-8.2.6.2 Headers and Tags
-
- The From field of the response MUST equal the From header field of
- the request. The Call-ID header field of the response MUST equal the
- Call-ID header field of the request. The CSeq header field of the
- response MUST equal the CSeq field of the request. The Via header
- field values in the response MUST equal the Via header field values
- in the request and MUST maintain the same ordering.
-
- If a request contained a To tag in the request, the To header field
- in the response MUST equal that of the request. However, if the To
- header field in the request did not contain a tag, the URI in the To
- header field in the response MUST equal the URI in the To header
- field; additionally, the UAS MUST add a tag to the To header field in
- the response (with the exception of the 100 (Trying) response, in
- which a tag MAY be present). This serves to identify the UAS that is
- responding, possibly resulting in a component of a dialog ID. The
- same tag MUST be used for all responses to that request, both final
- and provisional (again excepting the 100 (Trying)). Procedures for
- the generation of tags are defined in Section 19.3.
-
-8.2.7 Stateless UAS Behavior
-
- A stateless UAS is a UAS that does not maintain transaction state.
- It replies to requests normally, but discards any state that would
- ordinarily be retained by a UAS after a response has been sent. If a
- stateless UAS receives a retransmission of a request, it regenerates
- the response and resends it, just as if it were replying to the first
- instance of the request. A UAS cannot be stateless unless the request
- processing for that method would always result in the same response
- if the requests are identical. This rules out stateless registrars,
- for example. Stateless UASs do not use a transaction layer; they
- receive requests directly from the transport layer and send responses
- directly to the transport layer.
-
- The stateless UAS role is needed primarily to handle unauthenticated
- requests for which a challenge response is issued. If
- unauthenticated requests were handled statefully, then malicious
- floods of unauthenticated requests could create massive amounts of
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 50]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- transaction state that might slow or completely halt call processing
- in a UAS, effectively creating a denial of service condition; for
- more information see Section 26.1.5.
-
- The most important behaviors of a stateless UAS are the following:
-
- o A stateless UAS MUST NOT send provisional (1xx) responses.
-
- o A stateless UAS MUST NOT retransmit responses.
-
- o A stateless UAS MUST ignore ACK requests.
-
- o A stateless UAS MUST ignore CANCEL requests.
-
- o To header tags MUST be generated for responses in a stateless
- manner - in a manner that will generate the same tag for the
- same request consistently. For information on tag construction
- see Section 19.3.
-
- In all other respects, a stateless UAS behaves in the same manner as
- a stateful UAS. A UAS can operate in either a stateful or stateless
- mode for each new request.
-
-8.3 Redirect Servers
-
- In some architectures it may be desirable to reduce the processing
- load on proxy servers that are responsible for routing requests, and
- improve signaling path robustness, by relying on redirection.
-
- Redirection allows servers to push routing information for a request
- back in a response to the client, thereby taking themselves out of
- the loop of further messaging for this transaction while still aiding
- in locating the target of the request. When the originator of the
- request receives the redirection, it will send a new request based on
- the URI(s) it has received. By propagating URIs from the core of the
- network to its edges, redirection allows for considerable network
- scalability.
-
- A redirect server is logically constituted of a server transaction
- layer and a transaction user that has access to a location service of
- some kind (see Section 10 for more on registrars and location
- services). This location service is effectively a database
- containing mappings between a single URI and a set of one or more
- alternative locations at which the target of that URI can be found.
-
- A redirect server does not issue any SIP requests of its own. After
- receiving a request other than CANCEL, the server either refuses the
- request or gathers the list of alternative locations from the
-
-
-
-Rosenberg, et. al. Standards Track [Page 51]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- location service and returns a final response of class 3xx. For
- well-formed CANCEL requests, it SHOULD return a 2xx response. This
- response ends the SIP transaction. The redirect server maintains
- transaction state for an entire SIP transaction. It is the
- responsibility of clients to detect forwarding loops between redirect
- servers.
-
- When a redirect server returns a 3xx response to a request, it
- populates the list of (one or more) alternative locations into the
- Contact header field. An "expires" parameter to the Contact header
- field values may also be supplied to indicate the lifetime of the
- Contact data.
-
- The Contact header field contains URIs giving the new locations or
- user names to try, or may simply specify additional transport
- parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily)
- response may also give the same location and username that was
- targeted by the initial request but specify additional transport
- parameters such as a different server or multicast address to try, or
- a change of SIP transport from UDP to TCP or vice versa.
-
- However, redirect servers MUST NOT redirect a request to a URI equal
- to the one in the Request-URI; instead, provided that the URI does
- not point to itself, the server MAY proxy the request to the
- destination URI, or MAY reject it with a 404.
-
- If a client is using an outbound proxy, and that proxy actually
- redirects requests, a potential arises for infinite redirection
- loops.
-
- Note that a Contact header field value MAY also refer to a different
- resource than the one originally called. For example, a SIP call
- connected to PSTN gateway may need to deliver a special informational
- announcement such as "The number you have dialed has been changed."
-
- A Contact response header field can contain any suitable URI
- indicating where the called party can be reached, not limited to SIP
- URIs. For example, it could contain URIs for phones, fax, or irc (if
- they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4
- discusses implications and limitations of redirecting a SIPS URI to a
- non-SIPS URI.
-
- The "expires" parameter of a Contact header field value indicates how
- long the URI is valid. The value of the parameter is a number
- indicating seconds. If this parameter is not provided, the value of
- the Expires header field determines how long the URI is valid.
- Malformed values SHOULD be treated as equivalent to 3600.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 52]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- This provides a modest level of backwards compatibility with RFC
- 2543, which allowed absolute times in this header field. If an
- absolute time is received, it will be treated as malformed, and
- then default to 3600.
-
- Redirect servers MUST ignore features that are not understood
- (including unrecognized header fields, any unknown option tags in
- Require, or even method names) and proceed with the redirection of
- the request in question.
-
-9 Canceling a Request
-
- The previous section has discussed general UA behavior for generating
- requests and processing responses for requests of all methods. In
- this section, we discuss a general purpose method, called CANCEL.
-
- The CANCEL request, as the name implies, is used to cancel a previous
- request sent by a client. Specifically, it asks the UAS to cease
- processing the request and to generate an error response to that
- request. CANCEL has no effect on a request to which a UAS has
- already given a final response. Because of this, it is most useful
- to CANCEL requests to which it can take a server long time to
- respond. For this reason, CANCEL is best for INVITE requests, which
- can take a long time to generate a response. In that usage, a UAS
- that receives a CANCEL request for an INVITE, but has not yet sent a
- final response, would "stop ringing", and then respond to the INVITE
- with a specific error response (a 487).
-
- CANCEL requests can be constructed and sent by both proxies and user
- agent clients. Section 15 discusses under what conditions a UAC
- would CANCEL an INVITE request, and Section 16.10 discusses proxy
- usage of CANCEL.
-
- A stateful proxy responds to a CANCEL, rather than simply forwarding
- a response it would receive from a downstream element. For that
- reason, CANCEL is referred to as a "hop-by-hop" request, since it is
- responded to at each stateful proxy hop.
-
-9.1 Client Behavior
-
- A CANCEL request SHOULD NOT be sent to cancel a request other than
- INVITE.
-
- Since requests other than INVITE are responded to immediately,
- sending a CANCEL for a non-INVITE request would always create a
- race condition.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 53]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The following procedures are used to construct a CANCEL request. The
- Request-URI, Call-ID, To, the numeric part of CSeq, and From header
- fields in the CANCEL request MUST be identical to those in the
- request being cancelled, including tags. A CANCEL constructed by a
- client MUST have only a single Via header field value matching the
- top Via value in the request being cancelled. Using the same values
- for these header fields allows the CANCEL to be matched with the
- request it cancels (Section 9.2 indicates how such matching occurs).
- However, the method part of the CSeq header field MUST have a value
- of CANCEL. This allows it to be identified and processed as a
- transaction in its own right (See Section 17).
-
- If the request being cancelled contains a Route header field, the
- CANCEL request MUST include that Route header field's values.
-
- This is needed so that stateless proxies are able to route CANCEL
- requests properly.
-
- The CANCEL request MUST NOT contain any Require or Proxy-Require
- header fields.
-
- Once the CANCEL is constructed, the client SHOULD check whether it
- has received any response (provisional or final) for the request
- being cancelled (herein referred to as the "original request").
-
- If no provisional response has been received, the CANCEL request MUST
- NOT be sent; rather, the client MUST wait for the arrival of a
- provisional response before sending the request. If the original
- request has generated a final response, the CANCEL SHOULD NOT be
- sent, as it is an effective no-op, since CANCEL has no effect on
- requests that have already generated a final response. When the
- client decides to send the CANCEL, it creates a client transaction
- for the CANCEL and passes it the CANCEL request along with the
- destination address, port, and transport. The destination address,
- port, and transport for the CANCEL MUST be identical to those used to
- send the original request.
-
- If it was allowed to send the CANCEL before receiving a response
- for the previous request, the server could receive the CANCEL
- before the original request.
-
- Note that both the transaction corresponding to the original request
- and the CANCEL transaction will complete independently. However, a
- UAC canceling a request cannot rely on receiving a 487 (Request
- Terminated) response for the original request, as an RFC 2543-
- compliant UAS will not generate such a response. If there is no
- final response for the original request in 64*T1 seconds (T1 is
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 54]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- defined in Section 17.1.1.1), the client SHOULD then consider the
- original transaction cancelled and SHOULD destroy the client
- transaction handling the original request.
-
-9.2 Server Behavior
-
- The CANCEL method requests that the TU at the server side cancel a
- pending transaction. The TU determines the transaction to be
- cancelled by taking the CANCEL request, and then assuming that the
- request method is anything but CANCEL or ACK and applying the
- transaction matching procedures of Section 17.2.3. The matching
- transaction is the one to be cancelled.
-
- The processing of a CANCEL request at a server depends on the type of
- server. A stateless proxy will forward it, a stateful proxy might
- respond to it and generate some CANCEL requests of its own, and a UAS
- will respond to it. See Section 16.10 for proxy treatment of CANCEL.
-
- A UAS first processes the CANCEL request according to the general UAS
- processing described in Section 8.2. However, since CANCEL requests
- are hop-by-hop and cannot be resubmitted, they cannot be challenged
- by the server in order to get proper credentials in an Authorization
- header field. Note also that CANCEL requests do not contain a
- Require header field.
-
- If the UAS did not find a matching transaction for the CANCEL
- according to the procedure above, it SHOULD respond to the CANCEL
- with a 481 (Call Leg/Transaction Does Not Exist). If the transaction
- for the original request still exists, the behavior of the UAS on
- receiving a CANCEL request depends on whether it has already sent a
- final response for the original request. If it has, the CANCEL
- request has no effect on the processing of the original request, no
- effect on any session state, and no effect on the responses generated
- for the original request. If the UAS has not issued a final response
- for the original request, its behavior depends on the method of the
- original request. If the original request was an INVITE, the UAS
- SHOULD immediately respond to the INVITE with a 487 (Request
- Terminated). A CANCEL request has no impact on the processing of
- transactions with any other method defined in this specification.
-
- Regardless of the method of the original request, as long as the
- CANCEL matched an existing transaction, the UAS answers the CANCEL
- request itself with a 200 (OK) response. This response is
- constructed following the procedures described in Section 8.2.6
- noting that the To tag of the response to the CANCEL and the To tag
- in the response to the original request SHOULD be the same. The
- response to CANCEL is passed to the server transaction for
- transmission.
-
-
-
-Rosenberg, et. al. Standards Track [Page 55]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-10 Registrations
-
-10.1 Overview
-
- SIP offers a discovery capability. If a user wants to initiate a
- session with another user, SIP must discover the current host(s) at
- which the destination user is reachable. This discovery process is
- frequently accomplished by SIP network elements such as proxy servers
- and redirect servers which are responsible for receiving a request,
- determining where to send it based on knowledge of the location of
- the user, and then sending it there. To do this, SIP network
- elements consult an abstract service known as a location service,
- which provides address bindings for a particular domain. These
- address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com,
- for example, to one or more URIs that are somehow "closer" to the
- desired user, sip:bob@engineering.biloxi.com, for example.
- Ultimately, a proxy will consult a location service that maps a
- received URI to the user agent(s) at which the desired recipient is
- currently residing.
-
- Registration creates bindings in a location service for a particular
- domain that associates an address-of-record URI with one or more
- contact addresses. Thus, when a proxy for that domain receives a
- request whose Request-URI matches the address-of-record, the proxy
- will forward the request to the contact addresses registered to that
- address-of-record. Generally, it only makes sense to register an
- address-of-record at a domain's location service when requests for
- that address-of-record would be routed to that domain. In most
- cases, this means that the domain of the registration will need to
- match the domain in the URI of the address-of-record.
-
- There are many ways by which the contents of the location service can
- be established. One way is administratively. In the above example,
- Bob is known to be a member of the engineering department through
- access to a corporate database. However, SIP provides a mechanism
- for a UA to create a binding explicitly. This mechanism is known as
- registration.
-
- Registration entails sending a REGISTER request to a special type of
- UAS known as a registrar. A registrar acts as the front end to the
- location service for a domain, reading and writing mappings based on
- the contents of REGISTER requests. This location service is then
- typically consulted by a proxy server that is responsible for routing
- requests for that domain.
-
- An illustration of the overall registration process is given in
- Figure 2. Note that the registrar and proxy server are logical roles
- that can be played by a single device in a network; for purposes of
-
-
-
-Rosenberg, et. al. Standards Track [Page 56]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- clarity the two are separated in this illustration. Also note that
- UAs may send requests through a proxy server in order to reach a
- registrar if the two are separate elements.
-
- SIP does not mandate a particular mechanism for implementing the
- location service. The only requirement is that a registrar for some
- domain MUST be able to read and write data to the location service,
- and a proxy or a redirect server for that domain MUST be capable of
- reading that same data. A registrar MAY be co-located with a
- particular SIP proxy server for the same domain.
-
-10.2 Constructing the REGISTER Request
-
- REGISTER requests add, remove, and query bindings. A REGISTER
- request can add a new binding between an address-of-record and one or
- more contact addresses. Registration on behalf of a particular
- address-of-record can be performed by a suitably authorized third
- party. A client can also remove previous bindings or query to
- determine which bindings are currently in place for an address-of-
- record.
-
- Except as noted, the construction of the REGISTER request and the
- behavior of clients sending a REGISTER request is identical to the
- general UAC behavior described in Section 8.1 and Section 17.1.
-
- A REGISTER request does not establish a dialog. A UAC MAY include a
- Route header field in a REGISTER request based on a pre-existing
- route set as described in Section 8.1. The Record-Route header field
- has no meaning in REGISTER requests or responses, and MUST be ignored
- if present. In particular, the UAC MUST NOT create a new route set
- based on the presence or absence of a Record-Route header field in
- any response to a REGISTER request.
-
- The following header fields, except Contact, MUST be included in a
- REGISTER request. A Contact header field MAY be included:
-
- Request-URI: The Request-URI names the domain of the location
- service for which the registration is meant (for example,
- "sip:chicago.com"). The "userinfo" and "@" components of the
- SIP URI MUST NOT be present.
-
- To: The To header field contains the address of record whose
- registration is to be created, queried, or modified. The To
- header field and the Request-URI field typically differ, as
- the former contains a user name. This address-of-record MUST
- be a SIP URI or SIPS URI.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 57]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- From: The From header field contains the address-of-record of the
- person responsible for the registration. The value is the
- same as the To header field unless the request is a third-
- party registration.
-
- Call-ID: All registrations from a UAC SHOULD use the same Call-ID
- header field value for registrations sent to a particular
- registrar.
-
- If the same client were to use different Call-ID values, a
- registrar could not detect whether a delayed REGISTER request
- might have arrived out of order.
-
- CSeq: The CSeq value guarantees proper ordering of REGISTER
- requests. A UA MUST increment the CSeq value by one for each
- REGISTER request with the same Call-ID.
-
- Contact: REGISTER requests MAY contain a Contact header field with
- zero or more values containing address bindings.
-
- UAs MUST NOT send a new registration (that is, containing new Contact
- header field values, as opposed to a retransmission) until they have
- received a final response from the registrar for the previous one or
- the previous REGISTER request has timed out.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 58]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- bob
- +----+
- | UA |
- | |
- +----+
- |
- |3)INVITE
- | carol@chicago.com
- chicago.com +--------+ V
- +---------+ 2)Store|Location|4)Query +-----+
- |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
- +---------+ +--------+=======>+-----+
- A 5)Resp |
- | |
- | |
- 1)REGISTER| |
- | |
- +----+ |
- | UA |<-------------------------------+
- cube2214a| | 6)INVITE
- +----+ carol@cube2214a.chicago.com
- carol
-
- Figure 2: REGISTER example
-
- The following Contact header parameters have a special meaning in
- REGISTER requests:
-
- action: The "action" parameter from RFC 2543 has been deprecated.
- UACs SHOULD NOT use the "action" parameter.
-
- expires: The "expires" parameter indicates how long the UA would
- like the binding to be valid. The value is a number
- indicating seconds. If this parameter is not provided, the
- value of the Expires header field is used instead.
- Implementations MAY treat values larger than 2**32-1
- (4294967295 seconds or 136 years) as equivalent to 2**32-1.
- Malformed values SHOULD be treated as equivalent to 3600.
-
-10.2.1 Adding Bindings
-
- The REGISTER request sent to a registrar includes the contact
- address(es) to which SIP requests for the address-of-record should be
- forwarded. The address-of-record is included in the To header field
- of the REGISTER request.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 59]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The Contact header field values of the request typically consist of
- SIP or SIPS URIs that identify particular SIP endpoints (for example,
- "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme.
- A SIP UA can choose to register telephone numbers (with the tel URL,
- RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
- as Contacts for an address-of-record, for example.
-
- For example, Carol, with address-of-record "sip:carol@chicago.com",
- would register with the SIP registrar of the domain chicago.com. Her
- registrations would then be used by a proxy server in the chicago.com
- domain to route requests for Carol's address-of-record to her SIP
- endpoint.
-
- Once a client has established bindings at a registrar, it MAY send
- subsequent registrations containing new bindings or modifications to
- existing bindings as necessary. The 2xx response to the REGISTER
- request will contain, in a Contact header field, a complete list of
- bindings that have been registered for this address-of-record at this
- registrar.
-
- If the address-of-record in the To header field of a REGISTER request
- is a SIPS URI, then any Contact header field values in the request
- SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs
- under a SIPS address-of-record when the security of the resource
- represented by the contact address is guaranteed by other means.
- This may be applicable to URIs that invoke protocols other than SIP,
- or SIP devices secured by protocols other than TLS.
-
- Registrations do not need to update all bindings. Typically, a UA
- only updates its own contact addresses.
-
-10.2.1.1 Setting the Expiration Interval of Contact Addresses
-
- When a client sends a REGISTER request, it MAY suggest an expiration
- interval that indicates how long the client would like the
- registration to be valid. (As described in Section 10.3, the
- registrar selects the actual time interval based on its local
- policy.)
-
- There are two ways in which a client can suggest an expiration
- interval for a binding: through an Expires header field or an
- "expires" Contact header parameter. The latter allows expiration
- intervals to be suggested on a per-binding basis when more than one
- binding is given in a single REGISTER request, whereas the former
- suggests an expiration interval for all Contact header field values
- that do not contain the "expires" parameter.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 60]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- If neither mechanism for expressing a suggested expiration time is
- present in a REGISTER, the client is indicating its desire for the
- server to choose.
-
-10.2.1.2 Preferences among Contact Addresses
-
- If more than one Contact is sent in a REGISTER request, the
- registering UA intends to associate all of the URIs in these Contact
- header field values with the address-of-record present in the To
- field. This list can be prioritized with the "q" parameter in the
- Contact header field. The "q" parameter indicates a relative
- preference for the particular Contact header field value compared to
- other bindings for this address-of-record. Section 16.6 describes
- how a proxy server uses this preference indication.
-
-10.2.2 Removing Bindings
-
- Registrations are soft state and expire unless refreshed, but can
- also be explicitly removed. A client can attempt to influence the
- expiration interval selected by the registrar as described in Section
- 10.2.1. A UA requests the immediate removal of a binding by
- specifying an expiration interval of "0" for that contact address in
- a REGISTER request. UAs SHOULD support this mechanism so that
- bindings can be removed before their expiration interval has passed.
-
- The REGISTER-specific Contact header field value of "*" applies to
- all registrations, but it MUST NOT be used unless the Expires header
- field is present with a value of "0".
-
- Use of the "*" Contact header field value allows a registering UA
- to remove all bindings associated with an address-of-record
- without knowing their precise values.
-
-10.2.3 Fetching Bindings
-
- A success response to any REGISTER request contains the complete list
- of existing bindings, regardless of whether the request contained a
- Contact header field. If no Contact header field is present in a
- REGISTER request, the list of bindings is left unchanged.
-
-10.2.4 Refreshing Bindings
-
- Each UA is responsible for refreshing the bindings that it has
- previously established. A UA SHOULD NOT refresh bindings set up by
- other UAs.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 61]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The 200 (OK) response from the registrar contains a list of Contact
- fields enumerating all current bindings. The UA compares each
- contact address to see if it created the contact address, using
- comparison rules in Section 19.1.4. If so, it updates the expiration
- time interval according to the expires parameter or, if absent, the
- Expires field value. The UA then issues a REGISTER request for each
- of its bindings before the expiration interval has elapsed. It MAY
- combine several updates into one REGISTER request.
-
- A UA SHOULD use the same Call-ID for all registrations during a
- single boot cycle. Registration refreshes SHOULD be sent to the same
- network address as the original registration, unless redirected.
-
-10.2.5 Setting the Internal Clock
-
- If the response for a REGISTER request contains a Date header field,
- the client MAY use this header field to learn the current time in
- order to set any internal clocks.
-
-10.2.6 Discovering a Registrar
-
- UAs can use three ways to determine the address to which to send
- registrations: by configuration, using the address-of-record, and
- multicast. A UA can be configured, in ways beyond the scope of this
- specification, with a registrar address. If there is no configured
- registrar address, the UA SHOULD use the host part of the address-
- of-record as the Request-URI and address the request there, using the
- normal SIP server location mechanisms [4]. For example, the UA for
- the user "sip:carol@chicago.com" addresses the REGISTER request to
- "sip:chicago.com".
-
- Finally, a UA can be configured to use multicast. Multicast
- registrations are addressed to the well-known "all SIP servers"
- multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well-
- known IPv6 multicast address has been allocated; such an allocation
- will be documented separately when needed. SIP UAs MAY listen to
- that address and use it to become aware of the location of other
- local users (see [33]); however, they do not respond to the request.
-
- Multicast registration may be inappropriate in some environments,
- for example, if multiple businesses share the same local area
- network.
-
-10.2.7 Transmitting a Request
-
- Once the REGISTER method has been constructed, and the destination of
- the message identified, UACs follow the procedures described in
- Section 8.1.2 to hand off the REGISTER to the transaction layer.
-
-
-
-Rosenberg, et. al. Standards Track [Page 62]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- If the transaction layer returns a timeout error because the REGISTER
- yielded no response, the UAC SHOULD NOT immediately re-attempt a
- registration to the same registrar.
-
- An immediate re-attempt is likely to also timeout. Waiting some
- reasonable time interval for the conditions causing the timeout to
- be corrected reduces unnecessary load on the network. No specific
- interval is mandated.
-
-10.2.8 Error Responses
-
- If a UA receives a 423 (Interval Too Brief) response, it MAY retry
- the registration after making the expiration interval of all contact
- addresses in the REGISTER request equal to or greater than the
- expiration interval within the Min-Expires header field of the 423
- (Interval Too Brief) response.
-
-10.3 Processing REGISTER Requests
-
- A registrar is a UAS that responds to REGISTER requests and maintains
- a list of bindings that are accessible to proxy servers and redirect
- servers within its administrative domain. A registrar handles
- requests according to Section 8.2 and Section 17.2, but it accepts
- only REGISTER requests. A registrar MUST not generate 6xx responses.
-
- A registrar MAY redirect REGISTER requests as appropriate. One
- common usage would be for a registrar listening on a multicast
- interface to redirect multicast REGISTER requests to its own unicast
- interface with a 302 (Moved Temporarily) response.
-
- Registrars MUST ignore the Record-Route header field if it is
- included in a REGISTER request. Registrars MUST NOT include a
- Record-Route header field in any response to a REGISTER request.
-
- A registrar might receive a request that traversed a proxy which
- treats REGISTER as an unknown request and which added a Record-
- Route header field value.
-
- A registrar has to know (for example, through configuration) the set
- of domain(s) for which it maintains bindings. REGISTER requests MUST
- be processed by a registrar in the order that they are received.
- REGISTER requests MUST also be processed atomically, meaning that a
- particular REGISTER request is either processed completely or not at
- all. Each REGISTER message MUST be processed independently of any
- other registration or binding changes.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 63]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- When receiving a REGISTER request, a registrar follows these steps:
-
- 1. The registrar inspects the Request-URI to determine whether it
- has access to bindings for the domain identified in the
- Request-URI. If not, and if the server also acts as a proxy
- server, the server SHOULD forward the request to the addressed
- domain, following the general behavior for proxying messages
- described in Section 16.
-
- 2. To guarantee that the registrar supports any necessary
- extensions, the registrar MUST process the Require header field
- values as described for UASs in Section 8.2.2.
-
- 3. A registrar SHOULD authenticate the UAC. Mechanisms for the
- authentication of SIP user agents are described in Section 22.
- Registration behavior in no way overrides the generic
- authentication framework for SIP. If no authentication
- mechanism is available, the registrar MAY take the From address
- as the asserted identity of the originator of the request.
-
- 4. The registrar SHOULD determine if the authenticated user is
- authorized to modify registrations for this address-of-record.
- For example, a registrar might consult an authorization
- database that maps user names to a list of addresses-of-record
- for which that user has authorization to modify bindings. If
- the authenticated user is not authorized to modify bindings,
- the registrar MUST return a 403 (Forbidden) and skip the
- remaining steps.
-
- In architectures that support third-party registration, one
- entity may be responsible for updating the registrations
- associated with multiple addresses-of-record.
-
- 5. The registrar extracts the address-of-record from the To header
- field of the request. If the address-of-record is not valid
- for the domain in the Request-URI, the registrar MUST send a
- 404 (Not Found) response and skip the remaining steps. The URI
- MUST then be converted to a canonical form. To do that, all
- URI parameters MUST be removed (including the user-param), and
- any escaped characters MUST be converted to their unescaped
- form. The result serves as an index into the list of bindings.
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 64]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 6. The registrar checks whether the request contains the Contact
- header field. If not, it skips to the last step. If the
- Contact header field is present, the registrar checks if there
- is one Contact field value that contains the special value "*"
- and an Expires field. If the request has additional Contact
- fields or an expiration time other than zero, the request is
- invalid, and the server MUST return a 400 (Invalid Request) and
- skip the remaining steps. If not, the registrar checks whether
- the Call-ID agrees with the value stored for each binding. If
- not, it MUST remove the binding. If it does agree, it MUST
- remove the binding only if the CSeq in the request is higher
- than the value stored for that binding. Otherwise, the update
- MUST be aborted and the request fails.
-
- 7. The registrar now processes each contact address in the Contact
- header field in turn. For each address, it determines the
- expiration interval as follows:
-
- - If the field value has an "expires" parameter, that value
- MUST be taken as the requested expiration.
-
- - If there is no such parameter, but the request has an
- Expires header field, that value MUST be taken as the
- requested expiration.
-
- - If there is neither, a locally-configured default value MUST
- be taken as the requested expiration.
-
- The registrar MAY choose an expiration less than the requested
- expiration interval. If and only if the requested expiration
- interval is greater than zero AND smaller than one hour AND
- less than a registrar-configured minimum, the registrar MAY
- reject the registration with a response of 423 (Interval Too
- Brief). This response MUST contain a Min-Expires header field
- that states the minimum expiration interval the registrar is
- willing to honor. It then skips the remaining steps.
-
- Allowing the registrar to set the registration interval
- protects it against excessively frequent registration refreshes
- while limiting the state that it needs to maintain and
- decreasing the likelihood of registrations going stale. The
- expiration interval of a registration is frequently used in the
- creation of services. An example is a follow-me service, where
- the user may only be available at a terminal for a brief
- period. Therefore, registrars should accept brief
- registrations; a request should only be rejected if the
- interval is so short that the refreshes would degrade registrar
- performance.
-
-
-
-Rosenberg, et. al. Standards Track [Page 65]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- For each address, the registrar then searches the list of
- current bindings using the URI comparison rules. If the
- binding does not exist, it is tentatively added. If the
- binding does exist, the registrar checks the Call-ID value. If
- the Call-ID value in the existing binding differs from the
- Call-ID value in the request, the binding MUST be removed if
- the expiration time is zero and updated otherwise. If they are
- the same, the registrar compares the CSeq value. If the value
- is higher than that of the existing binding, it MUST update or
- remove the binding as above. If not, the update MUST be
- aborted and the request fails.
-
- This algorithm ensures that out-of-order requests from the same
- UA are ignored.
-
- Each binding record records the Call-ID and CSeq values from
- the request.
-
- The binding updates MUST be committed (that is, made visible to
- the proxy or redirect server) if and only if all binding
- updates and additions succeed. If any one of them fails (for
- example, because the back-end database commit failed), the
- request MUST fail with a 500 (Server Error) response and all
- tentative binding updates MUST be removed.
-
- 8. The registrar returns a 200 (OK) response. The response MUST
- contain Contact header field values enumerating all current
- bindings. Each Contact value MUST feature an "expires"
- parameter indicating its expiration interval chosen by the
- registrar. The response SHOULD include a Date header field.
-
-11 Querying for Capabilities
-
- The SIP method OPTIONS allows a UA to query another UA or a proxy
- server as to its capabilities. This allows a client to discover
- information about the supported methods, content types, extensions,
- codecs, etc. without "ringing" the other party. For example, before
- a client inserts a Require header field into an INVITE listing an
- option that it is not certain the destination UAS supports, the
- client can query the destination UAS with an OPTIONS to see if this
- option is returned in a Supported header field. All UAs MUST support
- the OPTIONS method.
-
- The target of the OPTIONS request is identified by the Request-URI,
- which could identify another UA or a SIP server. If the OPTIONS is
- addressed to a proxy server, the Request-URI is set without a user
- part, similar to the way a Request-URI is set for a REGISTER request.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 66]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Alternatively, a server receiving an OPTIONS request with a Max-
- Forwards header field value of 0 MAY respond to the request
- regardless of the Request-URI.
-
- This behavior is common with HTTP/1.1. This behavior can be used
- as a "traceroute" functionality to check the capabilities of
- individual hop servers by sending a series of OPTIONS requests
- with incremented Max-Forwards values.
-
- As is the case for general UA behavior, the transaction layer can
- return a timeout error if the OPTIONS yields no response. This may
- indicate that the target is unreachable and hence unavailable.
-
- An OPTIONS request MAY be sent as part of an established dialog to
- query the peer on capabilities that may be utilized later in the
- dialog.
-
-11.1 Construction of OPTIONS Request
-
- An OPTIONS request is constructed using the standard rules for a SIP
- request as discussed in Section 8.1.1.
-
- A Contact header field MAY be present in an OPTIONS.
-
- An Accept header field SHOULD be included to indicate the type of
- message body the UAC wishes to receive in the response. Typically,
- this is set to a format that is used to describe the media
- capabilities of a UA, such as SDP (application/sdp).
-
- The response to an OPTIONS request is assumed to be scoped to the
- Request-URI in the original request. However, only when an OPTIONS
- is sent as part of an established dialog is it guaranteed that future
- requests will be received by the server that generated the OPTIONS
- response.
-
- Example OPTIONS request:
-
- OPTIONS sip:carol@chicago.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
- Max-Forwards: 70
- To: <sip:carol@chicago.com>
- From: Alice <sip:alice@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710
- CSeq: 63104 OPTIONS
- Contact: <sip:alice@pc33.atlanta.com>
- Accept: application/sdp
- Content-Length: 0
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 67]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-11.2 Processing of OPTIONS Request
-
- The response to an OPTIONS is constructed using the standard rules
- for a SIP response as discussed in Section 8.2.6. The response code
- chosen MUST be the same that would have been chosen had the request
- been an INVITE. That is, a 200 (OK) would be returned if the UAS is
- ready to accept a call, a 486 (Busy Here) would be returned if the
- UAS is busy, etc. This allows an OPTIONS request to be used to
- determine the basic state of a UAS, which can be an indication of
- whether the UAS will accept an INVITE request.
-
- An OPTIONS request received within a dialog generates a 200 (OK)
- response that is identical to one constructed outside a dialog and
- does not have any impact on the dialog.
-
- This use of OPTIONS has limitations due to the differences in proxy
- handling of OPTIONS and INVITE requests. While a forked INVITE can
- result in multiple 200 (OK) responses being returned, a forked
- OPTIONS will only result in a single 200 (OK) response, since it is
- treated by proxies using the non-INVITE handling. See Section 16.7
- for the normative details.
-
- If the response to an OPTIONS is generated by a proxy server, the
- proxy returns a 200 (OK), listing the capabilities of the server.
- The response does not contain a message body.
-
- Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
- fields SHOULD be present in a 200 (OK) response to an OPTIONS
- request. If the response is generated by a proxy, the Allow header
- field SHOULD be omitted as it is ambiguous since a proxy is method
- agnostic. Contact header fields MAY be present in a 200 (OK)
- response and have the same semantics as in a 3xx response. That is,
- they may list a set of alternative names and methods of reaching the
- user. A Warning header field MAY be present.
-
- A message body MAY be sent, the type of which is determined by the
- Accept header field in the OPTIONS request (application/sdp is the
- default if the Accept header field is not present). If the types
- include one that can describe media capabilities, the UAS SHOULD
- include a body in the response for that purpose. Details on the
- construction of such a body in the case of application/sdp are
- described in [13].
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 68]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Example OPTIONS response generated by a UAS (corresponding to the
- request in Section 11.1):
-
- SIP/2.0 200 OK
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
- ;received=192.0.2.4
- To: <sip:carol@chicago.com>;tag=93810874
- From: Alice <sip:alice@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710
- CSeq: 63104 OPTIONS
- Contact: <sip:carol@chicago.com>
- Contact: <mailto:carol@chicago.com>
- Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
- Accept: application/sdp
- Accept-Encoding: gzip
- Accept-Language: en
- Supported: foo
- Content-Type: application/sdp
- Content-Length: 274
-
- (SDP not shown)
-
-12 Dialogs
-
- A key concept for a user agent is that of a dialog. A dialog
- represents a peer-to-peer SIP relationship between two user agents
- that persists for some time. The dialog facilitates sequencing of
- messages between the user agents and proper routing of requests
- between both of them. The dialog represents a context in which to
- interpret SIP messages. Section 8 discussed method independent UA
- processing for requests and responses outside of a dialog. This
- section discusses how those requests and responses are used to
- construct a dialog, and then how subsequent requests and responses
- are sent within a dialog.
-
- A dialog is identified at each UA with a dialog ID, which consists of
- a Call-ID value, a local tag and a remote tag. The dialog ID at each
- UA involved in the dialog is not the same. Specifically, the local
- tag at one UA is identical to the remote tag at the peer UA. The
- tags are opaque tokens that facilitate the generation of unique
- dialog IDs.
-
- A dialog ID is also associated with all responses and with any
- request that contains a tag in the To field. The rules for computing
- the dialog ID of a message depend on whether the SIP element is a UAC
- or UAS. For a UAC, the Call-ID value of the dialog ID is set to the
- Call-ID of the message, the remote tag is set to the tag in the To
- field of the message, and the local tag is set to the tag in the From
-
-
-
-Rosenberg, et. al. Standards Track [Page 69]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- field of the message (these rules apply to both requests and
- responses). As one would expect for a UAS, the Call-ID value of the
- dialog ID is set to the Call-ID of the message, the remote tag is set
- to the tag in the From field of the message, and the local tag is set
- to the tag in the To field of the message.
-
- A dialog contains certain pieces of state needed for further message
- transmissions within the dialog. This state consists of the dialog
- ID, a local sequence number (used to order requests from the UA to
- its peer), a remote sequence number (used to order requests from its
- peer to the UA), a local URI, a remote URI, remote target, a boolean
- flag called "secure", and a route set, which is an ordered list of
- URIs. The route set is the list of servers that need to be traversed
- to send a request to the peer. A dialog can also be in the "early"
- state, which occurs when it is created with a provisional response,
- and then transition to the "confirmed" state when a 2xx final
- response arrives. For other responses, or if no response arrives at
- all on that dialog, the early dialog terminates.
-
-12.1 Creation of a Dialog
-
- Dialogs are created through the generation of non-failure responses
- to requests with specific methods. Within this specification, only
- 2xx and 101-199 responses with a To tag, where the request was
- INVITE, will establish a dialog. A dialog established by a non-final
- response to a request is in the "early" state and it is called an
- early dialog. Extensions MAY define other means for creating
- dialogs. Section 13 gives more details that are specific to the
- INVITE method. Here, we describe the process for creation of dialog
- state that is not dependent on the method.
-
- UAs MUST assign values to the dialog ID components as described
- below.
-
-12.1.1 UAS behavior
-
- When a UAS responds to a request with a response that establishes a
- dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
- header field values from the request into the response (including the
- URIs, URI parameters, and any Record-Route header field parameters,
- whether they are known or unknown to the UAS) and MUST maintain the
- order of those values. The UAS MUST add a Contact header field to
- the response. The Contact header field contains an address where the
- UAS would like to be contacted for subsequent requests in the dialog
- (which includes the ACK for a 2xx response in the case of an INVITE).
- Generally, the host portion of this URI is the IP address or FQDN of
- the host. The URI provided in the Contact header field MUST be a SIP
- or SIPS URI. If the request that initiated the dialog contained a
-
-
-
-Rosenberg, et. al. Standards Track [Page 70]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- SIPS URI in the Request-URI or in the top Record-Route header field
- value, if there was any, or the Contact header field if there was no
- Record-Route header field, the Contact header field in the response
- MUST be a SIPS URI. The URI SHOULD have global scope (that is, the
- same URI can be used in messages outside this dialog). The same way,
- the scope of the URI in the Contact header field of the INVITE is not
- limited to this dialog either. It can therefore be used in messages
- to the UAC even outside this dialog.
-
- The UAS then constructs the state of the dialog. This state MUST be
- maintained for the duration of the dialog.
-
- If the request arrived over TLS, and the Request-URI contained a SIPS
- URI, the "secure" flag is set to TRUE.
-
- The route set MUST be set to the list of URIs in the Record-Route
- header field from the request, taken in order and preserving all URI
- parameters. If no Record-Route header field is present in the
- request, the route set MUST be set to the empty set. This route set,
- even if empty, overrides any pre-existing route set for future
- requests in this dialog. The remote target MUST be set to the URI
- from the Contact header field of the request.
-
- The remote sequence number MUST be set to the value of the sequence
- number in the CSeq header field of the request. The local sequence
- number MUST be empty. The call identifier component of the dialog ID
- MUST be set to the value of the Call-ID in the request. The local
- tag component of the dialog ID MUST be set to the tag in the To field
- in the response to the request (which always includes a tag), and the
- remote tag component of the dialog ID MUST be set to the tag from the
- From field in the request. A UAS MUST be prepared to receive a
- request without a tag in the From field, in which case the tag is
- considered to have a value of null.
-
- This is to maintain backwards compatibility with RFC 2543, which
- did not mandate From tags.
-
- The remote URI MUST be set to the URI in the From field, and the
- local URI MUST be set to the URI in the To field.
-
-12.1.2 UAC Behavior
-
- When a UAC sends a request that can establish a dialog (such as an
- INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,
- the same SIP URI can be used in messages outside this dialog) in the
- Contact header field of the request. If the request has a Request-
- URI or a topmost Route header field value with a SIPS URI, the
- Contact header field MUST contain a SIPS URI.
-
-
-
-Rosenberg, et. al. Standards Track [Page 71]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- When a UAC receives a response that establishes a dialog, it
- constructs the state of the dialog. This state MUST be maintained
- for the duration of the dialog.
-
- If the request was sent over TLS, and the Request-URI contained a
- SIPS URI, the "secure" flag is set to TRUE.
-
- The route set MUST be set to the list of URIs in the Record-Route
- header field from the response, taken in reverse order and preserving
- all URI parameters. If no Record-Route header field is present in
- the response, the route set MUST be set to the empty set. This route
- set, even if empty, overrides any pre-existing route set for future
- requests in this dialog. The remote target MUST be set to the URI
- from the Contact header field of the response.
-
- The local sequence number MUST be set to the value of the sequence
- number in the CSeq header field of the request. The remote sequence
- number MUST be empty (it is established when the remote UA sends a
- request within the dialog). The call identifier component of the
- dialog ID MUST be set to the value of the Call-ID in the request.
- The local tag component of the dialog ID MUST be set to the tag in
- the From field in the request, and the remote tag component of the
- dialog ID MUST be set to the tag in the To field of the response. A
- UAC MUST be prepared to receive a response without a tag in the To
- field, in which case the tag is considered to have a value of null.
-
- This is to maintain backwards compatibility with RFC 2543, which
- did not mandate To tags.
-
- The remote URI MUST be set to the URI in the To field, and the local
- URI MUST be set to the URI in the From field.
-
-12.2 Requests within a Dialog
-
- Once a dialog has been established between two UAs, either of them
- MAY initiate new transactions as needed within the dialog. The UA
- sending the request will take the UAC role for the transaction. The
- UA receiving the request will take the UAS role. Note that these may
- be different roles than the UAs held during the transaction that
- established the dialog.
-
- Requests within a dialog MAY contain Record-Route and Contact header
- fields. However, these requests do not cause the dialog's route set
- to be modified, although they may modify the remote target URI.
- Specifically, requests that are not target refresh requests do not
- modify the dialog's remote target URI, and requests that are target
- refresh requests do. For dialogs that have been established with an
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 72]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- INVITE, the only target refresh request defined is re-INVITE (see
- Section 14). Other extensions may define different target refresh
- requests for dialogs established in other ways.
-
- Note that an ACK is NOT a target refresh request.
-
- Target refresh requests only update the dialog's remote target URI,
- and not the route set formed from the Record-Route. Updating the
- latter would introduce severe backwards compatibility problems with
- RFC 2543-compliant systems.
-
-12.2.1 UAC Behavior
-
-12.2.1.1 Generating the Request
-
- A request within a dialog is constructed by using many of the
- components of the state stored as part of the dialog.
-
- The URI in the To field of the request MUST be set to the remote URI
- from the dialog state. The tag in the To header field of the request
- MUST be set to the remote tag of the dialog ID. The From URI of the
- request MUST be set to the local URI from the dialog state. The tag
- in the From header field of the request MUST be set to the local tag
- of the dialog ID. If the value of the remote or local tags is null,
- the tag parameter MUST be omitted from the To or From header fields,
- respectively.
-
- Usage of the URI from the To and From fields in the original
- request within subsequent requests is done for backwards
- compatibility with RFC 2543, which used the URI for dialog
- identification. In this specification, only the tags are used for
- dialog identification. It is expected that mandatory reflection
- of the original To and From URI in mid-dialog requests will be
- deprecated in a subsequent revision of this specification.
-
- The Call-ID of the request MUST be set to the Call-ID of the dialog.
- Requests within a dialog MUST contain strictly monotonically
- increasing and contiguous CSeq sequence numbers (increasing-by-one)
- in each direction (excepting ACK and CANCEL of course, whose numbers
- equal the requests being acknowledged or cancelled). Therefore, if
- the local sequence number is not empty, the value of the local
- sequence number MUST be incremented by one, and this value MUST be
- placed into the CSeq header field. If the local sequence number is
- empty, an initial value MUST be chosen using the guidelines of
- Section 8.1.1.5. The method field in the CSeq header field value
- MUST match the method of the request.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 73]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- With a length of 32 bits, a client could generate, within a single
- call, one request a second for about 136 years before needing to
- wrap around. The initial value of the sequence number is chosen
- so that subsequent requests within the same call will not wrap
- around. A non-zero initial value allows clients to use a time-
- based initial sequence number. A client could, for example,
- choose the 31 most significant bits of a 32-bit second clock as an
- initial sequence number.
-
- The UAC uses the remote target and route set to build the Request-URI
- and Route header field of the request.
-
- If the route set is empty, the UAC MUST place the remote target URI
- into the Request-URI. The UAC MUST NOT add a Route header field to
- the request.
-
- If the route set is not empty, and the first URI in the route set
- contains the lr parameter (see Section 19.1.1), the UAC MUST place
- the remote target URI into the Request-URI and MUST include a Route
- header field containing the route set values in order, including all
- parameters.
-
- If the route set is not empty, and its first URI does not contain the
- lr parameter, the UAC MUST place the first URI from the route set
- into the Request-URI, stripping any parameters that are not allowed
- in a Request-URI. The UAC MUST add a Route header field containing
- the remainder of the route set values in order, including all
- parameters. The UAC MUST then place the remote target URI into the
- Route header field as the last value.
-
- For example, if the remote target is sip:user@remoteua and the route
- set contains:
-
- <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
-
- The request will be formed with the following Request-URI and Route
- header field:
-
- METHOD sip:proxy1
- Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
-
- If the first URI of the route set does not contain the lr
- parameter, the proxy indicated does not understand the routing
- mechanisms described in this document and will act as specified in
- RFC 2543, replacing the Request-URI with the first Route header
- field value it receives while forwarding the message. Placing the
- Request-URI at the end of the Route header field preserves the
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 74]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- information in that Request-URI across the strict router (it will
- be returned to the Request-URI when the request reaches a loose-
- router).
-
- A UAC SHOULD include a Contact header field in any target refresh
- requests within a dialog, and unless there is a need to change it,
- the URI SHOULD be the same as used in previous requests within the
- dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.
- As discussed in Section 12.2.2, a Contact header field in a target
- refresh request updates the remote target URI. This allows a UA to
- provide a new contact address, should its address change during the
- duration of the dialog.
-
- However, requests that are not target refresh requests do not affect
- the remote target URI for the dialog.
-
- The rest of the request is formed as described in Section 8.1.1.
-
- Once the request has been constructed, the address of the server is
- computed and the request is sent, using the same procedures for
- requests outside of a dialog (Section 8.1.2).
-
- The procedures in Section 8.1.2 will normally result in the
- request being sent to the address indicated by the topmost Route
- header field value or the Request-URI if no Route header field is
- present. Subject to certain restrictions, they allow the request
- to be sent to an alternate address (such as a default outbound
- proxy not represented in the route set).
-
-12.2.1.2 Processing the Responses
-
- The UAC will receive responses to the request from the transaction
- layer. If the client transaction returns a timeout, this is treated
- as a 408 (Request Timeout) response.
-
- The behavior of a UAC that receives a 3xx response for a request sent
- within a dialog is the same as if the request had been sent outside a
- dialog. This behavior is described in Section 8.1.3.4.
-
- Note, however, that when the UAC tries alternative locations, it
- still uses the route set for the dialog to build the Route header
- of the request.
-
- When a UAC receives a 2xx response to a target refresh request, it
- MUST replace the dialog's remote target URI with the URI from the
- Contact header field in that response, if present.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 75]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- If the response for a request within a dialog is a 481
- (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
- SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if
- no response at all is received for the request (the client
- transaction would inform the TU about the timeout.)
-
- For INVITE initiated dialogs, terminating the dialog consists of
- sending a BYE.
-
-12.2.2 UAS Behavior
-
- Requests sent within a dialog, as any other requests, are atomic. If
- a particular request is accepted by the UAS, all the state changes
- associated with it are performed. If the request is rejected, none
- of the state changes are performed.
-
- Note that some requests, such as INVITEs, affect several pieces of
- state.
-
- The UAS will receive the request from the transaction layer. If the
- request has a tag in the To header field, the UAS core computes the
- dialog identifier corresponding to the request and compares it with
- existing dialogs. If there is a match, this is a mid-dialog request.
- In that case, the UAS first applies the same processing rules for
- requests outside of a dialog, discussed in Section 8.2.
-
- If the request has a tag in the To header field, but the dialog
- identifier does not match any existing dialogs, the UAS may have
- crashed and restarted, or it may have received a request for a
- different (possibly failed) UAS (the UASs can construct the To tags
- so that a UAS can identify that the tag was for a UAS for which it is
- providing recovery). Another possibility is that the incoming
- request has been simply misrouted. Based on the To tag, the UAS MAY
- either accept or reject the request. Accepting the request for
- acceptable To tags provides robustness, so that dialogs can persist
- even through crashes. UAs wishing to support this capability must
- take into consideration some issues such as choosing monotonically
- increasing CSeq sequence numbers even across reboots, reconstructing
- the route set, and accepting out-of-range RTP timestamps and sequence
- numbers.
-
- If the UAS wishes to reject the request because it does not wish to
- recreate the dialog, it MUST respond to the request with a 481
- (Call/Transaction Does Not Exist) status code and pass that to the
- server transaction.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 76]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Requests that do not change in any way the state of a dialog may be
- received within a dialog (for example, an OPTIONS request). They are
- processed as if they had been received outside the dialog.
-
- If the remote sequence number is empty, it MUST be set to the value
- of the sequence number in the CSeq header field value in the request.
- If the remote sequence number was not empty, but the sequence number
- of the request is lower than the remote sequence number, the request
- is out of order and MUST be rejected with a 500 (Server Internal
- Error) response. If the remote sequence number was not empty, and
- the sequence number of the request is greater than the remote
- sequence number, the request is in order. It is possible for the
- CSeq sequence number to be higher than the remote sequence number by
- more than one. This is not an error condition, and a UAS SHOULD be
- prepared to receive and process requests with CSeq values more than
- one higher than the previous received request. The UAS MUST then set
- the remote sequence number to the value of the sequence number in the
- CSeq header field value in the request.
-
- If a proxy challenges a request generated by the UAC, the UAC has
- to resubmit the request with credentials. The resubmitted request
- will have a new CSeq number. The UAS will never see the first
- request, and thus, it will notice a gap in the CSeq number space.
- Such a gap does not represent any error condition.
-
- When a UAS receives a target refresh request, it MUST replace the
- dialog's remote target URI with the URI from the Contact header field
- in that request, if present.
-
-12.3 Termination of a Dialog
-
- Independent of the method, if a request outside of a dialog generates
- a non-2xx final response, any early dialogs created through
- provisional responses to that request are terminated. The mechanism
- for terminating confirmed dialogs is method specific. In this
- specification, the BYE method terminates a session and the dialog
- associated with it. See Section 15 for details.
-
-13 Initiating a Session
-
-13.1 Overview
-
- When a user agent client desires to initiate a session (for example,
- audio, video, or a game), it formulates an INVITE request. The
- INVITE request asks a server to establish a session. This request
- may be forwarded by proxies, eventually arriving at one or more UAS
- that can potentially accept the invitation. These UASs will
- frequently need to query the user about whether to accept the
-
-
-
-Rosenberg, et. al. Standards Track [Page 77]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- invitation. After some time, those UASs can accept the invitation
- (meaning the session is to be established) by sending a 2xx response.
- If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is
- sent, depending on the reason for the rejection. Before sending a
- final response, the UAS can also send provisional responses (1xx) to
- advise the UAC of progress in contacting the called user.
-
- After possibly receiving one or more provisional responses, the UAC
- will get one or more 2xx responses or one non-2xx final response.
- Because of the protracted amount of time it can take to receive final
- responses to INVITE, the reliability mechanisms for INVITE
- transactions differ from those of other requests (like OPTIONS).
- Once it receives a final response, the UAC needs to send an ACK for
- every final response it receives. The procedure for sending this ACK
- depends on the type of response. For final responses between 300 and
- 699, the ACK processing is done in the transaction layer and follows
- one set of rules (See Section 17). For 2xx responses, the ACK is
- generated by the UAC core.
-
- A 2xx response to an INVITE establishes a session, and it also
- creates a dialog between the UA that issued the INVITE and the UA
- that generated the 2xx response. Therefore, when multiple 2xx
- responses are received from different remote UAs (because the INVITE
- forked), each 2xx establishes a different dialog. All these dialogs
- are part of the same call.
-
- This section provides details on the establishment of a session using
- INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and
- BYE.
-
-13.2 UAC Processing
-
-13.2.1 Creating the Initial INVITE
-
- Since the initial INVITE represents a request outside of a dialog,
- its construction follows the procedures of Section 8.1.1. Additional
- processing is required for the specific case of INVITE.
-
- An Allow header field (Section 20.5) SHOULD be present in the INVITE.
- It indicates what methods can be invoked within a dialog, on the UA
- sending the INVITE, for the duration of the dialog. For example, a
- UA capable of receiving INFO requests within a dialog [34] SHOULD
- include an Allow header field listing the INFO method.
-
- A Supported header field (Section 20.37) SHOULD be present in the
- INVITE. It enumerates all the extensions understood by the UAC.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 78]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- An Accept (Section 20.1) header field MAY be present in the INVITE.
- It indicates which Content-Types are acceptable to the UA, in both
- the response received by it, and in any subsequent requests sent to
- it within dialogs established by the INVITE. The Accept header field
- is especially useful for indicating support of various session
- description formats.
-
- The UAC MAY add an Expires header field (Section 20.19) to limit the
- validity of the invitation. If the time indicated in the Expires
- header field is reached and no final answer for the INVITE has been
- received, the UAC core SHOULD generate a CANCEL request for the
- INVITE, as per Section 9.
-
- A UAC MAY also find it useful to add, among others, Subject (Section
- 20.36), Organization (Section 20.25) and User-Agent (Section 20.41)
- header fields. They all contain information related to the INVITE.
-
- The UAC MAY choose to add a message body to the INVITE. Section
- 8.1.1.10 deals with how to construct the header fields -- Content-
- Type among others -- needed to describe the message body.
-
- There are special rules for message bodies that contain a session
- description - their corresponding Content-Disposition is "session".
- SIP uses an offer/answer model where one UA sends a session
- description, called the offer, which contains a proposed description
- of the session. The offer indicates the desired communications means
- (audio, video, games), parameters of those means (such as codec
- types) and addresses for receiving media from the answerer. The
- other UA responds with another session description, called the
- answer, which indicates which communications means are accepted, the
- parameters that apply to those means, and addresses for receiving
- media from the offerer. An offer/answer exchange is within the
- context of a dialog, so that if a SIP INVITE results in multiple
- dialogs, each is a separate offer/answer exchange. The offer/answer
- model defines restrictions on when offers and answers can be made
- (for example, you cannot make a new offer while one is in progress).
- This results in restrictions on where the offers and answers can
- appear in SIP messages. In this specification, offers and answers
- can only appear in INVITE requests and responses, and ACK. The usage
- of offers and answers is further restricted. For the initial INVITE
- transaction, the rules are:
-
- o The initial offer MUST be in either an INVITE or, if not there,
- in the first reliable non-failure message from the UAS back to
- the UAC. In this specification, that is the final 2xx
- response.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 79]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o If the initial offer is in an INVITE, the answer MUST be in a
- reliable non-failure message from UAS back to UAC which is
- correlated to that INVITE. For this specification, that is
- only the final 2xx response to that INVITE. That same exact
- answer MAY also be placed in any provisional responses sent
- prior to the answer. The UAC MUST treat the first session
- description it receives as the answer, and MUST ignore any
- session descriptions in subsequent responses to the initial
- INVITE.
-
- o If the initial offer is in the first reliable non-failure
- message from the UAS back to UAC, the answer MUST be in the
- acknowledgement for that message (in this specification, ACK
- for a 2xx response).
-
- o After having sent or received an answer to the first offer, the
- UAC MAY generate subsequent offers in requests based on rules
- specified for that method, but only if it has received answers
- to any previous offers, and has not sent any offers to which it
- hasn't gotten an answer.
-
- o Once the UAS has sent or received an answer to the initial
- offer, it MUST NOT generate subsequent offers in any responses
- to the initial INVITE. This means that a UAS based on this
- specification alone can never generate subsequent offers until
- completion of the initial transaction.
-
- Concretely, the above rules specify two exchanges for UAs compliant
- to this specification alone - the offer is in the INVITE, and the
- answer in the 2xx (and possibly in a 1xx as well, with the same
- value), or the offer is in the 2xx, and the answer is in the ACK.
- All user agents that support INVITE MUST support these two exchanges.
-
- The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be
- supported by all user agents as a means to describe sessions, and its
- usage for constructing offers and answers MUST follow the procedures
- defined in [13].
-
- The restrictions of the offer-answer model just described only apply
- to bodies whose Content-Disposition header field value is "session".
- Therefore, it is possible that both the INVITE and the ACK contain a
- body message (for example, the INVITE carries a photo (Content-
- Disposition: render) and the ACK a session description (Content-
- Disposition: session)).
-
- If the Content-Disposition header field is missing, bodies of
- Content-Type application/sdp imply the disposition "session", while
- other content types imply "render".
-
-
-
-Rosenberg, et. al. Standards Track [Page 80]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Once the INVITE has been created, the UAC follows the procedures
- defined for sending requests outside of a dialog (Section 8). This
- results in the construction of a client transaction that will
- ultimately send the request and deliver responses to the UAC.
-
-13.2.2 Processing INVITE Responses
-
- Once the INVITE has been passed to the INVITE client transaction, the
- UAC waits for responses for the INVITE. If the INVITE client
- transaction returns a timeout rather than a response the TU acts as
- if a 408 (Request Timeout) response had been received, as described
- in Section 8.1.3.
-
-13.2.2.1 1xx Responses
-
- Zero, one or multiple provisional responses may arrive before one or
- more final responses are received. Provisional responses for an
- INVITE request can create "early dialogs". If a provisional response
- has a tag in the To field, and if the dialog ID of the response does
- not match an existing dialog, one is constructed using the procedures
- defined in Section 12.1.2.
-
- The early dialog will only be needed if the UAC needs to send a
- request to its peer within the dialog before the initial INVITE
- transaction completes. Header fields present in a provisional
- response are applicable as long as the dialog is in the early state
- (for example, an Allow header field in a provisional response
- contains the methods that can be used in the dialog while this is in
- the early state).
-
-13.2.2.2 3xx Responses
-
- A 3xx response may contain one or more Contact header field values
- providing new addresses where the callee might be reachable.
- Depending on the status code of the 3xx response (see Section 21.3),
- the UAC MAY choose to try those new addresses.
-
-13.2.2.3 4xx, 5xx and 6xx Responses
-
- A single non-2xx final response may be received for the INVITE. 4xx,
- 5xx and 6xx responses may contain a Contact header field value
- indicating the location where additional information about the error
- can be found. Subsequent final responses (which would only arrive
- under error conditions) MUST be ignored.
-
- All early dialogs are considered terminated upon reception of the
- non-2xx final response.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 81]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- After having received the non-2xx final response the UAC core
- considers the INVITE transaction completed. The INVITE client
- transaction handles the generation of ACKs for the response (see
- Section 17).
-
-13.2.2.4 2xx Responses
-
- Multiple 2xx responses may arrive at the UAC for a single INVITE
- request due to a forking proxy. Each response is distinguished by
- the tag parameter in the To header field, and each represents a
- distinct dialog, with a distinct dialog identifier.
-
- If the dialog identifier in the 2xx response matches the dialog
- identifier of an existing dialog, the dialog MUST be transitioned to
- the "confirmed" state, and the route set for the dialog MUST be
- recomputed based on the 2xx response using the procedures of Section
- 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be
- constructed using the procedures of Section 12.1.2.
-
- Note that the only piece of state that is recomputed is the route
- set. Other pieces of state such as the highest sequence numbers
- (remote and local) sent within the dialog are not recomputed. The
- route set only is recomputed for backwards compatibility. RFC
- 2543 did not mandate mirroring of the Record-Route header field in
- a 1xx, only 2xx. However, we cannot update the entire state of
- the dialog, since mid-dialog requests may have been sent within
- the early dialog, modifying the sequence numbers, for example.
-
- The UAC core MUST generate an ACK request for each 2xx received from
- the transaction layer. The header fields of the ACK are constructed
- in the same way as for any request sent within a dialog (see Section
- 12) with the exception of the CSeq and the header fields related to
- authentication. The sequence number of the CSeq header field MUST be
- the same as the INVITE being acknowledged, but the CSeq method MUST
- be ACK. The ACK MUST contain the same credentials as the INVITE. If
- the 2xx contains an offer (based on the rules above), the ACK MUST
- carry an answer in its body. If the offer in the 2xx response is not
- acceptable, the UAC core MUST generate a valid answer in the ACK and
- then send a BYE immediately.
-
- Once the ACK has been constructed, the procedures of [4] are used to
- determine the destination address, port and transport. However, the
- request is passed to the transport layer directly for transmission,
- rather than a client transaction. This is because the UAC core
- handles retransmissions of the ACK, not the transaction layer. The
- ACK MUST be passed to the client transport every time a
- retransmission of the 2xx final response that triggered the ACK
- arrives.
-
-
-
-Rosenberg, et. al. Standards Track [Page 82]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The UAC core considers the INVITE transaction completed 64*T1 seconds
- after the reception of the first 2xx response. At this point all the
- early dialogs that have not transitioned to established dialogs are
- terminated. Once the INVITE transaction is considered completed by
- the UAC core, no more new 2xx responses are expected to arrive.
-
- If, after acknowledging any 2xx response to an INVITE, the UAC does
- not want to continue with that dialog, then the UAC MUST terminate
- the dialog by sending a BYE request as described in Section 15.
-
-13.3 UAS Processing
-
-13.3.1 Processing of the INVITE
-
- The UAS core will receive INVITE requests from the transaction layer.
- It first performs the request processing procedures of Section 8.2,
- which are applied for both requests inside and outside of a dialog.
-
- Assuming these processing states are completed without generating a
- response, the UAS core performs the additional processing steps:
-
- 1. If the request is an INVITE that contains an Expires header
- field, the UAS core sets a timer for the number of seconds
- indicated in the header field value. When the timer fires, the
- invitation is considered to be expired. If the invitation
- expires before the UAS has generated a final response, a 487
- (Request Terminated) response SHOULD be generated.
-
- 2. If the request is a mid-dialog request, the method-independent
- processing described in Section 12.2.2 is first applied. It
- might also modify the session; Section 14 provides details.
-
- 3. If the request has a tag in the To header field but the dialog
- identifier does not match any of the existing dialogs, the UAS
- may have crashed and restarted, or may have received a request
- for a different (possibly failed) UAS. Section 12.2.2 provides
- guidelines to achieve a robust behavior under such a situation.
-
- Processing from here forward assumes that the INVITE is outside of a
- dialog, and is thus for the purposes of establishing a new session.
-
- The INVITE may contain a session description, in which case the UAS
- is being presented with an offer for that session. It is possible
- that the user is already a participant in that session, even though
- the INVITE is outside of a dialog. This can happen when a user is
- invited to the same multicast conference by multiple other
- participants. If desired, the UAS MAY use identifiers within the
- session description to detect this duplication. For example, SDP
-
-
-
-Rosenberg, et. al. Standards Track [Page 83]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- contains a session id and version number in the origin (o) field. If
- the user is already a member of the session, and the session
- parameters contained in the session description have not changed, the
- UAS MAY silently accept the INVITE (that is, send a 2xx response
- without prompting the user).
-
- If the INVITE does not contain a session description, the UAS is
- being asked to participate in a session, and the UAC has asked that
- the UAS provide the offer of the session. It MUST provide the offer
- in its first non-failure reliable message back to the UAC. In this
- specification, that is a 2xx response to the INVITE.
-
- The UAS can indicate progress, accept, redirect, or reject the
- invitation. In all of these cases, it formulates a response using
- the procedures described in Section 8.2.6.
-
-13.3.1.1 Progress
-
- If the UAS is not able to answer the invitation immediately, it can
- choose to indicate some kind of progress to the UAC (for example, an
- indication that a phone is ringing). This is accomplished with a
- provisional response between 101 and 199. These provisional
- responses establish early dialogs and therefore follow the procedures
- of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY
- send as many provisional responses as it likes. Each of these MUST
- indicate the same dialog ID. However, these will not be delivered
- reliably.
-
- If the UAS desires an extended period of time to answer the INVITE,
- it will need to ask for an "extension" in order to prevent proxies
- from canceling the transaction. A proxy has the option of canceling
- a transaction when there is a gap of 3 minutes between responses in a
- transaction. To prevent cancellation, the UAS MUST send a non-100
- provisional response at every minute, to handle the possibility of
- lost provisional responses.
-
- An INVITE transaction can go on for extended durations when the
- user is placed on hold, or when interworking with PSTN systems
- which allow communications to take place without answering the
- call. The latter is common in Interactive Voice Response (IVR)
- systems.
-
-13.3.1.2 The INVITE is Redirected
-
- If the UAS decides to redirect the call, a 3xx response is sent. A
- 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved
- Temporarily) response SHOULD contain a Contact header field
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 84]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- containing one or more URIs of new addresses to be tried. The
- response is passed to the INVITE server transaction, which will deal
- with its retransmissions.
-
-13.3.1.3 The INVITE is Rejected
-
- A common scenario occurs when the callee is currently not willing or
- able to take additional calls at this end system. A 486 (Busy Here)
- SHOULD be returned in such a scenario. If the UAS knows that no
- other end system will be able to accept this call, a 600 (Busy
- Everywhere) response SHOULD be sent instead. However, it is unlikely
- that a UAS will be able to know this in general, and thus this
- response will not usually be used. The response is passed to the
- INVITE server transaction, which will deal with its retransmissions.
-
- A UAS rejecting an offer contained in an INVITE SHOULD return a 488
- (Not Acceptable Here) response. Such a response SHOULD include a
- Warning header field value explaining why the offer was rejected.
-
-13.3.1.4 The INVITE is Accepted
-
- The UAS core generates a 2xx response. This response establishes a
- dialog, and therefore follows the procedures of Section 12.1.1 in
- addition to those of Section 8.2.6.
-
- A 2xx response to an INVITE SHOULD contain the Allow header field and
- the Supported header field, and MAY contain the Accept header field.
- Including these header fields allows the UAC to determine the
- features and extensions supported by the UAS for the duration of the
- call, without probing.
-
- If the INVITE request contained an offer, and the UAS had not yet
- sent an answer, the 2xx MUST contain an answer. If the INVITE did
- not contain an offer, the 2xx MUST contain an offer if the UAS had
- not yet sent an offer.
-
- Once the response has been constructed, it is passed to the INVITE
- server transaction. Note, however, that the INVITE server
- transaction will be destroyed as soon as it receives this final
- response and passes it to the transport. Therefore, it is necessary
- to periodically pass the response directly to the transport until the
- ACK arrives. The 2xx response is passed to the transport with an
- interval that starts at T1 seconds and doubles for each
- retransmission until it reaches T2 seconds (T1 and T2 are defined in
- Section 17). Response retransmissions cease when an ACK request for
- the response is received. This is independent of whatever transport
- protocols are used to send the response.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 85]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Since 2xx is retransmitted end-to-end, there may be hops between
- UAS and UAC that are UDP. To ensure reliable delivery across
- these hops, the response is retransmitted periodically even if the
- transport at the UAS is reliable.
-
- If the server retransmits the 2xx response for 64*T1 seconds without
- receiving an ACK, the dialog is confirmed, but the session SHOULD be
- terminated. This is accomplished with a BYE, as described in Section
- 15.
-
-14 Modifying an Existing Session
-
- A successful INVITE request (see Section 13) establishes both a
- dialog between two user agents and a session using the offer-answer
- model. Section 12 explains how to modify an existing dialog using a
- target refresh request (for example, changing the remote target URI
- of the dialog). This section describes how to modify the actual
- session. This modification can involve changing addresses or ports,
- adding a media stream, deleting a media stream, and so on. This is
- accomplished by sending a new INVITE request within the same dialog
- that established the session. An INVITE request sent within an
- existing dialog is known as a re-INVITE.
-
- Note that a single re-INVITE can modify the dialog and the
- parameters of the session at the same time.
-
- Either the caller or callee can modify an existing session.
-
- The behavior of a UA on detection of media failure is a matter of
- local policy. However, automated generation of re-INVITE or BYE is
- NOT RECOMMENDED to avoid flooding the network with traffic when there
- is congestion. In any case, if these messages are sent
- automatically, they SHOULD be sent after some randomized interval.
-
- Note that the paragraph above refers to automatically generated
- BYEs and re-INVITEs. If the user hangs up upon media failure, the
- UA would send a BYE request as usual.
-
-14.1 UAC Behavior
-
- The same offer-answer model that applies to session descriptions in
- INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC
- that wants to add a media stream, for example, will create a new
- offer that contains this media stream, and send that in an INVITE
- request to its peer. It is important to note that the full
- description of the session, not just the change, is sent. This
- supports stateless session processing in various elements, and
- supports failover and recovery capabilities. Of course, a UAC MAY
-
-
-
-Rosenberg, et. al. Standards Track [Page 86]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- send a re-INVITE with no session description, in which case the first
- reliable non-failure response to the re-INVITE will contain the offer
- (in this specification, that is a 2xx response).
-
- If the session description format has the capability for version
- numbers, the offerer SHOULD indicate that the version of the session
- description has changed.
-
- The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set
- following the same rules as for regular requests within an existing
- dialog, described in Section 12.
-
- A UAC MAY choose not to add an Alert-Info header field or a body with
- Content-Disposition "alert" to re-INVITEs because UASs do not
- typically alert the user upon reception of a re-INVITE.
-
- Unlike an INVITE, which can fork, a re-INVITE will never fork, and
- therefore, only ever generate a single final response. The reason a
- re-INVITE will never fork is that the Request-URI identifies the
- target as the UA instance it established the dialog with, rather than
- identifying an address-of-record for the user.
-
- Note that a UAC MUST NOT initiate a new INVITE transaction within a
- dialog while another INVITE transaction is in progress in either
- direction.
-
- 1. If there is an ongoing INVITE client transaction, the TU MUST
- wait until the transaction reaches the completed or terminated
- state before initiating the new INVITE.
-
- 2. If there is an ongoing INVITE server transaction, the TU MUST
- wait until the transaction reaches the confirmed or terminated
- state before initiating the new INVITE.
-
- However, a UA MAY initiate a regular transaction while an INVITE
- transaction is in progress. A UA MAY also initiate an INVITE
- transaction while a regular transaction is in progress.
-
- If a UA receives a non-2xx final response to a re-INVITE, the session
- parameters MUST remain unchanged, as if no re-INVITE had been issued.
- Note that, as stated in Section 12.2.1.2, if the non-2xx final
- response is a 481 (Call/Transaction Does Not Exist), or a 408
- (Request Timeout), or no response at all is received for the re-
- INVITE (that is, a timeout is returned by the INVITE client
- transaction), the UAC will terminate the dialog.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 87]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
- timer with a value T chosen as follows:
-
- 1. If the UAC is the owner of the Call-ID of the dialog ID
- (meaning it generated the value), T has a randomly chosen value
- between 2.1 and 4 seconds in units of 10 ms.
-
- 2. If the UAC is not the owner of the Call-ID of the dialog ID, T
- has a randomly chosen value of between 0 and 2 seconds in units
- of 10 ms.
-
- When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
- if it still desires for that session modification to take place. For
- example, if the call was already hung up with a BYE, the re-INVITE
- would not take place.
-
- The rules for transmitting a re-INVITE and for generating an ACK for
- a 2xx response to re-INVITE are the same as for the initial INVITE
- (Section 13.2.1).
-
-14.2 UAS Behavior
-
- Section 13.3.1 describes the procedure for distinguishing incoming
- re-INVITEs from incoming initial INVITEs and handling a re-INVITE for
- an existing dialog.
-
- A UAS that receives a second INVITE before it sends the final
- response to a first INVITE with a lower CSeq sequence number on the
- same dialog MUST return a 500 (Server Internal Error) response to the
- second INVITE and MUST include a Retry-After header field with a
- randomly chosen value of between 0 and 10 seconds.
-
- A UAS that receives an INVITE on a dialog while an INVITE it had sent
- on that dialog is in progress MUST return a 491 (Request Pending)
- response to the received INVITE.
-
- If a UA receives a re-INVITE for an existing dialog, it MUST check
- any version identifiers in the session description or, if there are
- no version identifiers, the content of the session description to see
- if it has changed. If the session description has changed, the UAS
- MUST adjust the session parameters accordingly, possibly after asking
- the user for confirmation.
-
- Versioning of the session description can be used to accommodate
- the capabilities of new arrivals to a conference, add or delete
- media, or change from a unicast to a multicast conference.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 88]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- If the new session description is not acceptable, the UAS can reject
- it by returning a 488 (Not Acceptable Here) response for the re-
- INVITE. This response SHOULD include a Warning header field.
-
- If a UAS generates a 2xx response and never receives an ACK, it
- SHOULD generate a BYE to terminate the dialog.
-
- A UAS MAY choose not to generate 180 (Ringing) responses for a re-
- INVITE because UACs do not typically render this information to the
- user. For the same reason, UASs MAY choose not to use an Alert-Info
- header field or a body with Content-Disposition "alert" in responses
- to a re-INVITE.
-
- A UAS providing an offer in a 2xx (because the INVITE did not contain
- an offer) SHOULD construct the offer as if the UAS were making a
- brand new call, subject to the constraints of sending an offer that
- updates an existing session, as described in [13] in the case of SDP.
- Specifically, this means that it SHOULD include as many media formats
- and media types that the UA is willing to support. The UAS MUST
- ensure that the session description overlaps with its previous
- session description in media formats, transports, or other parameters
- that require support from the peer. This is to avoid the need for
- the peer to reject the session description. If, however, it is
- unacceptable to the UAC, the UAC SHOULD generate an answer with a
- valid session description, and then send a BYE to terminate the
- session.
-
-15 Terminating a Session
-
- This section describes the procedures for terminating a session
- established by SIP. The state of the session and the state of the
- dialog are very closely related. When a session is initiated with an
- INVITE, each 1xx or 2xx response from a distinct UAS creates a
- dialog, and if that response completes the offer/answer exchange, it
- also creates a session. As a result, each session is "associated"
- with a single dialog - the one which resulted in its creation. If an
- initial INVITE generates a non-2xx final response, that terminates
- all sessions (if any) and all dialogs (if any) that were created
- through responses to the request. By virtue of completing the
- transaction, a non-2xx final response also prevents further sessions
- from being created as a result of the INVITE. The BYE request is
- used to terminate a specific session or attempted session. In this
- case, the specific session is the one with the peer UA on the other
- side of the dialog. When a BYE is received on a dialog, any session
- associated with that dialog SHOULD terminate. A UA MUST NOT send a
- BYE outside of a dialog. The caller's UA MAY send a BYE for either
- confirmed or early dialogs, and the callee's UA MAY send a BYE on
- confirmed dialogs, but MUST NOT send a BYE on early dialogs.
-
-
-
-Rosenberg, et. al. Standards Track [Page 89]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- However, the callee's UA MUST NOT send a BYE on a confirmed dialog
- until it has received an ACK for its 2xx response or until the server
- transaction times out. If no SIP extensions have defined other
- application layer states associated with the dialog, the BYE also
- terminates the dialog.
-
- The impact of a non-2xx final response to INVITE on dialogs and
- sessions makes the use of CANCEL attractive. The CANCEL attempts to
- force a non-2xx response to the INVITE (in particular, a 487).
- Therefore, if a UAC wishes to give up on its call attempt entirely,
- it can send a CANCEL. If the INVITE results in 2xx final response(s)
- to the INVITE, this means that a UAS accepted the invitation while
- the CANCEL was in progress. The UAC MAY continue with the sessions
- established by any 2xx responses, or MAY terminate them with BYE.
-
- The notion of "hanging up" is not well defined within SIP. It is
- specific to a particular, albeit common, user interface.
- Typically, when the user hangs up, it indicates a desire to
- terminate the attempt to establish a session, and to terminate any
- sessions already created. For the caller's UA, this would imply a
- CANCEL request if the initial INVITE has not generated a final
- response, and a BYE to all confirmed dialogs after a final
- response. For the callee's UA, it would typically imply a BYE;
- presumably, when the user picked up the phone, a 2xx was
- generated, and so hanging up would result in a BYE after the ACK
- is received. This does not mean a user cannot hang up before
- receipt of the ACK, it just means that the software in his phone
- needs to maintain state for a short while in order to clean up
- properly. If the particular UI allows for the user to reject a
- call before its answered, a 403 (Forbidden) is a good way to
- express that. As per the rules above, a BYE can't be sent.
-
-15.1 Terminating a Session with a BYE Request
-
-15.1.1 UAC Behavior
-
- A BYE request is constructed as would any other request within a
- dialog, as described in Section 12.
-
- Once the BYE is constructed, the UAC core creates a new non-INVITE
- client transaction, and passes it the BYE request. The UAC MUST
- consider the session terminated (and therefore stop sending or
- listening for media) as soon as the BYE request is passed to the
- client transaction. If the response for the BYE is a 481
- (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 90]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- response at all is received for the BYE (that is, a timeout is
- returned by the client transaction), the UAC MUST consider the
- session and the dialog terminated.
-
-15.1.2 UAS Behavior
-
- A UAS first processes the BYE request according to the general UAS
- processing described in Section 8.2. A UAS core receiving a BYE
- request checks if it matches an existing dialog. If the BYE does not
- match an existing dialog, the UAS core SHOULD generate a 481
- (Call/Transaction Does Not Exist) response and pass that to the
- server transaction.
-
- This rule means that a BYE sent without tags by a UAC will be
- rejected. This is a change from RFC 2543, which allowed BYE
- without tags.
-
- A UAS core receiving a BYE request for an existing dialog MUST follow
- the procedures of Section 12.2.2 to process the request. Once done,
- the UAS SHOULD terminate the session (and therefore stop sending and
- listening for media). The only case where it can elect not to are
- multicast sessions, where participation is possible even if the other
- participant in the dialog has terminated its involvement in the
- session. Whether or not it ends its participation on the session,
- the UAS core MUST generate a 2xx response to the BYE, and MUST pass
- that to the server transaction for transmission.
-
- The UAS MUST still respond to any pending requests received for that
- dialog. It is RECOMMENDED that a 487 (Request Terminated) response
- be generated to those pending requests.
-
-16 Proxy Behavior
-
-16.1 Overview
-
- SIP proxies are elements that route SIP requests to user agent
- servers and SIP responses to user agent clients. A request may
- traverse several proxies on its way to a UAS. Each will make routing
- decisions, modifying the request before forwarding it to the next
- element. Responses will route through the same set of proxies
- traversed by the request in the reverse order.
-
- Being a proxy is a logical role for a SIP element. When a request
- arrives, an element that can play the role of a proxy first decides
- if it needs to respond to the request on its own. For instance, the
- request may be malformed or the element may need credentials from the
- client before acting as a proxy. The element MAY respond with any
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 91]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- appropriate error code. When responding directly to a request, the
- element is playing the role of a UAS and MUST behave as described in
- Section 8.2.
-
- A proxy can operate in either a stateful or stateless mode for each
- new request. When stateless, a proxy acts as a simple forwarding
- element. It forwards each request downstream to a single element
- determined by making a targeting and routing decision based on the
- request. It simply forwards every response it receives upstream. A
- stateless proxy discards information about a message once the message
- has been forwarded. A stateful proxy remembers information
- (specifically, transaction state) about each incoming request and any
- requests it sends as a result of processing the incoming request. It
- uses this information to affect the processing of future messages
- associated with that request. A stateful proxy MAY choose to "fork"
- a request, routing it to multiple destinations. Any request that is
- forwarded to more than one location MUST be handled statefully.
-
- In some circumstances, a proxy MAY forward requests using stateful
- transports (such as TCP) without being transaction-stateful. For
- instance, a proxy MAY forward a request from one TCP connection to
- another transaction statelessly as long as it places enough
- information in the message to be able to forward the response down
- the same connection the request arrived on. Requests forwarded
- between different types of transports where the proxy's TU must take
- an active role in ensuring reliable delivery on one of the transports
- MUST be forwarded transaction statefully.
-
- A stateful proxy MAY transition to stateless operation at any time
- during the processing of a request, so long as it did not do anything
- that would otherwise prevent it from being stateless initially
- (forking, for example, or generation of a 100 response). When
- performing such a transition, all state is simply discarded. The
- proxy SHOULD NOT initiate a CANCEL request.
-
- Much of the processing involved when acting statelessly or statefully
- for a request is identical. The next several subsections are written
- from the point of view of a stateful proxy. The last section calls
- out those places where a stateless proxy behaves differently.
-
-16.2 Stateful Proxy
-
- When stateful, a proxy is purely a SIP transaction processing engine.
- Its behavior is modeled here in terms of the server and client
- transactions defined in Section 17. A stateful proxy has a server
- transaction associated with one or more client transactions by a
- higher layer proxy processing component (see figure 3), known as a
- proxy core. An incoming request is processed by a server
-
-
-
-Rosenberg, et. al. Standards Track [Page 92]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- transaction. Requests from the server transaction are passed to a
- proxy core. The proxy core determines where to route the request,
- choosing one or more next-hop locations. An outgoing request for
- each next-hop location is processed by its own associated client
- transaction. The proxy core collects the responses from the client
- transactions and uses them to send responses to the server
- transaction.
-
- A stateful proxy creates a new server transaction for each new
- request received. Any retransmissions of the request will then be
- handled by that server transaction per Section 17. The proxy core
- MUST behave as a UAS with respect to sending an immediate provisional
- on that server transaction (such as 100 Trying) as described in
- Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100
- (Trying) responses to non-INVITE requests.
-
- This is a model of proxy behavior, not of software. An
- implementation is free to take any approach that replicates the
- external behavior this model defines.
-
- For all new requests, including any with unknown methods, an element
- intending to proxy the request MUST:
-
- 1. Validate the request (Section 16.3)
-
- 2. Preprocess routing information (Section 16.4)
-
- 3. Determine target(s) for the request (Section 16.5)
-
- +--------------------+
- | | +---+
- | | | C |
- | | | T |
- | | +---+
- +---+ | Proxy | +---+ CT = Client Transaction
- | S | | "Higher" Layer | | C |
- | T | | | | T | ST = Server Transaction
- +---+ | | +---+
- | | +---+
- | | | C |
- | | | T |
- | | +---+
- +--------------------+
-
- Figure 3: Stateful Proxy Model
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 93]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 4. Forward the request to each target (Section 16.6)
-
- 5. Process all responses (Section 16.7)
-
-16.3 Request Validation
-
- Before an element can proxy a request, it MUST verify the message's
- validity. A valid message must pass the following checks:
-
- 1. Reasonable Syntax
-
- 2. URI scheme
-
- 3. Max-Forwards
-
- 4. (Optional) Loop Detection
-
- 5. Proxy-Require
-
- 6. Proxy-Authorization
-
- If any of these checks fail, the element MUST behave as a user agent
- server (see Section 8.2) and respond with an error code.
-
- Notice that a proxy is not required to detect merged requests and
- MUST NOT treat merged requests as an error condition. The endpoints
- receiving the requests will resolve the merge as described in Section
- 8.2.2.2.
-
- 1. Reasonable syntax check
-
- The request MUST be well-formed enough to be handled with a server
- transaction. Any components involved in the remainder of these
- Request Validation steps or the Request Forwarding section MUST be
- well-formed. Any other components, well-formed or not, SHOULD be
- ignored and remain unchanged when the message is forwarded. For
- instance, an element would not reject a request because of a
- malformed Date header field. Likewise, a proxy would not remove a
- malformed Date header field before forwarding a request.
-
- This protocol is designed to be extended. Future extensions may
- define new methods and header fields at any time. An element MUST
- NOT refuse to proxy a request because it contains a method or
- header field it does not know about.
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 94]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 2. URI scheme check
-
- If the Request-URI has a URI whose scheme is not understood by the
- proxy, the proxy SHOULD reject the request with a 416 (Unsupported
- URI Scheme) response.
-
- 3. Max-Forwards check
-
- The Max-Forwards header field (Section 20.22) is used to limit the
- number of elements a SIP request can traverse.
-
- If the request does not contain a Max-Forwards header field, this
- check is passed.
-
- If the request contains a Max-Forwards header field with a field
- value greater than zero, the check is passed.
-
- If the request contains a Max-Forwards header field with a field
- value of zero (0), the element MUST NOT forward the request. If
- the request was for OPTIONS, the element MAY act as the final
- recipient and respond per Section 11. Otherwise, the element MUST
- return a 483 (Too many hops) response.
-
- 4. Optional Loop Detection check
-
- An element MAY check for forwarding loops before forwarding a
- request. If the request contains a Via header field with a sent-
- by value that equals a value placed into previous requests by the
- proxy, the request has been forwarded by this element before. The
- request has either looped or is legitimately spiraling through the
- element. To determine if the request has looped, the element MAY
- perform the branch parameter calculation described in Step 8 of
- Section 16.6 on this message and compare it to the parameter
- received in that Via header field. If the parameters match, the
- request has looped. If they differ, the request is spiraling, and
- processing continues. If a loop is detected, the element MAY
- return a 482 (Loop Detected) response.
-
- 5. Proxy-Require check
-
- Future extensions to this protocol may introduce features that
- require special handling by proxies. Endpoints will include a
- Proxy-Require header field in requests that use these features,
- telling the proxy not to process the request unless the feature is
- understood.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 95]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- If the request contains a Proxy-Require header field (Section
- 20.29) with one or more option-tags this element does not
- understand, the element MUST return a 420 (Bad Extension)
- response. The response MUST include an Unsupported (Section
- 20.40) header field listing those option-tags the element did not
- understand.
-
- 6. Proxy-Authorization check
-
- If an element requires credentials before forwarding a request,
- the request MUST be inspected as described in Section 22.3. That
- section also defines what the element must do if the inspection
- fails.
-
-16.4 Route Information Preprocessing
-
- The proxy MUST inspect the Request-URI of the request. If the
- Request-URI of the request contains a value this proxy previously
- placed into a Record-Route header field (see Section 16.6 item 4),
- the proxy MUST replace the Request-URI in the request with the last
- value from the Route header field, and remove that value from the
- Route header field. The proxy MUST then proceed as if it received
- this modified request.
-
- This will only happen when the element sending the request to the
- proxy (which may have been an endpoint) is a strict router. This
- rewrite on receive is necessary to enable backwards compatibility
- with those elements. It also allows elements following this
- specification to preserve the Request-URI through strict-routing
- proxies (see Section 12.2.1.1).
-
- This requirement does not obligate a proxy to keep state in order
- to detect URIs it previously placed in Record-Route header fields.
- Instead, a proxy need only place enough information in those URIs
- to recognize them as values it provided when they later appear.
-
- If the Request-URI contains a maddr parameter, the proxy MUST check
- to see if its value is in the set of addresses or domains the proxy
- is configured to be responsible for. If the Request-URI has a maddr
- parameter with a value the proxy is responsible for, and the request
- was received using the port and transport indicated (explicitly or by
- default) in the Request-URI, the proxy MUST strip the maddr and any
- non-default port or transport parameter and continue processing as if
- those values had not been present in the request.
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 96]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- A request may arrive with a maddr matching the proxy, but on a
- port or transport different from that indicated in the URI. Such
- a request needs to be forwarded to the proxy using the indicated
- port and transport.
-
- If the first value in the Route header field indicates this proxy,
- the proxy MUST remove that value from the request.
-
-16.5 Determining Request Targets
-
- Next, the proxy calculates the target(s) of the request. The set of
- targets will either be predetermined by the contents of the request
- or will be obtained from an abstract location service. Each target
- in the set is represented as a URI.
-
- If the Request-URI of the request contains an maddr parameter, the
- Request-URI MUST be placed into the target set as the only target
- URI, and the proxy MUST proceed to Section 16.6.
-
- If the domain of the Request-URI indicates a domain this element is
- not responsible for, the Request-URI MUST be placed into the target
- set as the only target, and the element MUST proceed to the task of
- Request Forwarding (Section 16.6).
-
- There are many circumstances in which a proxy might receive a
- request for a domain it is not responsible for. A firewall proxy
- handling outgoing calls (the way HTTP proxies handle outgoing
- requests) is an example of where this is likely to occur.
-
- If the target set for the request has not been predetermined as
- described above, this implies that the element is responsible for the
- domain in the Request-URI, and the element MAY use whatever mechanism
- it desires to determine where to send the request. Any of these
- mechanisms can be modeled as accessing an abstract Location Service.
- This may consist of obtaining information from a location service
- created by a SIP Registrar, reading a database, consulting a presence
- server, utilizing other protocols, or simply performing an
- algorithmic substitution on the Request-URI. When accessing the
- location service constructed by a registrar, the Request-URI MUST
- first be canonicalized as described in Section 10.3 before being used
- as an index. The output of these mechanisms is used to construct the
- target set.
-
- If the Request-URI does not provide sufficient information for the
- proxy to determine the target set, it SHOULD return a 485 (Ambiguous)
- response. This response SHOULD contain a Contact header field
- containing URIs of new addresses to be tried. For example, an INVITE
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 97]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- to sip:John.Smith@company.com may be ambiguous at a proxy whose
- location service has multiple John Smiths listed. See Section
- 21.4.23 for details.
-
- Any information in or about the request or the current environment of
- the element MAY be used in the construction of the target set. For
- instance, different sets may be constructed depending on contents or
- the presence of header fields and bodies, the time of day of the
- request's arrival, the interface on which the request arrived,
- failure of previous requests, or even the element's current level of
- utilization.
-
- As potential targets are located through these services, their URIs
- are added to the target set. Targets can only be placed in the
- target set once. If a target URI is already present in the set
- (based on the definition of equality for the URI type), it MUST NOT
- be added again.
-
- A proxy MUST NOT add additional targets to the target set if the
- Request-URI of the original request does not indicate a resource this
- proxy is responsible for.
-
- A proxy can only change the Request-URI of a request during
- forwarding if it is responsible for that URI. If the proxy is not
- responsible for that URI, it will not recurse on 3xx or 416
- responses as described below.
-
- If the Request-URI of the original request indicates a resource this
- proxy is responsible for, the proxy MAY continue to add targets to
- the set after beginning Request Forwarding. It MAY use any
- information obtained during that processing to determine new targets.
- For instance, a proxy may choose to incorporate contacts obtained in
- a redirect response (3xx) into the target set. If a proxy uses a
- dynamic source of information while building the target set (for
- instance, if it consults a SIP Registrar), it SHOULD monitor that
- source for the duration of processing the request. New locations
- SHOULD be added to the target set as they become available. As
- above, any given URI MUST NOT be added to the set more than once.
-
- Allowing a URI to be added to the set only once reduces
- unnecessary network traffic, and in the case of incorporating
- contacts from redirect requests prevents infinite recursion.
-
- For example, a trivial location service is a "no-op", where the
- target URI is equal to the incoming request URI. The request is sent
- to a specific next hop proxy for further processing. During request
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 98]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- forwarding of Section 16.6, Item 6, the identity of that next hop,
- expressed as a SIP or SIPS URI, is inserted as the top-most Route
- header field value into the request.
-
- If the Request-URI indicates a resource at this proxy that does not
- exist, the proxy MUST return a 404 (Not Found) response.
-
- If the target set remains empty after applying all of the above, the
- proxy MUST return an error response, which SHOULD be the 480
- (Temporarily Unavailable) response.
-
-16.6 Request Forwarding
-
- As soon as the target set is non-empty, a proxy MAY begin forwarding
- the request. A stateful proxy MAY process the set in any order. It
- MAY process multiple targets serially, allowing each client
- transaction to complete before starting the next. It MAY start
- client transactions with every target in parallel. It also MAY
- arbitrarily divide the set into groups, processing the groups
- serially and processing the targets in each group in parallel.
-
- A common ordering mechanism is to use the qvalue parameter of targets
- obtained from Contact header fields (see Section 20.10). Targets are
- processed from highest qvalue to lowest. Targets with equal qvalues
- may be processed in parallel.
-
- A stateful proxy must have a mechanism to maintain the target set as
- responses are received and associate the responses to each forwarded
- request with the original request. For the purposes of this model,
- this mechanism is a "response context" created by the proxy layer
- before forwarding the first request.
-
- For each target, the proxy forwards the request following these
- steps:
-
- 1. Make a copy of the received request
-
- 2. Update the Request-URI
-
- 3. Update the Max-Forwards header field
-
- 4. Optionally add a Record-route header field value
-
- 5. Optionally add additional header fields
-
- 6. Postprocess routing information
-
- 7. Determine the next-hop address, port, and transport
-
-
-
-Rosenberg, et. al. Standards Track [Page 99]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 8. Add a Via header field value
-
- 9. Add a Content-Length header field if necessary
-
- 10. Forward the new request
-
- 11. Set timer C
-
- Each of these steps is detailed below:
-
- 1. Copy request
-
- The proxy starts with a copy of the received request. The copy
- MUST initially contain all of the header fields from the
- received request. Fields not detailed in the processing
- described below MUST NOT be removed. The copy SHOULD maintain
- the ordering of the header fields as in the received request.
- The proxy MUST NOT reorder field values with a common field
- name (See Section 7.3.1). The proxy MUST NOT add to, modify,
- or remove the message body.
-
- An actual implementation need not perform a copy; the primary
- requirement is that the processing for each next hop begin with
- the same request.
-
- 2. Request-URI
-
- The Request-URI in the copy's start line MUST be replaced with
- the URI for this target. If the URI contains any parameters
- not allowed in a Request-URI, they MUST be removed.
-
- This is the essence of a proxy's role. This is the mechanism
- through which a proxy routes a request toward its destination.
-
- In some circumstances, the received Request-URI is placed into
- the target set without being modified. For that target, the
- replacement above is effectively a no-op.
-
- 3. Max-Forwards
-
- If the copy contains a Max-Forwards header field, the proxy
- MUST decrement its value by one (1).
-
- If the copy does not contain a Max-Forwards header field, the
- proxy MUST add one with a field value, which SHOULD be 70.
-
- Some existing UAs will not provide a Max-Forwards header field
- in a request.
-
-
-
-Rosenberg, et. al. Standards Track [Page 100]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 4. Record-Route
-
- If this proxy wishes to remain on the path of future requests
- in a dialog created by this request (assuming the request
- creates a dialog), it MUST insert a Record-Route header field
- value into the copy before any existing Record-Route header
- field values, even if a Route header field is already present.
-
- Requests establishing a dialog may contain a preloaded Route
- header field.
-
- If this request is already part of a dialog, the proxy SHOULD
- insert a Record-Route header field value if it wishes to remain
- on the path of future requests in the dialog. In normal
- endpoint operation as described in Section 12, these Record-
- Route header field values will not have any effect on the route
- sets used by the endpoints.
-
- The proxy will remain on the path if it chooses to not insert a
- Record-Route header field value into requests that are already
- part of a dialog. However, it would be removed from the path
- when an endpoint that has failed reconstitutes the dialog.
-
- A proxy MAY insert a Record-Route header field value into any
- request. If the request does not initiate a dialog, the
- endpoints will ignore the value. See Section 12 for details on
- how endpoints use the Record-Route header field values to
- construct Route header fields.
-
- Each proxy in the path of a request chooses whether to add a
- Record-Route header field value independently - the presence of
- a Record-Route header field in a request does not obligate this
- proxy to add a value.
-
- The URI placed in the Record-Route header field value MUST be a
- SIP or SIPS URI. This URI MUST contain an lr parameter (see
- Section 19.1.1). This URI MAY be different for each
- destination the request is forwarded to. The URI SHOULD NOT
- contain the transport parameter unless the proxy has knowledge
- (such as in a private network) that the next downstream element
- that will be in the path of subsequent requests supports that
- transport.
-
- The URI this proxy provides will be used by some other element
- to make a routing decision. This proxy, in general, has no way
- of knowing the capabilities of that element, so it must
- restrict itself to the mandatory elements of a SIP
- implementation: SIP URIs and either the TCP or UDP transports.
-
-
-
-Rosenberg, et. al. Standards Track [Page 101]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The URI placed in the Record-Route header field MUST resolve to
- the element inserting it (or a suitable stand-in) when the
- server location procedures of [4] are applied to it, so that
- subsequent requests reach the same SIP element. If the
- Request-URI contains a SIPS URI, or the topmost Route header
- field value (after the post processing of bullet 6) contains a
- SIPS URI, the URI placed into the Record-Route header field
- MUST be a SIPS URI. Furthermore, if the request was not
- received over TLS, the proxy MUST insert a Record-Route header
- field. In a similar fashion, a proxy that receives a request
- over TLS, but generates a request without a SIPS URI in the
- Request-URI or topmost Route header field value (after the post
- processing of bullet 6), MUST insert a Record-Route header
- field that is not a SIPS URI.
-
- A proxy at a security perimeter must remain on the perimeter
- throughout the dialog.
-
- If the URI placed in the Record-Route header field needs to be
- rewritten when it passes back through in a response, the URI
- MUST be distinct enough to locate at that time. (The request
- may spiral through this proxy, resulting in more than one
- Record-Route header field value being added). Item 8 of
- Section 16.7 recommends a mechanism to make the URI
- sufficiently distinct.
-
- The proxy MAY include parameters in the Record-Route header
- field value. These will be echoed in some responses to the
- request such as the 200 (OK) responses to INVITE. Such
- parameters may be useful for keeping state in the message
- rather than the proxy.
-
- If a proxy needs to be in the path of any type of dialog (such
- as one straddling a firewall), it SHOULD add a Record-Route
- header field value to every request with a method it does not
- understand since that method may have dialog semantics.
-
- The URI a proxy places into a Record-Route header field is only
- valid for the lifetime of any dialog created by the transaction
- in which it occurs. A dialog-stateful proxy, for example, MAY
- refuse to accept future requests with that value in the
- Request-URI after the dialog has terminated. Non-dialog-
- stateful proxies, of course, have no concept of when the dialog
- has terminated, but they MAY encode enough information in the
- value to compare it against the dialog identifier of future
- requests and MAY reject requests not matching that information.
- Endpoints MUST NOT use a URI obtained from a Record-Route
- header field outside the dialog in which it was provided. See
-
-
-
-Rosenberg, et. al. Standards Track [Page 102]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Section 12 for more information on an endpoint's use of
- Record-Route header fields.
-
- Record-routing may be required by certain services where the
- proxy needs to observe all messages in a dialog. However, it
- slows down processing and impairs scalability and thus proxies
- should only record-route if required for a particular service.
-
- The Record-Route process is designed to work for any SIP
- request that initiates a dialog. INVITE is the only such
- request in this specification, but extensions to the protocol
- MAY define others.
-
- 5. Add Additional Header Fields
-
- The proxy MAY add any other appropriate header fields to the
- copy at this point.
-
- 6. Postprocess routing information
-
- A proxy MAY have a local policy that mandates that a request
- visit a specific set of proxies before being delivered to the
- destination. A proxy MUST ensure that all such proxies are
- loose routers. Generally, this can only be known with
- certainty if the proxies are within the same administrative
- domain. This set of proxies is represented by a set of URIs
- (each of which contains the lr parameter). This set MUST be
- pushed into the Route header field of the copy ahead of any
- existing values, if present. If the Route header field is
- absent, it MUST be added, containing that list of URIs.
-
- If the proxy has a local policy that mandates that the request
- visit one specific proxy, an alternative to pushing a Route
- value into the Route header field is to bypass the forwarding
- logic of item 10 below, and instead just send the request to
- the address, port, and transport for that specific proxy. If
- the request has a Route header field, this alternative MUST NOT
- be used unless it is known that next hop proxy is a loose
- router. Otherwise, this approach MAY be used, but the Route
- insertion mechanism above is preferred for its robustness,
- flexibility, generality and consistency of operation.
- Furthermore, if the Request-URI contains a SIPS URI, TLS MUST
- be used to communicate with that proxy.
-
- If the copy contains a Route header field, the proxy MUST
- inspect the URI in its first value. If that URI does not
- contain an lr parameter, the proxy MUST modify the copy as
- follows:
-
-
-
-Rosenberg, et. al. Standards Track [Page 103]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- - The proxy MUST place the Request-URI into the Route header
- field as the last value.
-
- - The proxy MUST then place the first Route header field value
- into the Request-URI and remove that value from the Route
- header field.
-
- Appending the Request-URI to the Route header field is part of
- a mechanism used to pass the information in that Request-URI
- through strict-routing elements. "Popping" the first Route
- header field value into the Request-URI formats the message the
- way a strict-routing element expects to receive it (with its
- own URI in the Request-URI and the next location to visit in
- the first Route header field value).
-
- 7. Determine Next-Hop Address, Port, and Transport
-
- The proxy MAY have a local policy to send the request to a
- specific IP address, port, and transport, independent of the
- values of the Route and Request-URI. Such a policy MUST NOT be
- used if the proxy is not certain that the IP address, port, and
- transport correspond to a server that is a loose router.
- However, this mechanism for sending the request through a
- specific next hop is NOT RECOMMENDED; instead a Route header
- field should be used for that purpose as described above.
-
- In the absence of such an overriding mechanism, the proxy
- applies the procedures listed in [4] as follows to determine
- where to send the request. If the proxy has reformatted the
- request to send to a strict-routing element as described in
- step 6 above, the proxy MUST apply those procedures to the
- Request-URI of the request. Otherwise, the proxy MUST apply
- the procedures to the first value in the Route header field, if
- present, else the Request-URI. The procedures will produce an
- ordered set of (address, port, transport) tuples.
- Independently of which URI is being used as input to the
- procedures of [4], if the Request-URI specifies a SIPS
- resource, the proxy MUST follow the procedures of [4] as if the
- input URI were a SIPS URI.
-
- As described in [4], the proxy MUST attempt to deliver the
- message to the first tuple in that set, and proceed through the
- set in order until the delivery attempt succeeds.
-
- For each tuple attempted, the proxy MUST format the message as
- appropriate for the tuple and send the request using a new
- client transaction as detailed in steps 8 through 10.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 104]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Since each attempt uses a new client transaction, it represents
- a new branch. Thus, the branch parameter provided with the Via
- header field inserted in step 8 MUST be different for each
- attempt.
-
- If the client transaction reports failure to send the request
- or a timeout from its state machine, the proxy continues to the
- next address in that ordered set. If the ordered set is
- exhausted, the request cannot be forwarded to this element in
- the target set. The proxy does not need to place anything in
- the response context, but otherwise acts as if this element of
- the target set returned a 408 (Request Timeout) final response.
-
- 8. Add a Via header field value
-
- The proxy MUST insert a Via header field value into the copy
- before the existing Via header field values. The construction
- of this value follows the same guidelines of Section 8.1.1.7.
- This implies that the proxy will compute its own branch
- parameter, which will be globally unique for that branch, and
- contain the requisite magic cookie. Note that this implies that
- the branch parameter will be different for different instances
- of a spiraled or looped request through a proxy.
-
- Proxies choosing to detect loops have an additional constraint
- in the value they use for construction of the branch parameter.
- A proxy choosing to detect loops SHOULD create a branch
- parameter separable into two parts by the implementation. The
- first part MUST satisfy the constraints of Section 8.1.1.7 as
- described above. The second is used to perform loop detection
- and distinguish loops from spirals.
-
- Loop detection is performed by verifying that, when a request
- returns to a proxy, those fields having an impact on the
- processing of the request have not changed. The value placed
- in this part of the branch parameter SHOULD reflect all of
- those fields (including any Route, Proxy-Require and Proxy-
- Authorization header fields). This is to ensure that if the
- request is routed back to the proxy and one of those fields
- changes, it is treated as a spiral and not a loop (see Section
- 16.3). A common way to create this value is to compute a
- cryptographic hash of the To tag, From tag, Call-ID header
- field, the Request-URI of the request received (before
- translation), the topmost Via header, and the sequence number
- from the CSeq header field, in addition to any Proxy-Require
- and Proxy-Authorization header fields that may be present. The
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 105]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- algorithm used to compute the hash is implementation-dependent,
- but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a
- reasonable choice. (Base64 is not permissible for a token.)
-
- If a proxy wishes to detect loops, the "branch" parameter it
- supplies MUST depend on all information affecting processing of
- a request, including the incoming Request-URI and any header
- fields affecting the request's admission or routing. This is
- necessary to distinguish looped requests from requests whose
- routing parameters have changed before returning to this
- server.
-
- The request method MUST NOT be included in the calculation of
- the branch parameter. In particular, CANCEL and ACK requests
- (for non-2xx responses) MUST have the same branch value as the
- corresponding request they cancel or acknowledge. The branch
- parameter is used in correlating those requests at the server
- handling them (see Sections 17.2.3 and 9.2).
-
- 9. Add a Content-Length header field if necessary
-
- If the request will be sent to the next hop using a stream-
- based transport and the copy contains no Content-Length header
- field, the proxy MUST insert one with the correct value for the
- body of the request (see Section 20.14).
-
- 10. Forward Request
-
- A stateful proxy MUST create a new client transaction for this
- request as described in Section 17.1 and instructs the
- transaction to send the request using the address, port and
- transport determined in step 7.
-
- 11. Set timer C
-
- In order to handle the case where an INVITE request never
- generates a final response, the TU uses a timer which is called
- timer C. Timer C MUST be set for each client transaction when
- an INVITE request is proxied. The timer MUST be larger than 3
- minutes. Section 16.7 bullet 2 discusses how this timer is
- updated with provisional responses, and Section 16.8 discusses
- processing when it fires.
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 106]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-16.7 Response Processing
-
- When a response is received by an element, it first tries to locate a
- client transaction (Section 17.1.3) matching the response. If none
- is found, the element MUST process the response (even if it is an
- informational response) as a stateless proxy (described below). If a
- match is found, the response is handed to the client transaction.
-
- Forwarding responses for which a client transaction (or more
- generally any knowledge of having sent an associated request) is
- not found improves robustness. In particular, it ensures that
- "late" 2xx responses to INVITE requests are forwarded properly.
-
- As client transactions pass responses to the proxy layer, the
- following processing MUST take place:
-
- 1. Find the appropriate response context
-
- 2. Update timer C for provisional responses
-
- 3. Remove the topmost Via
-
- 4. Add the response to the response context
-
- 5. Check to see if this response should be forwarded immediately
-
- 6. When necessary, choose the best final response from the
- response context
-
- If no final response has been forwarded after every client
- transaction associated with the response context has been terminated,
- the proxy must choose and forward the "best" response from those it
- has seen so far.
-
- The following processing MUST be performed on each response that is
- forwarded. It is likely that more than one response to each request
- will be forwarded: at least each provisional and one final response.
-
- 7. Aggregate authorization header field values if necessary
-
- 8. Optionally rewrite Record-Route header field values
-
- 9. Forward the response
-
- 10. Generate any necessary CANCEL requests
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 107]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Each of the above steps are detailed below:
-
- 1. Find Context
-
- The proxy locates the "response context" it created before
- forwarding the original request using the key described in
- Section 16.6. The remaining processing steps take place in
- this context.
-
- 2. Update timer C for provisional responses
-
- For an INVITE transaction, if the response is a provisional
- response with status codes 101 to 199 inclusive (i.e., anything
- but 100), the proxy MUST reset timer C for that client
- transaction. The timer MAY be reset to a different value, but
- this value MUST be greater than 3 minutes.
-
- 3. Via
-
- The proxy removes the topmost Via header field value from the
- response.
-
- If no Via header field values remain in the response, the
- response was meant for this element and MUST NOT be forwarded.
- The remainder of the processing described in this section is
- not performed on this message, the UAC processing rules
- described in Section 8.1.3 are followed instead (transport
- layer processing has already occurred).
-
- This will happen, for instance, when the element generates
- CANCEL requests as described in Section 10.
-
- 4. Add response to context
-
- Final responses received are stored in the response context
- until a final response is generated on the server transaction
- associated with this context. The response may be a candidate
- for the best final response to be returned on that server
- transaction. Information from this response may be needed in
- forming the best response, even if this response is not chosen.
-
- If the proxy chooses to recurse on any contacts in a 3xx
- response by adding them to the target set, it MUST remove them
- from the response before adding the response to the response
- context. However, a proxy SHOULD NOT recurse to a non-SIPS URI
- if the Request-URI of the original request was a SIPS URI. If
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 108]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- the proxy recurses on all of the contacts in a 3xx response,
- the proxy SHOULD NOT add the resulting contactless response to
- the response context.
-
- Removing the contact before adding the response to the response
- context prevents the next element upstream from retrying a
- location this proxy has already attempted.
-
- 3xx responses may contain a mixture of SIP, SIPS, and non-SIP
- URIs. A proxy may choose to recurse on the SIP and SIPS URIs
- and place the remainder into the response context to be
- returned, potentially in the final response.
-
- If a proxy receives a 416 (Unsupported URI Scheme) response to
- a request whose Request-URI scheme was not SIP, but the scheme
- in the original received request was SIP or SIPS (that is, the
- proxy changed the scheme from SIP or SIPS to something else
- when it proxied a request), the proxy SHOULD add a new URI to
- the target set. This URI SHOULD be a SIP URI version of the
- non-SIP URI that was just tried. In the case of the tel URL,
- this is accomplished by placing the telephone-subscriber part
- of the tel URL into the user part of the SIP URI, and setting
- the hostpart to the domain where the prior request was sent.
- See Section 19.1.6 for more detail on forming SIP URIs from tel
- URLs.
-
- As with a 3xx response, if a proxy "recurses" on the 416 by
- trying a SIP or SIPS URI instead, the 416 response SHOULD NOT
- be added to the response context.
-
- 5. Check response for forwarding
-
- Until a final response has been sent on the server transaction,
- the following responses MUST be forwarded immediately:
-
- - Any provisional response other than 100 (Trying)
-
- - Any 2xx response
-
- If a 6xx response is received, it is not immediately forwarded,
- but the stateful proxy SHOULD cancel all client pending
- transactions as described in Section 10, and it MUST NOT create
- any new branches in this context.
-
- This is a change from RFC 2543, which mandated that the proxy
- was to forward the 6xx response immediately. For an INVITE
- transaction, this approach had the problem that a 2xx response
- could arrive on another branch, in which case the proxy would
-
-
-
-Rosenberg, et. al. Standards Track [Page 109]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- have to forward the 2xx. The result was that the UAC could
- receive a 6xx response followed by a 2xx response, which should
- never be allowed to happen. Under the new rules, upon
- receiving a 6xx, a proxy will issue a CANCEL request, which
- will generally result in 487 responses from all outstanding
- client transactions, and then at that point the 6xx is
- forwarded upstream.
-
- After a final response has been sent on the server transaction,
- the following responses MUST be forwarded immediately:
-
- - Any 2xx response to an INVITE request
-
- A stateful proxy MUST NOT immediately forward any other
- responses. In particular, a stateful proxy MUST NOT forward
- any 100 (Trying) response. Those responses that are candidates
- for forwarding later as the "best" response have been gathered
- as described in step "Add Response to Context".
-
- Any response chosen for immediate forwarding MUST be processed
- as described in steps "Aggregate Authorization Header Field
- Values" through "Record-Route".
-
- This step, combined with the next, ensures that a stateful
- proxy will forward exactly one final response to a non-INVITE
- request, and either exactly one non-2xx response or one or more
- 2xx responses to an INVITE request.
-
- 6. Choosing the best response
-
- A stateful proxy MUST send a final response to a response
- context's server transaction if no final responses have been
- immediately forwarded by the above rules and all client
- transactions in this response context have been terminated.
-
- The stateful proxy MUST choose the "best" final response among
- those received and stored in the response context.
-
- If there are no final responses in the context, the proxy MUST
- send a 408 (Request Timeout) response to the server
- transaction.
-
- Otherwise, the proxy MUST forward a response from the responses
- stored in the response context. It MUST choose from the 6xx
- class responses if any exist in the context. If no 6xx class
- responses are present, the proxy SHOULD choose from the lowest
- response class stored in the response context. The proxy MAY
- select any response within that chosen class. The proxy SHOULD
-
-
-
-Rosenberg, et. al. Standards Track [Page 110]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- give preference to responses that provide information affecting
- resubmission of this request, such as 401, 407, 415, 420, and
- 484 if the 4xx class is chosen.
-
- A proxy which receives a 503 (Service Unavailable) response
- SHOULD NOT forward it upstream unless it can determine that any
- subsequent requests it might proxy will also generate a 503.
- In other words, forwarding a 503 means that the proxy knows it
- cannot service any requests, not just the one for the Request-
- URI in the request which generated the 503. If the only
- response that was received is a 503, the proxy SHOULD generate
- a 500 response and forward that upstream.
-
- The forwarded response MUST be processed as described in steps
- "Aggregate Authorization Header Field Values" through "Record-
- Route".
-
- For example, if a proxy forwarded a request to 4 locations, and
- received 503, 407, 501, and 404 responses, it may choose to
- forward the 407 (Proxy Authentication Required) response.
-
- 1xx and 2xx responses may be involved in the establishment of
- dialogs. When a request does not contain a To tag, the To tag
- in the response is used by the UAC to distinguish multiple
- responses to a dialog creating request. A proxy MUST NOT
- insert a tag into the To header field of a 1xx or 2xx response
- if the request did not contain one. A proxy MUST NOT modify
- the tag in the To header field of a 1xx or 2xx response.
-
- Since a proxy may not insert a tag into the To header field of
- a 1xx response to a request that did not contain one, it cannot
- issue non-100 provisional responses on its own. However, it
- can branch the request to a UAS sharing the same element as the
- proxy. This UAS can return its own provisional responses,
- entering into an early dialog with the initiator of the
- request. The UAS does not have to be a discreet process from
- the proxy. It could be a virtual UAS implemented in the same
- code space as the proxy.
-
- 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx
- response, the element is effectively acting as a UAS, issuing
- its own response, usually based on the responses received from
- downstream elements. An element SHOULD preserve the To tag
- when simply forwarding a 3-6xx response to a request that did
- not contain a To tag.
-
- A proxy MUST NOT modify the To tag in any forwarded response to
- a request that contains a To tag.
-
-
-
-Rosenberg, et. al. Standards Track [Page 111]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- While it makes no difference to the upstream elements if the
- proxy replaced the To tag in a forwarded 3-6xx response,
- preserving the original tag may assist with debugging.
-
- When the proxy is aggregating information from several
- responses, choosing a To tag from among them is arbitrary, and
- generating a new To tag may make debugging easier. This
- happens, for instance, when combining 401 (Unauthorized) and
- 407 (Proxy Authentication Required) challenges, or combining
- Contact values from unencrypted and unauthenticated 3xx
- responses.
-
- 7. Aggregate Authorization Header Field Values
-
- If the selected response is a 401 (Unauthorized) or 407 (Proxy
- Authentication Required), the proxy MUST collect any WWW-
- Authenticate and Proxy-Authenticate header field values from
- all other 401 (Unauthorized) and 407 (Proxy Authentication
- Required) responses received so far in this response context
- and add them to this response without modification before
- forwarding. The resulting 401 (Unauthorized) or 407 (Proxy
- Authentication Required) response could have several WWW-
- Authenticate AND Proxy-Authenticate header field values.
-
- This is necessary because any or all of the destinations the
- request was forwarded to may have requested credentials. The
- client needs to receive all of those challenges and supply
- credentials for each of them when it retries the request.
- Motivation for this behavior is provided in Section 26.
-
- 8. Record-Route
-
- If the selected response contains a Record-Route header field
- value originally provided by this proxy, the proxy MAY choose
- to rewrite the value before forwarding the response. This
- allows the proxy to provide different URIs for itself to the
- next upstream and downstream elements. A proxy may choose to
- use this mechanism for any reason. For instance, it is useful
- for multi-homed hosts.
-
- If the proxy received the request over TLS, and sent it out
- over a non-TLS connection, the proxy MUST rewrite the URI in
- the Record-Route header field to be a SIPS URI. If the proxy
- received the request over a non-TLS connection, and sent it out
- over TLS, the proxy MUST rewrite the URI in the Record-Route
- header field to be a SIP URI.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 112]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The new URI provided by the proxy MUST satisfy the same
- constraints on URIs placed in Record-Route header fields in
- requests (see Step 4 of Section 16.6) with the following
- modifications:
-
- The URI SHOULD NOT contain the transport parameter unless the
- proxy has knowledge that the next upstream (as opposed to
- downstream) element that will be in the path of subsequent
- requests supports that transport.
-
- When a proxy does decide to modify the Record-Route header
- field in the response, one of the operations it performs is
- locating the Record-Route value that it had inserted. If the
- request spiraled, and the proxy inserted a Record-Route value
- in each iteration of the spiral, locating the correct value in
- the response (which must be the proper iteration in the reverse
- direction) is tricky. The rules above recommend that a proxy
- wishing to rewrite Record-Route header field values insert
- sufficiently distinct URIs into the Record-Route header field
- so that the right one may be selected for rewriting. A
- RECOMMENDED mechanism to achieve this is for the proxy to
- append a unique identifier for the proxy instance to the user
- portion of the URI.
-
- When the response arrives, the proxy modifies the first
- Record-Route whose identifier matches the proxy instance. The
- modification results in a URI without this piece of data
- appended to the user portion of the URI. Upon the next
- iteration, the same algorithm (find the topmost Record-Route
- header field value with the parameter) will correctly extract
- the next Record-Route header field value inserted by that
- proxy.
-
- Not every response to a request to which a proxy adds a
- Record-Route header field value will contain a Record-Route
- header field. If the response does contain a Record-Route
- header field, it will contain the value the proxy added.
-
- 9. Forward response
-
- After performing the processing described in steps "Aggregate
- Authorization Header Field Values" through "Record-Route", the
- proxy MAY perform any feature specific manipulations on the
- selected response. The proxy MUST NOT add to, modify, or
- remove the message body. Unless otherwise specified, the proxy
- MUST NOT remove any header field values other than the Via
- header field value discussed in Section 16.7 Item 3. In
- particular, the proxy MUST NOT remove any "received" parameter
-
-
-
-Rosenberg, et. al. Standards Track [Page 113]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- it may have added to the next Via header field value while
- processing the request associated with this response. The
- proxy MUST pass the response to the server transaction
- associated with the response context. This will result in the
- response being sent to the location now indicated in the
- topmost Via header field value. If the server transaction is
- no longer available to handle the transmission, the element
- MUST forward the response statelessly by sending it to the
- server transport. The server transaction might indicate
- failure to send the response or signal a timeout in its state
- machine. These errors would be logged for diagnostic purposes
- as appropriate, but the protocol requires no remedial action
- from the proxy.
-
- The proxy MUST maintain the response context until all of its
- associated transactions have been terminated, even after
- forwarding a final response.
-
- 10. Generate CANCELs
-
- If the forwarded response was a final response, the proxy MUST
- generate a CANCEL request for all pending client transactions
- associated with this response context. A proxy SHOULD also
- generate a CANCEL request for all pending client transactions
- associated with this response context when it receives a 6xx
- response. A pending client transaction is one that has
- received a provisional response, but no final response (it is
- in the proceeding state) and has not had an associated CANCEL
- generated for it. Generating CANCEL requests is described in
- Section 9.1.
-
- The requirement to CANCEL pending client transactions upon
- forwarding a final response does not guarantee that an endpoint
- will not receive multiple 200 (OK) responses to an INVITE. 200
- (OK) responses on more than one branch may be generated before
- the CANCEL requests can be sent and processed. Further, it is
- reasonable to expect that a future extension may override this
- requirement to issue CANCEL requests.
-
-16.8 Processing Timer C
-
- If timer C should fire, the proxy MUST either reset the timer with
- any value it chooses, or terminate the client transaction. If the
- client transaction has received a provisional response, the proxy
- MUST generate a CANCEL request matching that transaction. If the
- client transaction has not received a provisional response, the proxy
- MUST behave as if the transaction received a 408 (Request Timeout)
- response.
-
-
-
-Rosenberg, et. al. Standards Track [Page 114]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Allowing the proxy to reset the timer allows the proxy to dynamically
- extend the transaction's lifetime based on current conditions (such
- as utilization) when the timer fires.
-
-16.9 Handling Transport Errors
-
- If the transport layer notifies a proxy of an error when it tries to
- forward a request (see Section 18.4), the proxy MUST behave as if the
- forwarded request received a 503 (Service Unavailable) response.
-
- If the proxy is notified of an error when forwarding a response, it
- drops the response. The proxy SHOULD NOT cancel any outstanding
- client transactions associated with this response context due to this
- notification.
-
- If a proxy cancels its outstanding client transactions, a single
- malicious or misbehaving client can cause all transactions to fail
- through its Via header field.
-
-16.10 CANCEL Processing
-
- A stateful proxy MAY generate a CANCEL to any other request it has
- generated at any time (subject to receiving a provisional response to
- that request as described in section 9.1). A proxy MUST cancel any
- pending client transactions associated with a response context when
- it receives a matching CANCEL request.
-
- A stateful proxy MAY generate CANCEL requests for pending INVITE
- client transactions based on the period specified in the INVITE's
- Expires header field elapsing. However, this is generally
- unnecessary since the endpoints involved will take care of signaling
- the end of the transaction.
-
- While a CANCEL request is handled in a stateful proxy by its own
- server transaction, a new response context is not created for it.
- Instead, the proxy layer searches its existing response contexts for
- the server transaction handling the request associated with this
- CANCEL. If a matching response context is found, the element MUST
- immediately return a 200 (OK) response to the CANCEL request. In
- this case, the element is acting as a user agent server as defined in
- Section 8.2. Furthermore, the element MUST generate CANCEL requests
- for all pending client transactions in the context as described in
- Section 16.7 step 10.
-
- If a response context is not found, the element does not have any
- knowledge of the request to apply the CANCEL to. It MUST statelessly
- forward the CANCEL request (it may have statelessly forwarded the
- associated request previously).
-
-
-
-Rosenberg, et. al. Standards Track [Page 115]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-16.11 Stateless Proxy
-
- When acting statelessly, a proxy is a simple message forwarder. Much
- of the processing performed when acting statelessly is the same as
- when behaving statefully. The differences are detailed here.
-
- A stateless proxy does not have any notion of a transaction, or of
- the response context used to describe stateful proxy behavior.
- Instead, the stateless proxy takes messages, both requests and
- responses, directly from the transport layer (See section 18). As a
- result, stateless proxies do not retransmit messages on their own.
- They do, however, forward all retransmissions they receive (they do
- not have the ability to distinguish a retransmission from the
- original message). Furthermore, when handling a request statelessly,
- an element MUST NOT generate its own 100 (Trying) or any other
- provisional response.
-
- A stateless proxy MUST validate a request as described in Section
- 16.3
-
- A stateless proxy MUST follow the request processing steps described
- in Sections 16.4 through 16.5 with the following exception:
-
- o A stateless proxy MUST choose one and only one target from the
- target set. This choice MUST only rely on fields in the
- message and time-invariant properties of the server. In
- particular, a retransmitted request MUST be forwarded to the
- same destination each time it is processed. Furthermore,
- CANCEL and non-Routed ACK requests MUST generate the same
- choice as their associated INVITE.
-
- A stateless proxy MUST follow the request processing steps described
- in Section 16.6 with the following exceptions:
-
- o The requirement for unique branch IDs across space and time
- applies to stateless proxies as well. However, a stateless
- proxy cannot simply use a random number generator to compute
- the first component of the branch ID, as described in Section
- 16.6 bullet 8. This is because retransmissions of a request
- need to have the same value, and a stateless proxy cannot tell
- a retransmission from the original request. Therefore, the
- component of the branch parameter that makes it unique MUST be
- the same each time a retransmitted request is forwarded. Thus
- for a stateless proxy, the branch parameter MUST be computed as
- a combinatoric function of message parameters which are
- invariant on retransmission.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 116]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The stateless proxy MAY use any technique it likes to guarantee
- uniqueness of its branch IDs across transactions. However, the
- following procedure is RECOMMENDED. The proxy examines the
- branch ID in the topmost Via header field of the received
- request. If it begins with the magic cookie, the first
- component of the branch ID of the outgoing request is computed
- as a hash of the received branch ID. Otherwise, the first
- component of the branch ID is computed as a hash of the topmost
- Via, the tag in the To header field, the tag in the From header
- field, the Call-ID header field, the CSeq number (but not
- method), and the Request-URI from the received request. One of
- these fields will always vary across two different
- transactions.
-
- o All other message transformations specified in Section 16.6
- MUST result in the same transformation of a retransmitted
- request. In particular, if the proxy inserts a Record-Route
- value or pushes URIs into the Route header field, it MUST place
- the same values in retransmissions of the request. As for the
- Via branch parameter, this implies that the transformations
- MUST be based on time-invariant configuration or
- retransmission-invariant properties of the request.
-
- o A stateless proxy determines where to forward the request as
- described for stateful proxies in Section 16.6 Item 10. The
- request is sent directly to the transport layer instead of
- through a client transaction.
-
- Since a stateless proxy must forward retransmitted requests to
- the same destination and add identical branch parameters to
- each of them, it can only use information from the message
- itself and time-invariant configuration data for those
- calculations. If the configuration state is not time-invariant
- (for example, if a routing table is updated) any requests that
- could be affected by the change may not be forwarded
- statelessly during an interval equal to the transaction timeout
- window before or after the change. The method of processing
- the affected requests in that interval is an implementation
- decision. A common solution is to forward them transaction
- statefully.
-
- Stateless proxies MUST NOT perform special processing for CANCEL
- requests. They are processed by the above rules as any other
- requests. In particular, a stateless proxy applies the same Route
- header field processing to CANCEL requests that it applies to any
- other request.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 117]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Response processing as described in Section 16.7 does not apply to a
- proxy behaving statelessly. When a response arrives at a stateless
- proxy, the proxy MUST inspect the sent-by value in the first
- (topmost) Via header field value. If that address matches the proxy,
- (it equals a value this proxy has inserted into previous requests)
- the proxy MUST remove that header field value from the response and
- forward the result to the location indicated in the next Via header
- field value. The proxy MUST NOT add to, modify, or remove the
- message body. Unless specified otherwise, the proxy MUST NOT remove
- any other header field values. If the address does not match the
- proxy, the message MUST be silently discarded.
-
-16.12 Summary of Proxy Route Processing
-
- In the absence of local policy to the contrary, the processing a
- proxy performs on a request containing a Route header field can be
- summarized in the following steps.
-
- 1. The proxy will inspect the Request-URI. If it indicates a
- resource owned by this proxy, the proxy will replace it with
- the results of running a location service. Otherwise, the
- proxy will not change the Request-URI.
-
- 2. The proxy will inspect the URI in the topmost Route header
- field value. If it indicates this proxy, the proxy removes it
- from the Route header field (this route node has been
- reached).
-
- 3. The proxy will forward the request to the resource indicated
- by the URI in the topmost Route header field value or in the
- Request-URI if no Route header field is present. The proxy
- determines the address, port and transport to use when
- forwarding the request by applying the procedures in [4] to
- that URI.
-
- If no strict-routing elements are encountered on the path of the
- request, the Request-URI will always indicate the target of the
- request.
-
-16.12.1 Examples
-
-16.12.1.1 Basic SIP Trapezoid
-
- This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with
- both proxies record-routing. Here is the flow.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 118]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- U1 sends:
-
- INVITE sip:callee@domain.com SIP/2.0
- Contact: sip:caller@u1.example.com
-
- to P1. P1 is an outbound proxy. P1 is not responsible for
- domain.com, so it looks it up in DNS and sends it there. It also
- adds a Record-Route header field value:
-
- INVITE sip:callee@domain.com SIP/2.0
- Contact: sip:caller@u1.example.com
- Record-Route: <sip:p1.example.com;lr>
-
- P2 gets this. It is responsible for domain.com so it runs a location
- service and rewrites the Request-URI. It also adds a Record-Route
- header field value. There is no Route header field, so it resolves
- the new Request-URI to determine where to send the request:
-
- INVITE sip:callee@u2.domain.com SIP/2.0
- Contact: sip:caller@u1.example.com
- Record-Route: <sip:p2.domain.com;lr>
- Record-Route: <sip:p1.example.com;lr>
-
- The callee at u2.domain.com gets this and responds with a 200 OK:
-
- SIP/2.0 200 OK
- Contact: sip:callee@u2.domain.com
- Record-Route: <sip:p2.domain.com;lr>
- Record-Route: <sip:p1.example.com;lr>
-
- The callee at u2 also sets its dialog state's remote target URI to
- sip:caller@u1.example.com and its route set to:
-
- (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
-
- This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its
- dialog state's remote target URI to sip:callee@u2.domain.com and its
- route set to:
-
- (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
-
- Since all the route set elements contain the lr parameter, U1
- constructs the following BYE request:
-
- BYE sip:callee@u2.domain.com SIP/2.0
- Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 119]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- As any other element (including proxies) would do, it resolves the
- URI in the topmost Route header field value using DNS to determine
- where to send the request. This goes to P1. P1 notices that it is
- not responsible for the resource indicated in the Request-URI so it
- doesn't change it. It does see that it is the first value in the
- Route header field, so it removes that value, and forwards the
- request to P2:
-
- BYE sip:callee@u2.domain.com SIP/2.0
- Route: <sip:p2.domain.com;lr>
-
- P2 also notices it is not responsible for the resource indicated by
- the Request-URI (it is responsible for domain.com, not
- u2.domain.com), so it doesn't change it. It does see itself in the
- first Route header field value, so it removes it and forwards the
- following to u2.domain.com based on a DNS lookup against the
- Request-URI:
-
- BYE sip:callee@u2.domain.com SIP/2.0
-
-16.12.1.2 Traversing a Strict-Routing Proxy
-
- In this scenario, a dialog is established across four proxies, each
- of which adds Record-Route header field values. The third proxy
- implements the strict-routing procedures specified in RFC 2543 and
- many works in progress.
-
- U1->P1->P2->P3->P4->U2
-
- The INVITE arriving at U2 contains:
-
- INVITE sip:callee@u2.domain.com SIP/2.0
- Contact: sip:caller@u1.example.com
- Record-Route: <sip:p4.domain.com;lr>
- Record-Route: <sip:p3.middle.com>
- Record-Route: <sip:p2.example.com;lr>
- Record-Route: <sip:p1.example.com;lr>
-
- Which U2 responds to with a 200 OK. Later, U2 sends the following
- BYE request to P4 based on the first Route header field value.
-
- BYE sip:caller@u1.example.com SIP/2.0
- Route: <sip:p4.domain.com;lr>
- Route: <sip:p3.middle.com>
- Route: <sip:p2.example.com;lr>
- Route: <sip:p1.example.com;lr>
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 120]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- P4 is not responsible for the resource indicated in the Request-URI
- so it will leave it alone. It notices that it is the element in the
- first Route header field value so it removes it. It then prepares to
- send the request based on the now first Route header field value of
- sip:p3.middle.com, but it notices that this URI does not contain the
- lr parameter, so before sending, it reformats the request to be:
-
- BYE sip:p3.middle.com SIP/2.0
- Route: <sip:p2.example.com;lr>
- Route: <sip:p1.example.com;lr>
- Route: <sip:caller@u1.example.com>
-
- P3 is a strict router, so it forwards the following to P2:
-
- BYE sip:p2.example.com;lr SIP/2.0
- Route: <sip:p1.example.com;lr>
- Route: <sip:caller@u1.example.com>
-
- P2 sees the request-URI is a value it placed into a Record-Route
- header field, so before further processing, it rewrites the request
- to be:
-
- BYE sip:caller@u1.example.com SIP/2.0
- Route: <sip:p1.example.com;lr>
-
- P2 is not responsible for u1.example.com, so it sends the request to
- P1 based on the resolution of the Route header field value.
-
- P1 notices itself in the topmost Route header field value, so it
- removes it, resulting in:
-
- BYE sip:caller@u1.example.com SIP/2.0
-
- Since P1 is not responsible for u1.example.com and there is no Route
- header field, P1 will forward the request to u1.example.com based on
- the Request-URI.
-
-16.12.1.3 Rewriting Record-Route Header Field Values
-
- In this scenario, U1 and U2 are in different private namespaces and
- they enter a dialog through a proxy P1, which acts as a gateway
- between the namespaces.
-
- U1->P1->U2
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 121]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- U1 sends:
-
- INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
- Contact: <sip:caller@u1.leftprivatespace.com>
-
- P1 uses its location service and sends the following to U2:
-
- INVITE sip:callee@rightprivatespace.com SIP/2.0
- Contact: <sip:caller@u1.leftprivatespace.com>
- Record-Route: <sip:gateway.rightprivatespace.com;lr>
-
- U2 sends this 200 (OK) back to P1:
-
- SIP/2.0 200 OK
- Contact: <sip:callee@u2.rightprivatespace.com>
- Record-Route: <sip:gateway.rightprivatespace.com;lr>
-
- P1 rewrites its Record-Route header parameter to provide a value that
- U1 will find useful, and sends the following to U1:
-
- SIP/2.0 200 OK
- Contact: <sip:callee@u2.rightprivatespace.com>
- Record-Route: <sip:gateway.leftprivatespace.com;lr>
-
- Later, U1 sends the following BYE request to P1:
-
- BYE sip:callee@u2.rightprivatespace.com SIP/2.0
- Route: <sip:gateway.leftprivatespace.com;lr>
-
- which P1 forwards to U2 as:
-
- BYE sip:callee@u2.rightprivatespace.com SIP/2.0
-
-17 Transactions
-
- SIP is a transactional protocol: interactions between components take
- place in a series of independent message exchanges. Specifically, a
- SIP transaction consists of a single request and any responses to
- that request, which include zero or more provisional responses and
- one or more final responses. In the case of a transaction where the
- request was an INVITE (known as an INVITE transaction), the
- transaction also includes the ACK only if the final response was not
- a 2xx response. If the response was a 2xx, the ACK is not considered
- part of the transaction.
-
- The reason for this separation is rooted in the importance of
- delivering all 200 (OK) responses to an INVITE to the UAC. To
- deliver them all to the UAC, the UAS alone takes responsibility
-
-
-
-Rosenberg, et. al. Standards Track [Page 122]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- for retransmitting them (see Section 13.3.1.4), and the UAC alone
- takes responsibility for acknowledging them with ACK (see Section
- 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is
- effectively considered its own transaction.
-
- Transactions have a client side and a server side. The client side
- is known as a client transaction and the server side as a server
- transaction. The client transaction sends the request, and the
- server transaction sends the response. The client and server
- transactions are logical functions that are embedded in any number of
- elements. Specifically, they exist within user agents and stateful
- proxy servers. Consider the example in Section 4. In this example,
- the UAC executes the client transaction, and its outbound proxy
- executes the server transaction. The outbound proxy also executes a
- client transaction, which sends the request to a server transaction
- in the inbound proxy. That proxy also executes a client transaction,
- which in turn sends the request to a server transaction in the UAS.
- This is shown in Figure 4.
-
- +---------+ +---------+ +---------+ +---------+
- | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ |
- | |C||------->||S| |C||------->||S| |C||------->||S| |
- | |l|| ||e| |l|| ||e| |l|| ||e| |
- | |i|| ||r| |i|| ||r| |i|| ||r| |
- | |e|| ||v| |e|| ||v| |e|| ||v| |
- | |n|| ||e| |n|| ||e| |n|| ||e| |
- | |t|| ||r| |t|| ||r| |t|| ||r| |
- | | || || | | || || | | || || | |
- | |T|| ||T| |T|| ||T| |T|| ||T| |
- | |r|| ||r| |r|| ||r| |r|| ||r| |
- | |a|| ||a| |a|| ||a| |a|| ||a| |
- | |n|| ||n| |n|| ||n| |n|| ||n| |
- | |s||Response||s| |s||Response||s| |s||Response||s| |
- | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ |
- +---------+ +---------+ +---------+ +---------+
- UAC Outbound Inbound UAS
- Proxy Proxy
-
- Figure 4: Transaction relationships
-
- A stateless proxy does not contain a client or server transaction.
- The transaction exists between the UA or stateful proxy on one side,
- and the UA or stateful proxy on the other side. As far as SIP
- transactions are concerned, stateless proxies are effectively
- transparent. The purpose of the client transaction is to receive a
- request from the element in which the client is embedded (call this
- element the "Transaction User" or TU; it can be a UA or a stateful
- proxy), and reliably deliver the request to a server transaction.
-
-
-
-Rosenberg, et. al. Standards Track [Page 123]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The client transaction is also responsible for receiving responses
- and delivering them to the TU, filtering out any response
- retransmissions or disallowed responses (such as a response to ACK).
- Additionally, in the case of an INVITE request, the client
- transaction is responsible for generating the ACK request for any
- final response accepting a 2xx response.
-
- Similarly, the purpose of the server transaction is to receive
- requests from the transport layer and deliver them to the TU. The
- server transaction filters any request retransmissions from the
- network. The server transaction accepts responses from the TU and
- delivers them to the transport layer for transmission over the
- network. In the case of an INVITE transaction, it absorbs the ACK
- request for any final response excepting a 2xx response.
-
- The 2xx response and its ACK receive special treatment. This
- response is retransmitted only by a UAS, and its ACK generated only
- by the UAC. This end-to-end treatment is needed so that a caller
- knows the entire set of users that have accepted the call. Because
- of this special handling, retransmissions of the 2xx response are
- handled by the UA core, not the transaction layer. Similarly,
- generation of the ACK for the 2xx is handled by the UA core. Each
- proxy along the path merely forwards each 2xx response to INVITE and
- its corresponding ACK.
-
-17.1 Client Transaction
-
- The client transaction provides its functionality through the
- maintenance of a state machine.
-
- The TU communicates with the client transaction through a simple
- interface. When the TU wishes to initiate a new transaction, it
- creates a client transaction and passes it the SIP request to send
- and an IP address, port, and transport to which to send it. The
- client transaction begins execution of its state machine. Valid
- responses are passed up to the TU from the client transaction.
-
- There are two types of client transaction state machines, depending
- on the method of the request passed by the TU. One handles client
- transactions for INVITE requests. This type of machine is referred
- to as an INVITE client transaction. Another type handles client
- transactions for all requests except INVITE and ACK. This is
- referred to as a non-INVITE client transaction. There is no client
- transaction for ACK. If the TU wishes to send an ACK, it passes one
- directly to the transport layer for transmission.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 124]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The INVITE transaction is different from those of other methods
- because of its extended duration. Normally, human input is required
- in order to respond to an INVITE. The long delays expected for
- sending a response argue for a three-way handshake. On the other
- hand, requests of other methods are expected to complete rapidly.
- Because of the non-INVITE transaction's reliance on a two-way
- handshake, TUs SHOULD respond immediately to non-INVITE requests.
-
-17.1.1 INVITE Client Transaction
-
-17.1.1.1 Overview of INVITE Transaction
-
- The INVITE transaction consists of a three-way handshake. The client
- transaction sends an INVITE, the server transaction sends responses,
- and the client transaction sends an ACK. For unreliable transports
- (such as UDP), the client transaction retransmits requests at an
- interval that starts at T1 seconds and doubles after every
- retransmission. T1 is an estimate of the round-trip time (RTT), and
- it defaults to 500 ms. Nearly all of the transaction timers
- described here scale with T1, and changing T1 adjusts their values.
- The request is not retransmitted over reliable transports. After
- receiving a 1xx response, any retransmissions cease altogether, and
- the client waits for further responses. The server transaction can
- send additional 1xx responses, which are not transmitted reliably by
- the server transaction. Eventually, the server transaction decides
- to send a final response. For unreliable transports, that response
- is retransmitted periodically, and for reliable transports, it is
- sent once. For each final response that is received at the client
- transaction, the client transaction sends an ACK, the purpose of
- which is to quench retransmissions of the response.
-
-17.1.1.2 Formal Description
-
- The state machine for the INVITE client transaction is shown in
- Figure 5. The initial state, "calling", MUST be entered when the TU
- initiates a new client transaction with an INVITE request. The
- client transaction MUST pass the request to the transport layer for
- transmission (see Section 18). If an unreliable transport is being
- used, the client transaction MUST start timer A with a value of T1.
- If a reliable transport is being used, the client transaction SHOULD
- NOT start timer A (Timer A controls request retransmissions). For
- any transport, the client transaction MUST start timer B with a value
- of 64*T1 seconds (Timer B controls transaction timeouts).
-
- When timer A fires, the client transaction MUST retransmit the
- request by passing it to the transport layer, and MUST reset the
- timer with a value of 2*T1. The formal definition of retransmit
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 125]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- within the context of the transaction layer is to take the message
- previously sent to the transport layer and pass it to the transport
- layer once more.
-
- When timer A fires 2*T1 seconds later, the request MUST be
- retransmitted again (assuming the client transaction is still in this
- state). This process MUST continue so that the request is
- retransmitted with intervals that double after each transmission.
- These retransmissions SHOULD only be done while the client
- transaction is in the "calling" state.
-
- The default value for T1 is 500 ms. T1 is an estimate of the RTT
- between the client and server transactions. Elements MAY (though it
- is NOT RECOMMENDED) use smaller values of T1 within closed, private
- networks that do not permit general Internet connection. T1 MAY be
- chosen larger, and this is RECOMMENDED if it is known in advance
- (such as on high latency access links) that the RTT is larger.
- Whatever the value of T1, the exponential backoffs on retransmissions
- described in this section MUST be used.
-
- If the client transaction is still in the "Calling" state when timer
- B fires, the client transaction SHOULD inform the TU that a timeout
- has occurred. The client transaction MUST NOT generate an ACK. The
- value of 64*T1 is equal to the amount of time required to send seven
- requests in the case of an unreliable transport.
-
- If the client transaction receives a provisional response while in
- the "Calling" state, it transitions to the "Proceeding" state. In the
- "Proceeding" state, the client transaction SHOULD NOT retransmit the
- request any longer. Furthermore, the provisional response MUST be
- passed to the TU. Any further provisional responses MUST be passed
- up to the TU while in the "Proceeding" state.
-
- When in either the "Calling" or "Proceeding" states, reception of a
- response with status code from 300-699 MUST cause the client
- transaction to transition to "Completed". The client transaction
- MUST pass the received response up to the TU, and the client
- transaction MUST generate an ACK request, even if the transport is
- reliable (guidelines for constructing the ACK from the response are
- given in Section 17.1.1.3) and then pass the ACK to the transport
- layer for transmission. The ACK MUST be sent to the same address,
- port, and transport to which the original request was sent. The
- client transaction SHOULD start timer D when it enters the
- "Completed" state, with a value of at least 32 seconds for unreliable
- transports, and a value of zero seconds for reliable transports.
- Timer D reflects the amount of time that the server transaction can
- remain in the "Completed" state when unreliable transports are used.
- This is equal to Timer H in the INVITE server transaction, whose
-
-
-
-Rosenberg, et. al. Standards Track [Page 126]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- default is 64*T1. However, the client transaction does not know the
- value of T1 in use by the server transaction, so an absolute minimum
- of 32s is used instead of basing Timer D on T1.
-
- Any retransmissions of the final response that are received while in
- the "Completed" state MUST cause the ACK to be re-passed to the
- transport layer for retransmission, but the newly received response
- MUST NOT be passed up to the TU. A retransmission of the response is
- defined as any response which would match the same client transaction
- based on the rules of Section 17.1.3.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 127]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- |INVITE from TU
- Timer A fires |INVITE sent
- Reset A, V Timer B fires
- INVITE sent +-----------+ or Transport Err.
- +---------| |---------------+inform TU
- | | Calling | |
- +-------->| |-------------->|
- +-----------+ 2xx |
- | | 2xx to TU |
- | |1xx |
- 300-699 +---------------+ |1xx to TU |
- ACK sent | | |
-resp. to TU | 1xx V |
- | 1xx to TU -----------+ |
- | +---------| | |
- | | |Proceeding |-------------->|
- | +-------->| | 2xx |
- | +-----------+ 2xx to TU |
- | 300-699 | |
- | ACK sent, | |
- | resp. to TU| |
- | | | NOTE:
- | 300-699 V |
- | ACK sent +-----------+Transport Err. | transitions
- | +---------| |Inform TU | labeled with
- | | | Completed |-------------->| the event
- | +-------->| | | over the action
- | +-----------+ | to take
- | ^ | |
- | | | Timer D fires |
- +--------------+ | - |
- | |
- V |
- +-----------+ |
- | | |
- | Terminated|<--------------+
- | |
- +-----------+
-
- Figure 5: INVITE client transaction
-
- If timer D fires while the client transaction is in the "Completed"
- state, the client transaction MUST move to the terminated state.
-
- When in either the "Calling" or "Proceeding" states, reception of a
- 2xx response MUST cause the client transaction to enter the
- "Terminated" state, and the response MUST be passed up to the TU.
- The handling of this response depends on whether the TU is a proxy
-
-
-
-Rosenberg, et. al. Standards Track [Page 128]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- core or a UAC core. A UAC core will handle generation of the ACK for
- this response, while a proxy core will always forward the 200 (OK)
- upstream. The differing treatment of 200 (OK) between proxy and UAC
- is the reason that handling of it does not take place in the
- transaction layer.
-
- The client transaction MUST be destroyed the instant it enters the
- "Terminated" state. This is actually necessary to guarantee correct
- operation. The reason is that 2xx responses to an INVITE are treated
- differently; each one is forwarded by proxies, and the ACK handling
- in a UAC is different. Thus, each 2xx needs to be passed to a proxy
- core (so that it can be forwarded) and to a UAC core (so it can be
- acknowledged). No transaction layer processing takes place.
- Whenever a response is received by the transport, if the transport
- layer finds no matching client transaction (using the rules of
- Section 17.1.3), the response is passed directly to the core. Since
- the matching client transaction is destroyed by the first 2xx,
- subsequent 2xx will find no match and therefore be passed to the
- core.
-
-17.1.1.3 Construction of the ACK Request
-
- This section specifies the construction of ACK requests sent within
- the client transaction. A UAC core that generates an ACK for 2xx
- MUST instead follow the rules described in Section 13.
-
- The ACK request constructed by the client transaction MUST contain
- values for the Call-ID, From, and Request-URI that are equal to the
- values of those header fields in the request passed to the transport
- by the client transaction (call this the "original request"). The To
- header field in the ACK MUST equal the To header field in the
- response being acknowledged, and therefore will usually differ from
- the To header field in the original request by the addition of the
- tag parameter. The ACK MUST contain a single Via header field, and
- this MUST be equal to the top Via header field of the original
- request. The CSeq header field in the ACK MUST contain the same
- value for the sequence number as was present in the original request,
- but the method parameter MUST be equal to "ACK".
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 129]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- If the INVITE request whose response is being acknowledged had Route
- header fields, those header fields MUST appear in the ACK. This is
- to ensure that the ACK can be routed properly through any downstream
- stateless proxies.
-
- Although any request MAY contain a body, a body in an ACK is special
- since the request cannot be rejected if the body is not understood.
- Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED,
- but if done, the body types are restricted to any that appeared in
- the INVITE, assuming that the response to the INVITE was not 415. If
- it was, the body in the ACK MAY be any type listed in the Accept
- header field in the 415.
-
- For example, consider the following request:
-
- INVITE sip:bob@biloxi.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
- To: Bob <sip:bob@biloxi.com>
- From: Alice <sip:alice@atlanta.com>;tag=88sja8x
- Max-Forwards: 70
- Call-ID: 987asjd97y7atg
- CSeq: 986759 INVITE
-
- The ACK request for a non-2xx final response to this request would
- look like this:
-
- ACK sip:bob@biloxi.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
- To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
- From: Alice <sip:alice@atlanta.com>;tag=88sja8x
- Max-Forwards: 70
- Call-ID: 987asjd97y7atg
- CSeq: 986759 ACK
-
-17.1.2 Non-INVITE Client Transaction
-
-17.1.2.1 Overview of the non-INVITE Transaction
-
- Non-INVITE transactions do not make use of ACK. They are simple
- request-response interactions. For unreliable transports, requests
- are retransmitted at an interval which starts at T1 and doubles until
- it hits T2. If a provisional response is received, retransmissions
- continue for unreliable transports, but at an interval of T2. The
- server transaction retransmits the last response it sent, which can
- be a provisional or final response, only when a retransmission of the
- request is received. This is why request retransmissions need to
- continue even after a provisional response; they are to ensure
- reliable delivery of the final response.
-
-
-
-Rosenberg, et. al. Standards Track [Page 130]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Unlike an INVITE transaction, a non-INVITE transaction has no special
- handling for the 2xx response. The result is that only a single 2xx
- response to a non-INVITE is ever delivered to a UAC.
-
-17.1.2.2 Formal Description
-
- The state machine for the non-INVITE client transaction is shown in
- Figure 6. It is very similar to the state machine for INVITE.
-
- The "Trying" state is entered when the TU initiates a new client
- transaction with a request. When entering this state, the client
- transaction SHOULD set timer F to fire in 64*T1 seconds. The request
- MUST be passed to the transport layer for transmission. If an
- unreliable transport is in use, the client transaction MUST set timer
- E to fire in T1 seconds. If timer E fires while still in this state,
- the timer is reset, but this time with a value of MIN(2*T1, T2).
- When the timer fires again, it is reset to a MIN(4*T1, T2). This
- process continues so that retransmissions occur with an exponentially
- increasing interval that caps at T2. The default value of T2 is 4s,
- and it represents the amount of time a non-INVITE server transaction
- will take to respond to a request, if it does not respond
- immediately. For the default values of T1 and T2, this results in
- intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.
-
- If Timer F fires while the client transaction is still in the
- "Trying" state, the client transaction SHOULD inform the TU about the
- timeout, and then it SHOULD enter the "Terminated" state. If a
- provisional response is received while in the "Trying" state, the
- response MUST be passed to the TU, and then the client transaction
- SHOULD move to the "Proceeding" state. If a final response (status
- codes 200-699) is received while in the "Trying" state, the response
- MUST be passed to the TU, and the client transaction MUST transition
- to the "Completed" state.
-
- If Timer E fires while in the "Proceeding" state, the request MUST be
- passed to the transport layer for retransmission, and Timer E MUST be
- reset with a value of T2 seconds. If timer F fires while in the
- "Proceeding" state, the TU MUST be informed of a timeout, and the
- client transaction MUST transition to the terminated state. If a
- final response (status codes 200-699) is received while in the
- "Proceeding" state, the response MUST be passed to the TU, and the
- client transaction MUST transition to the "Completed" state.
-
- Once the client transaction enters the "Completed" state, it MUST set
- Timer K to fire in T4 seconds for unreliable transports, and zero
- seconds for reliable transports. The "Completed" state exists to
- buffer any additional response retransmissions that may be received
- (which is why the client transaction remains there only for
-
-
-
-Rosenberg, et. al. Standards Track [Page 131]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- unreliable transports). T4 represents the amount of time the network
- will take to clear messages between client and server transactions.
- The default value of T4 is 5s. A response is a retransmission when
- it matches the same transaction, using the rules specified in Section
- 17.1.3. If Timer K fires while in this state, the client transaction
- MUST transition to the "Terminated" state.
-
- Once the transaction is in the terminated state, it MUST be destroyed
- immediately.
-
-17.1.3 Matching Responses to Client Transactions
-
- When the transport layer in the client receives a response, it has to
- determine which client transaction will handle the response, so that
- the processing of Sections 17.1.1 and 17.1.2 can take place. The
- branch parameter in the top Via header field is used for this
- purpose. A response matches a client transaction under two
- conditions:
-
- 1. If the response has the same value of the branch parameter in
- the top Via header field as the branch parameter in the top
- Via header field of the request that created the transaction.
-
- 2. If the method parameter in the CSeq header field matches the
- method of the request that created the transaction. The
- method is needed since a CANCEL request constitutes a
- different transaction, but shares the same value of the branch
- parameter.
-
- If a request is sent via multicast, it is possible that it will
- generate multiple responses from different servers. These responses
- will all have the same branch parameter in the topmost Via, but vary
- in the To tag. The first response received, based on the rules
- above, will be used, and others will be viewed as retransmissions.
- That is not an error; multicast SIP provides only a rudimentary
- "single-hop-discovery-like" service that is limited to processing a
- single response. See Section 18.1.1 for details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 132]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-17.1.4 Handling Transport Errors
-
- |Request from TU
- |send request
- Timer E V
- send request +-----------+
- +---------| |-------------------+
- | | Trying | Timer F |
- +-------->| | or Transport Err.|
- +-----------+ inform TU |
- 200-699 | | |
- resp. to TU | |1xx |
- +---------------+ |resp. to TU |
- | | |
- | Timer E V Timer F |
- | send req +-----------+ or Transport Err. |
- | +---------| | inform TU |
- | | |Proceeding |------------------>|
- | +-------->| |-----+ |
- | +-----------+ |1xx |
- | | ^ |resp to TU |
- | 200-699 | +--------+ |
- | resp. to TU | |
- | | |
- | V |
- | +-----------+ |
- | | | |
- | | Completed | |
- | | | |
- | +-----------+ |
- | ^ | |
- | | | Timer K |
- +--------------+ | - |
- | |
- V |
- NOTE: +-----------+ |
- | | |
- transitions | Terminated|<------------------+
- labeled with | |
- the event +-----------+
- over the action
- to take
-
- Figure 6: non-INVITE client transaction
-
- When the client transaction sends a request to the transport layer to
- be sent, the following procedures are followed if the transport layer
- indicates a failure.
-
-
-
-Rosenberg, et. al. Standards Track [Page 133]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The client transaction SHOULD inform the TU that a transport failure
- has occurred, and the client transaction SHOULD transition directly
- to the "Terminated" state. The TU will handle the failover
- mechanisms described in [4].
-
-17.2 Server Transaction
-
- The server transaction is responsible for the delivery of requests to
- the TU and the reliable transmission of responses. It accomplishes
- this through a state machine. Server transactions are created by the
- core when a request is received, and transaction handling is desired
- for that request (this is not always the case).
-
- As with the client transactions, the state machine depends on whether
- the received request is an INVITE request.
-
-17.2.1 INVITE Server Transaction
-
- The state diagram for the INVITE server transaction is shown in
- Figure 7.
-
- When a server transaction is constructed for a request, it enters the
- "Proceeding" state. The server transaction MUST generate a 100
- (Trying) response unless it knows that the TU will generate a
- provisional or final response within 200 ms, in which case it MAY
- generate a 100 (Trying) response. This provisional response is
- needed to quench request retransmissions rapidly in order to avoid
- network congestion. The 100 (Trying) response is constructed
- according to the procedures in Section 8.2.6, except that the
- insertion of tags in the To header field of the response (when none
- was present in the request) is downgraded from MAY to SHOULD NOT.
- The request MUST be passed to the TU.
-
- The TU passes any number of provisional responses to the server
- transaction. So long as the server transaction is in the
- "Proceeding" state, each of these MUST be passed to the transport
- layer for transmission. They are not sent reliably by the
- transaction layer (they are not retransmitted by it) and do not cause
- a change in the state of the server transaction. If a request
- retransmission is received while in the "Proceeding" state, the most
- recent provisional response that was received from the TU MUST be
- passed to the transport layer for retransmission. A request is a
- retransmission if it matches the same server transaction based on the
- rules of Section 17.2.3.
-
- If, while in the "Proceeding" state, the TU passes a 2xx response to
- the server transaction, the server transaction MUST pass this
- response to the transport layer for transmission. It is not
-
-
-
-Rosenberg, et. al. Standards Track [Page 134]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- retransmitted by the server transaction; retransmissions of 2xx
- responses are handled by the TU. The server transaction MUST then
- transition to the "Terminated" state.
-
- While in the "Proceeding" state, if the TU passes a response with
- status code from 300 to 699 to the server transaction, the response
- MUST be passed to the transport layer for transmission, and the state
- machine MUST enter the "Completed" state. For unreliable transports,
- timer G is set to fire in T1 seconds, and is not set to fire for
- reliable transports.
-
- This is a change from RFC 2543, where responses were always
- retransmitted, even over reliable transports.
-
- When the "Completed" state is entered, timer H MUST be set to fire in
- 64*T1 seconds for all transports. Timer H determines when the server
- transaction abandons retransmitting the response. Its value is
- chosen to equal Timer B, the amount of time a client transaction will
- continue to retry sending a request. If timer G fires, the response
- is passed to the transport layer once more for retransmission, and
- timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when
- timer G fires, the response is passed to the transport again for
- transmission, and timer G is reset with a value that doubles, unless
- that value exceeds T2, in which case it is reset with the value of
- T2. This is identical to the retransmit behavior for requests in the
- "Trying" state of the non-INVITE client transaction. Furthermore,
- while in the "Completed" state, if a request retransmission is
- received, the server SHOULD pass the response to the transport for
- retransmission.
-
- If an ACK is received while the server transaction is in the
- "Completed" state, the server transaction MUST transition to the
- "Confirmed" state. As Timer G is ignored in this state, any
- retransmissions of the response will cease.
-
- If timer H fires while in the "Completed" state, it implies that the
- ACK was never received. In this case, the server transaction MUST
- transition to the "Terminated" state, and MUST indicate to the TU
- that a transaction failure has occurred.
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 135]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- |INVITE
- |pass INV to TU
- INVITE V send 100 if TU won't in 200ms
- send response+-----------+
- +--------| |--------+101-199 from TU
- | | Proceeding| |send response
- +------->| |<-------+
- | | Transport Err.
- | | Inform TU
- | |--------------->+
- +-----------+ |
- 300-699 from TU | |2xx from TU |
- send response | |send response |
- | +------------------>+
- | |
- INVITE V Timer G fires |
- send response+-----------+ send response |
- +--------| |--------+ |
- | | Completed | | |
- +------->| |<-------+ |
- +-----------+ |
- | | |
- ACK | | |
- - | +------------------>+
- | Timer H fires |
- V or Transport Err.|
- +-----------+ Inform TU |
- | | |
- | Confirmed | |
- | | |
- +-----------+ |
- | |
- |Timer I fires |
- |- |
- | |
- V |
- +-----------+ |
- | | |
- | Terminated|<---------------+
- | |
- +-----------+
-
- Figure 7: INVITE server transaction
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 136]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The purpose of the "Confirmed" state is to absorb any additional ACK
- messages that arrive, triggered from retransmissions of the final
- response. When this state is entered, timer I is set to fire in T4
- seconds for unreliable transports, and zero seconds for reliable
- transports. Once timer I fires, the server MUST transition to the
- "Terminated" state.
-
- Once the transaction is in the "Terminated" state, it MUST be
- destroyed immediately. As with client transactions, this is needed
- to ensure reliability of the 2xx responses to INVITE.
-
-17.2.2 Non-INVITE Server Transaction
-
- The state machine for the non-INVITE server transaction is shown in
- Figure 8.
-
- The state machine is initialized in the "Trying" state and is passed
- a request other than INVITE or ACK when initialized. This request is
- passed up to the TU. Once in the "Trying" state, any further request
- retransmissions are discarded. A request is a retransmission if it
- matches the same server transaction, using the rules specified in
- Section 17.2.3.
-
- While in the "Trying" state, if the TU passes a provisional response
- to the server transaction, the server transaction MUST enter the
- "Proceeding" state. The response MUST be passed to the transport
- layer for transmission. Any further provisional responses that are
- received from the TU while in the "Proceeding" state MUST be passed
- to the transport layer for transmission. If a retransmission of the
- request is received while in the "Proceeding" state, the most
- recently sent provisional response MUST be passed to the transport
- layer for retransmission. If the TU passes a final response (status
- codes 200-699) to the server while in the "Proceeding" state, the
- transaction MUST enter the "Completed" state, and the response MUST
- be passed to the transport layer for transmission.
-
- When the server transaction enters the "Completed" state, it MUST set
- Timer J to fire in 64*T1 seconds for unreliable transports, and zero
- seconds for reliable transports. While in the "Completed" state, the
- server transaction MUST pass the final response to the transport
- layer for retransmission whenever a retransmission of the request is
- received. Any other final responses passed by the TU to the server
- transaction MUST be discarded while in the "Completed" state. The
- server transaction remains in this state until Timer J fires, at
- which point it MUST transition to the "Terminated" state.
-
- The server transaction MUST be destroyed the instant it enters the
- "Terminated" state.
-
-
-
-Rosenberg, et. al. Standards Track [Page 137]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-17.2.3 Matching Requests to Server Transactions
-
- When a request is received from the network by the server, it has to
- be matched to an existing transaction. This is accomplished in the
- following manner.
-
- The branch parameter in the topmost Via header field of the request
- is examined. If it is present and begins with the magic cookie
- "z9hG4bK", the request was generated by a client transaction
- compliant to this specification. Therefore, the branch parameter
- will be unique across all transactions sent by that client. The
- request matches a transaction if:
-
- 1. the branch parameter in the request is equal to the one in the
- top Via header field of the request that created the
- transaction, and
-
- 2. the sent-by value in the top Via of the request is equal to the
- one in the request that created the transaction, and
-
- 3. the method of the request matches the one that created the
- transaction, except for ACK, where the method of the request
- that created the transaction is INVITE.
-
- This matching rule applies to both INVITE and non-INVITE transactions
- alike.
-
- The sent-by value is used as part of the matching process because
- there could be accidental or malicious duplication of branch
- parameters from different clients.
-
- If the branch parameter in the top Via header field is not present,
- or does not contain the magic cookie, the following procedures are
- used. These exist to handle backwards compatibility with RFC 2543
- compliant implementations.
-
- The INVITE request matches a transaction if the Request-URI, To tag,
- From tag, Call-ID, CSeq, and top Via header field match those of the
- INVITE request which created the transaction. In this case, the
- INVITE is a retransmission of the original one that created the
- transaction. The ACK request matches a transaction if the Request-
- URI, From tag, Call-ID, CSeq number (not the method), and top Via
- header field match those of the INVITE request which created the
- transaction, and the To tag of the ACK matches the To tag of the
- response sent by the server transaction. Matching is done based on
- the matching rules defined for each of those header fields.
- Inclusion of the tag in the To header field in the ACK matching
- process helps disambiguate ACK for 2xx from ACK for other responses
-
-
-
-Rosenberg, et. al. Standards Track [Page 138]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- at a proxy, which may have forwarded both responses (This can occur
- in unusual conditions. Specifically, when a proxy forked a request,
- and then crashes, the responses may be delivered to another proxy,
- which might end up forwarding multiple responses upstream). An ACK
- request that matches an INVITE transaction matched by a previous ACK
- is considered a retransmission of that previous ACK.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 139]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- |Request received
- |pass to TU
- V
- +-----------+
- | |
- | Trying |-------------+
- | | |
- +-----------+ |200-699 from TU
- | |send response
- |1xx from TU |
- |send response |
- | |
- Request V 1xx from TU |
- send response+-----------+send response|
- +--------| |--------+ |
- | | Proceeding| | |
- +------->| |<-------+ |
- +<--------------| | |
- |Trnsprt Err +-----------+ |
- |Inform TU | |
- | | |
- | |200-699 from TU |
- | |send response |
- | Request V |
- | send response+-----------+ |
- | +--------| | |
- | | | Completed |<------------+
- | +------->| |
- +<--------------| |
- |Trnsprt Err +-----------+
- |Inform TU |
- | |Timer J fires
- | |-
- | |
- | V
- | +-----------+
- | | |
- +-------------->| Terminated|
- | |
- +-----------+
-
- Figure 8: non-INVITE server transaction
-
- For all other request methods, a request is matched to a transaction
- if the Request-URI, To tag, From tag, Call-ID, CSeq (including the
- method), and top Via header field match those of the request that
- created the transaction. Matching is done based on the matching
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 140]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- rules defined for each of those header fields. When a non-INVITE
- request matches an existing transaction, it is a retransmission of
- the request that created that transaction.
-
- Because the matching rules include the Request-URI, the server cannot
- match a response to a transaction. When the TU passes a response to
- the server transaction, it must pass it to the specific server
- transaction for which the response is targeted.
-
-17.2.4 Handling Transport Errors
-
- When the server transaction sends a response to the transport layer
- to be sent, the following procedures are followed if the transport
- layer indicates a failure.
-
- First, the procedures in [4] are followed, which attempt to deliver
- the response to a backup. If those should all fail, based on the
- definition of failure in [4], the server transaction SHOULD inform
- the TU that a failure has occurred, and SHOULD transition to the
- terminated state.
-
-18 Transport
-
- The transport layer is responsible for the actual transmission of
- requests and responses over network transports. This includes
- determination of the connection to use for a request or response in
- the case of connection-oriented transports.
-
- The transport layer is responsible for managing persistent
- connections for transport protocols like TCP and SCTP, or TLS over
- those, including ones opened to the transport layer. This includes
- connections opened by the client or server transports, so that
- connections are shared between client and server transport functions.
- These connections are indexed by the tuple formed from the address,
- port, and transport protocol at the far end of the connection. When
- a connection is opened by the transport layer, this index is set to
- the destination IP, port and transport. When the connection is
- accepted by the transport layer, this index is set to the source IP
- address, port number, and transport. Note that, because the source
- port is often ephemeral, but it cannot be known whether it is
- ephemeral or selected through procedures in [4], connections accepted
- by the transport layer will frequently not be reused. The result is
- that two proxies in a "peering" relationship using a connection-
- oriented transport frequently will have two connections in use, one
- for transactions initiated in each direction.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 141]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- It is RECOMMENDED that connections be kept open for some
- implementation-defined duration after the last message was sent or
- received over that connection. This duration SHOULD at least equal
- the longest amount of time the element would need in order to bring a
- transaction from instantiation to the terminated state. This is to
- make it likely that transactions are completed over the same
- connection on which they are initiated (for example, request,
- response, and in the case of INVITE, ACK for non-2xx responses).
- This usually means at least 64*T1 (see Section 17.1.1.1 for a
- definition of T1). However, it could be larger in an element that
- has a TU using a large value for timer C (bullet 11 of Section 16.6),
- for example.
-
- All SIP elements MUST implement UDP and TCP. SIP elements MAY
- implement other protocols.
-
- Making TCP mandatory for the UA is a substantial change from RFC
- 2543. It has arisen out of the need to handle larger messages,
- which MUST use TCP, as discussed below. Thus, even if an element
- never sends large messages, it may receive one and needs to be
- able to handle them.
-
-18.1 Clients
-
-18.1.1 Sending Requests
-
- The client side of the transport layer is responsible for sending the
- request and receiving responses. The user of the transport layer
- passes the client transport the request, an IP address, port,
- transport, and possibly TTL for multicast destinations.
-
- If a request is within 200 bytes of the path MTU, or if it is larger
- than 1300 bytes and the path MTU is unknown, the request MUST be sent
- using an RFC 2914 [43] congestion controlled transport protocol, such
- as TCP. If this causes a change in the transport protocol from the
- one indicated in the top Via, the value in the top Via MUST be
- changed. This prevents fragmentation of messages over UDP and
- provides congestion control for larger messages. However,
- implementations MUST be able to handle messages up to the maximum
- datagram packet size. For UDP, this size is 65,535 bytes, including
- IP and UDP headers.
-
- The 200 byte "buffer" between the message size and the MTU
- accommodates the fact that the response in SIP can be larger than
- the request. This happens due to the addition of Record-Route
- header field values to the responses to INVITE, for example. With
- the extra buffer, the response can be about 170 bytes larger than
- the request, and still not be fragmented on IPv4 (about 30 bytes
-
-
-
-Rosenberg, et. al. Standards Track [Page 142]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when
- path MTU is not known, based on the assumption of a 1500 byte
- Ethernet MTU.
-
- If an element sends a request over TCP because of these message size
- constraints, and that request would have otherwise been sent over
- UDP, if the attempt to establish the connection generates either an
- ICMP Protocol Not Supported, or results in a TCP reset, the element
- SHOULD retry the request, using UDP. This is only to provide
- backwards compatibility with RFC 2543 compliant implementations that
- do not support TCP. It is anticipated that this behavior will be
- deprecated in a future revision of this specification.
-
- A client that sends a request to a multicast address MUST add the
- "maddr" parameter to its Via header field value containing the
- destination multicast address, and for IPv4, SHOULD add the "ttl"
- parameter with a value of 1. Usage of IPv6 multicast is not defined
- in this specification, and will be a subject of future
- standardization when the need arises.
-
- These rules result in a purposeful limitation of multicast in SIP.
- Its primary function is to provide a "single-hop-discovery-like"
- service, delivering a request to a group of homogeneous servers,
- where it is only required to process the response from any one of
- them. This functionality is most useful for registrations. In fact,
- based on the transaction processing rules in Section 17.1.3, the
- client transaction will accept the first response, and view any
- others as retransmissions because they all contain the same Via
- branch identifier.
-
- Before a request is sent, the client transport MUST insert a value of
- the "sent-by" field into the Via header field. This field contains
- an IP address or host name, and port. The usage of an FQDN is
- RECOMMENDED. This field is used for sending responses under certain
- conditions, described below. If the port is absent, the default
- value depends on the transport. It is 5060 for UDP, TCP and SCTP,
- 5061 for TLS.
-
- For reliable transports, the response is normally sent on the
- connection on which the request was received. Therefore, the client
- transport MUST be prepared to receive the response on the same
- connection used to send the request. Under error conditions, the
- server may attempt to open a new connection to send the response. To
- handle this case, the transport layer MUST also be prepared to
- receive an incoming connection on the source IP address from which
- the request was sent and port number in the "sent-by" field. It also
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 143]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- MUST be prepared to receive incoming connections on any address and
- port that would be selected by a server based on the procedures
- described in Section 5 of [4].
-
- For unreliable unicast transports, the client transport MUST be
- prepared to receive responses on the source IP address from which the
- request is sent (as responses are sent back to the source address)
- and the port number in the "sent-by" field. Furthermore, as with
- reliable transports, in certain cases the response will be sent
- elsewhere. The client MUST be prepared to receive responses on any
- address and port that would be selected by a server based on the
- procedures described in Section 5 of [4].
-
- For multicast, the client transport MUST be prepared to receive
- responses on the same multicast group and port to which the request
- is sent (that is, it needs to be a member of the multicast group it
- sent the request to.)
-
- If a request is destined to an IP address, port, and transport to
- which an existing connection is open, it is RECOMMENDED that this
- connection be used to send the request, but another connection MAY be
- opened and used.
-
- If a request is sent using multicast, it is sent to the group
- address, port, and TTL provided by the transport user. If a request
- is sent using unicast unreliable transports, it is sent to the IP
- address and port provided by the transport user.
-
-18.1.2 Receiving Responses
-
- When a response is received, the client transport examines the top
- Via header field value. If the value of the "sent-by" parameter in
- that header field value does not correspond to a value that the
- client transport is configured to insert into requests, the response
- MUST be silently discarded.
-
- If there are any client transactions in existence, the client
- transport uses the matching procedures of Section 17.1.3 to attempt
- to match the response to an existing transaction. If there is a
- match, the response MUST be passed to that transaction. Otherwise,
- the response MUST be passed to the core (whether it be stateless
- proxy, stateful proxy, or UA) for further processing. Handling of
- these "stray" responses is dependent on the core (a proxy will
- forward them, while a UA will discard, for example).
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 144]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-18.2 Servers
-
-18.2.1 Receiving Requests
-
- A server SHOULD be prepared to receive requests on any IP address,
- port and transport combination that can be the result of a DNS lookup
- on a SIP or SIPS URI [4] that is handed out for the purposes of
- communicating with that server. In this context, "handing out"
- includes placing a URI in a Contact header field in a REGISTER
- request or a redirect response, or in a Record-Route header field in
- a request or response. A URI can also be "handed out" by placing it
- on a web page or business card. It is also RECOMMENDED that a server
- listen for requests on the default SIP ports (5060 for TCP and UDP,
- 5061 for TLS over TCP) on all public interfaces. The typical
- exception would be private networks, or when multiple server
- instances are running on the same host. For any port and interface
- that a server listens on for UDP, it MUST listen on that same port
- and interface for TCP. This is because a message may need to be sent
- using TCP, rather than UDP, if it is too large. As a result, the
- converse is not true. A server need not listen for UDP on a
- particular address and port just because it is listening on that same
- address and port for TCP. There may, of course, be other reasons why
- a server needs to listen for UDP on a particular address and port.
-
- When the server transport receives a request over any transport, it
- MUST examine the value of the "sent-by" parameter in the top Via
- header field value. If the host portion of the "sent-by" parameter
- contains a domain name, or if it contains an IP address that differs
- from the packet source address, the server MUST add a "received"
- parameter to that Via header field value. This parameter MUST
- contain the source address from which the packet was received. This
- is to assist the server transport layer in sending the response,
- since it must be sent to the source IP address from which the request
- came.
-
- Consider a request received by the server transport which looks like,
- in part:
-
- INVITE sip:bob@Biloxi.com SIP/2.0
- Via: SIP/2.0/UDP bobspc.biloxi.com:5060
-
- The request is received with a source IP address of 192.0.2.4.
- Before passing the request up, the transport adds a "received"
- parameter, so that the request would look like, in part:
-
- INVITE sip:bob@Biloxi.com SIP/2.0
- Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 145]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Next, the server transport attempts to match the request to a server
- transaction. It does so using the matching rules described in
- Section 17.2.3. If a matching server transaction is found, the
- request is passed to that transaction for processing. If no match is
- found, the request is passed to the core, which may decide to
- construct a new server transaction for that request. Note that when
- a UAS core sends a 2xx response to INVITE, the server transaction is
- destroyed. This means that when the ACK arrives, there will be no
- matching server transaction, and based on this rule, the ACK is
- passed to the UAS core, where it is processed.
-
-18.2.2 Sending Responses
-
- The server transport uses the value of the top Via header field in
- order to determine where to send a response. It MUST follow the
- following process:
-
- o If the "sent-protocol" is a reliable transport protocol such as
- TCP or SCTP, or TLS over those, the response MUST be sent using
- the existing connection to the source of the original request
- that created the transaction, if that connection is still open.
- This requires the server transport to maintain an association
- between server transactions and transport connections. If that
- connection is no longer open, the server SHOULD open a
- connection to the IP address in the "received" parameter, if
- present, using the port in the "sent-by" value, or the default
- port for that transport, if no port is specified. If that
- connection attempt fails, the server SHOULD use the procedures
- in [4] for servers in order to determine the IP address and
- port to open the connection and send the response to.
-
- o Otherwise, if the Via header field value contains a "maddr"
- parameter, the response MUST be forwarded to the address listed
- there, using the port indicated in "sent-by", or port 5060 if
- none is present. If the address is a multicast address, the
- response SHOULD be sent using the TTL indicated in the "ttl"
- parameter, or with a TTL of 1 if that parameter is not present.
-
- o Otherwise (for unreliable unicast transports), if the top Via
- has a "received" parameter, the response MUST be sent to the
- address in the "received" parameter, using the port indicated
- in the "sent-by" value, or using port 5060 if none is specified
- explicitly. If this fails, for example, elicits an ICMP "port
- unreachable" response, the procedures of Section 5 of [4]
- SHOULD be used to determine where to send the response.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 146]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o Otherwise, if it is not receiver-tagged, the response MUST be
- sent to the address indicated by the "sent-by" value, using the
- procedures in Section 5 of [4].
-
-18.3 Framing
-
- In the case of message-oriented transports (such as UDP), if the
- message has a Content-Length header field, the message body is
- assumed to contain that many bytes. If there are additional bytes in
- the transport packet beyond the end of the body, they MUST be
- discarded. If the transport packet ends before the end of the
- message body, this is considered an error. If the message is a
- response, it MUST be discarded. If the message is a request, the
- element SHOULD generate a 400 (Bad Request) response. If the message
- has no Content-Length header field, the message body is assumed to
- end at the end of the transport packet.
-
- In the case of stream-oriented transports such as TCP, the Content-
- Length header field indicates the size of the body. The Content-
- Length header field MUST be used with stream oriented transports.
-
-18.4 Error Handling
-
- Error handling is independent of whether the message was a request or
- response.
-
- If the transport user asks for a message to be sent over an
- unreliable transport, and the result is an ICMP error, the behavior
- depends on the type of ICMP error. Host, network, port or protocol
- unreachable errors, or parameter problem errors SHOULD cause the
- transport layer to inform the transport user of a failure in sending.
- Source quench and TTL exceeded ICMP errors SHOULD be ignored.
-
- If the transport user asks for a request to be sent over a reliable
- transport, and the result is a connection failure, the transport
- layer SHOULD inform the transport user of a failure in sending.
-
-19 Common Message Components
-
- There are certain components of SIP messages that appear in various
- places within SIP messages (and sometimes, outside of them) that
- merit separate discussion.
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 147]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-19.1 SIP and SIPS Uniform Resource Indicators
-
- A SIP or SIPS URI identifies a communications resource. Like all
- URIs, SIP and SIPS URIs may be placed in web pages, email messages,
- or printed literature. They contain sufficient information to
- initiate and maintain a communication session with the resource.
-
- Examples of communications resources include the following:
-
- o a user of an online service
-
- o an appearance on a multi-line phone
-
- o a mailbox on a messaging system
-
- o a PSTN number at a gateway service
-
- o a group (such as "sales" or "helpdesk") in an organization
-
- A SIPS URI specifies that the resource be contacted securely. This
- means, in particular, that TLS is to be used between the UAC and the
- domain that owns the URI. From there, secure communications are used
- to reach the user, where the specific security mechanism depends on
- the policy of the domain. Any resource described by a SIP URI can be
- "upgraded" to a SIPS URI by just changing the scheme, if it is
- desired to communicate with that resource securely.
-
-19.1.1 SIP and SIPS URI Components
-
- The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5].
- They use a form similar to the mailto URL, allowing the specification
- of SIP request-header fields and the SIP message-body. This makes it
- possible to specify the subject, media type, or urgency of sessions
- initiated by using a URI on a web page or in an email message. The
- formal syntax for a SIP or SIPS URI is presented in Section 25. Its
- general form, in the case of a SIP URI, is:
-
- sip:user:password@host:port;uri-parameters?headers
-
- The format for a SIPS URI is the same, except that the scheme is
- "sips" instead of sip. These tokens, and some of the tokens in their
- expansions, have the following meanings:
-
- user: The identifier of a particular resource at the host being
- addressed. The term "host" in this context frequently refers
- to a domain. The "userinfo" of a URI consists of this user
- field, the password field, and the @ sign following them. The
- userinfo part of a URI is optional and MAY be absent when the
-
-
-
-Rosenberg, et. al. Standards Track [Page 148]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- destination host does not have a notion of users or when the
- host itself is the resource being identified. If the @ sign is
- present in a SIP or SIPS URI, the user field MUST NOT be empty.
-
- If the host being addressed can process telephone numbers, for
- instance, an Internet telephony gateway, a telephone-
- subscriber field defined in RFC 2806 [9] MAY be used to
- populate the user field. There are special escaping rules for
- encoding telephone-subscriber fields in SIP and SIPS URIs
- described in Section 19.1.2.
-
- password: A password associated with the user. While the SIP and
- SIPS URI syntax allows this field to be present, its use is NOT
- RECOMMENDED, because the passing of authentication information
- in clear text (such as URIs) has proven to be a security risk
- in almost every case where it has been used. For instance,
- transporting a PIN number in this field exposes the PIN.
-
- Note that the password field is just an extension of the user
- portion. Implementations not wishing to give special
- significance to the password portion of the field MAY simply
- treat "user:password" as a single string.
-
- host: The host providing the SIP resource. The host part contains
- either a fully-qualified domain name or numeric IPv4 or IPv6
- address. Using the fully-qualified domain name form is
- RECOMMENDED whenever possible.
-
- port: The port number where the request is to be sent.
-
- URI parameters: Parameters affecting a request constructed from
- the URI.
-
- URI parameters are added after the hostport component and are
- separated by semi-colons.
-
- URI parameters take the form:
-
- parameter-name "=" parameter-value
-
- Even though an arbitrary number of URI parameters may be
- included in a URI, any given parameter-name MUST NOT appear
- more than once.
-
- This extensible mechanism includes the transport, maddr, ttl,
- user, method and lr parameters.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 149]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The transport parameter determines the transport mechanism to
- be used for sending SIP messages, as specified in [4]. SIP can
- use any network transport protocol. Parameter names are
- defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP
- (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST
- indicate a reliable transport.
-
- The maddr parameter indicates the server address to be
- contacted for this user, overriding any address derived from
- the host field. When an maddr parameter is present, the port
- and transport components of the URI apply to the address
- indicated in the maddr parameter value. [4] describes the
- proper interpretation of the transport, maddr, and hostport in
- order to obtain the destination address, port, and transport
- for sending a request.
-
- The maddr field has been used as a simple form of loose source
- routing. It allows a URI to specify a proxy that must be
- traversed en-route to the destination. Continuing to use the
- maddr parameter this way is strongly discouraged (the
- mechanisms that enable it are deprecated). Implementations
- should instead use the Route mechanism described in this
- document, establishing a pre-existing route set if necessary
- (see Section 8.1.1.1). This provides a full URI to describe
- the node to be traversed.
-
- The ttl parameter determines the time-to-live value of the UDP
- multicast packet and MUST only be used if maddr is a multicast
- address and the transport protocol is UDP. For example, to
- specify a call to alice@atlanta.com using multicast to
- 239.255.255.1 with a ttl of 15, the following URI would be
- used:
-
- sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
-
- The set of valid telephone-subscriber strings is a subset of
- valid user strings. The user URI parameter exists to
- distinguish telephone numbers from user names that happen to
- look like telephone numbers. If the user string contains a
- telephone number formatted as a telephone-subscriber, the user
- parameter value "phone" SHOULD be present. Even without this
- parameter, recipients of SIP and SIPS URIs MAY interpret the
- pre-@ part as a telephone number if local restrictions on the
- name space for user name allow it.
-
- The method of the SIP request constructed from the URI can be
- specified with the method parameter.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 150]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The lr parameter, when present, indicates that the element
- responsible for this resource implements the routing mechanisms
- specified in this document. This parameter will be used in the
- URIs proxies place into Record-Route header field values, and
- may appear in the URIs in a pre-existing route set.
-
- This parameter is used to achieve backwards compatibility with
- systems implementing the strict-routing mechanisms of RFC 2543
- and the rfc2543bis drafts up to bis-05. An element preparing
- to send a request based on a URI not containing this parameter
- can assume the receiving element implements strict-routing and
- reformat the message to preserve the information in the
- Request-URI.
-
- Since the uri-parameter mechanism is extensible, SIP elements
- MUST silently ignore any uri-parameters that they do not
- understand.
-
- Headers: Header fields to be included in a request constructed
- from the URI.
-
- Headers fields in the SIP request can be specified with the "?"
- mechanism within a URI. The header names and values are
- encoded in ampersand separated hname = hvalue pairs. The
- special hname "body" indicates that the associated hvalue is
- the message-body of the SIP request.
-
- Table 1 summarizes the use of SIP and SIPS URI components based on
- the context in which the URI appears. The external column describes
- URIs appearing anywhere outside of a SIP message, for instance on a
- web page or business card. Entries marked "m" are mandatory, those
- marked "o" are optional, and those marked "-" are not allowed.
- Elements processing URIs SHOULD ignore any disallowed components if
- they are present. The second column indicates the default value of
- an optional element if it is not present. "--" indicates that the
- element is either not optional, or has no default value.
-
- URIs in Contact header fields have different restrictions depending
- on the context in which the header field appears. One set applies to
- messages that establish and maintain dialogs (INVITE and its 200 (OK)
- response). The other applies to registration and redirection
- messages (REGISTER, its 200 (OK) response, and 3xx class responses to
- any method).
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 151]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-19.1.2 Character Escaping Requirements
-
- dialog
- reg./redir. Contact/
- default Req.-URI To From Contact R-R/Route external
-user -- o o o o o o
-password -- o o o o o o
-host -- m m m m m m
-port (1) o - - o o o
-user-param ip o o o o o o
-method INVITE - - - - - o
-maddr-param -- o - - o o o
-ttl-param 1 o - - o - o
-transp.-param (2) o - - o o o
-lr-param -- o - - - o o
-other-param -- o o o o o o
-headers -- - - - o - o
-
- (1): The default port value is transport and scheme dependent. The
- default is 5060 for sip: using UDP, TCP, or SCTP. The default is
- 5061 for sip: using TLS over TCP and sips: over TCP.
-
- (2): The default transport is scheme dependent. For sip:, it is UDP.
- For sips:, it is TCP.
-
- Table 1: Use and default values of URI components for SIP header
- field values, Request-URI and references
-
- SIP follows the requirements and guidelines of RFC 2396 [5] when
- defining the set of characters that must be escaped in a SIP URI, and
- uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]:
-
- The set of characters actually reserved within any given URI
- component is defined by that component. In general, a character
- is reserved if the semantics of the URI changes if the character
- is replaced with its escaped US-ASCII encoding [5]. Excluded US-
- ASCII characters (RFC 2396 [5]), such as space and control
- characters and characters used as URI delimiters, also MUST be
- escaped. URIs MUST NOT contain unescaped space and control
- characters.
-
- For each component, the set of valid BNF expansions defines exactly
- which characters may appear unescaped. All other characters MUST be
- escaped.
-
- For example, "@" is not in the set of characters in the user
- component, so the user "j@s0n" must have at least the @ sign encoded,
- as in "j%40s0n".
-
-
-
-Rosenberg, et. al. Standards Track [Page 152]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Expanding the hname and hvalue tokens in Section 25 show that all URI
- reserved characters in header field names and values MUST be escaped.
-
- The telephone-subscriber subset of the user component has special
- escaping considerations. The set of characters not reserved in the
- RFC 2806 [9] description of telephone-subscriber contains a number of
- characters in various syntax elements that need to be escaped when
- used in SIP URIs. Any characters occurring in a telephone-subscriber
- that do not appear in an expansion of the BNF for the user rule MUST
- be escaped.
-
- Note that character escaping is not allowed in the host component of
- a SIP or SIPS URI (the % character is not valid in its expansion).
- This is likely to change in the future as requirements for
- Internationalized Domain Names are finalized. Current
- implementations MUST NOT attempt to improve robustness by treating
- received escaped characters in the host component as literally
- equivalent to their unescaped counterpart. The behavior required to
- meet the requirements of IDN may be significantly different.
-
-19.1.3 Example SIP and SIPS URIs
-
- sip:alice@atlanta.com
- sip:alice:secretword@atlanta.com;transport=tcp
- sips:alice@atlanta.com?subject=project%20x&priority=urgent
- sip:+1-212-555-1212:1234@gateway.com;user=phone
- sips:1212@gateway.com
- sip:alice@192.0.2.4
- sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
- sip:alice;day=tuesday@atlanta.com
-
- The last sample URI above has a user field value of
- "alice;day=tuesday". The escaping rules defined above allow a
- semicolon to appear unescaped in this field. For the purposes of
- this protocol, the field is opaque. The structure of that value is
- only useful to the SIP element responsible for the resource.
-
-19.1.4 URI Comparison
-
- Some operations in this specification require determining whether two
- SIP or SIPS URIs are equivalent. In this specification, registrars
- need to compare bindings in Contact URIs in REGISTER requests (see
- Section 10.3.). SIP and SIPS URIs are compared for equality
- according to the following rules:
-
- o A SIP and SIPS URI are never equivalent.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 153]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o Comparison of the userinfo of SIP and SIPS URIs is case-
- sensitive. This includes userinfo containing passwords or
- formatted as telephone-subscribers. Comparison of all other
- components of the URI is case-insensitive unless explicitly
- defined otherwise.
-
- o The ordering of parameters and header fields is not significant
- in comparing SIP and SIPS URIs.
-
- o Characters other than those in the "reserved" set (see RFC 2396
- [5]) are equivalent to their ""%" HEX HEX" encoding.
-
- o An IP address that is the result of a DNS lookup of a host name
- does not match that host name.
-
- o For two URIs to be equal, the user, password, host, and port
- components must match.
-
- A URI omitting the user component will not match a URI that
- includes one. A URI omitting the password component will not
- match a URI that includes one.
-
- A URI omitting any component with a default value will not
- match a URI explicitly containing that component with its
- default value. For instance, a URI omitting the optional port
- component will not match a URI explicitly declaring port 5060.
- The same is true for the transport-parameter, ttl-parameter,
- user-parameter, and method components.
-
- Defining sip:user@host to not be equivalent to
- sip:user@host:5060 is a change from RFC 2543. When deriving
- addresses from URIs, equivalent addresses are expected from
- equivalent URIs. The URI sip:user@host:5060 will always
- resolve to port 5060. The URI sip:user@host may resolve to
- other ports through the DNS SRV mechanisms detailed in [4].
-
- o URI uri-parameter components are compared as follows:
-
- - Any uri-parameter appearing in both URIs must match.
-
- - A user, ttl, or method uri-parameter appearing in only one
- URI never matches, even if it contains the default value.
-
- - A URI that includes an maddr parameter will not match a URI
- that contains no maddr parameter.
-
- - All other uri-parameters appearing in only one URI are
- ignored when comparing the URIs.
-
-
-
-Rosenberg, et. al. Standards Track [Page 154]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o URI header components are never ignored. Any present header
- component MUST be present in both URIs and match for the URIs
- to match. The matching rules are defined for each header field
- in Section 20.
-
- The URIs within each of the following sets are equivalent:
-
- sip:%61lice@atlanta.com;transport=TCP
- sip:alice@AtLanTa.CoM;Transport=tcp
-
- sip:carol@chicago.com
- sip:carol@chicago.com;newparam=5
- sip:carol@chicago.com;security=on
-
- sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
- sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
-
- sip:alice@atlanta.com?subject=project%20x&priority=urgent
- sip:alice@atlanta.com?priority=urgent&subject=project%20x
-
- The URIs within each of the following sets are not equivalent:
-
- SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames)
- sip:alice@AtLanTa.CoM;Transport=UDP
-
- sip:bob@biloxi.com (can resolve to different ports)
- sip:bob@biloxi.com:5060
-
- sip:bob@biloxi.com (can resolve to different transports)
- sip:bob@biloxi.com;transport=udp
-
- sip:bob@biloxi.com (can resolve to different port and transports)
- sip:bob@biloxi.com:6000;transport=tcp
-
- sip:carol@chicago.com (different header component)
- sip:carol@chicago.com?Subject=next%20meeting
-
- sip:bob@phone21.boxesbybob.com (even though that's what
- sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to)
-
- Note that equality is not transitive:
-
- o sip:carol@chicago.com and sip:carol@chicago.com;security=on are
- equivalent
-
- o sip:carol@chicago.com and sip:carol@chicago.com;security=off
- are equivalent
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 155]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o sip:carol@chicago.com;security=on and
- sip:carol@chicago.com;security=off are not equivalent
-
-19.1.5 Forming Requests from a URI
-
- An implementation needs to take care when forming requests directly
- from a URI. URIs from business cards, web pages, and even from
- sources inside the protocol such as registered contacts may contain
- inappropriate header fields or body parts.
-
- An implementation MUST include any provided transport, maddr, ttl, or
- user parameter in the Request-URI of the formed request. If the URI
- contains a method parameter, its value MUST be used as the method of
- the request. The method parameter MUST NOT be placed in the
- Request-URI. Unknown URI parameters MUST be placed in the message's
- Request-URI.
-
- An implementation SHOULD treat the presence of any headers or body
- parts in the URI as a desire to include them in the message, and
- choose to honor the request on a per-component basis.
-
- An implementation SHOULD NOT honor these obviously dangerous header
- fields: From, Call-ID, CSeq, Via, and Record-Route.
-
- An implementation SHOULD NOT honor any requested Route header field
- values in order to not be used as an unwitting agent in malicious
- attacks.
-
- An implementation SHOULD NOT honor requests to include header fields
- that may cause it to falsely advertise its location or capabilities.
- These include: Accept, Accept-Encoding, Accept-Language, Allow,
- Contact (in its dialog usage), Organization, Supported, and User-
- Agent.
-
- An implementation SHOULD verify the accuracy of any requested
- descriptive header fields, including: Content-Disposition, Content-
- Encoding, Content-Language, Content-Length, Content-Type, Date,
- Mime-Version, and Timestamp.
-
- If the request formed from constructing a message from a given URI is
- not a valid SIP request, the URI is invalid. An implementation MUST
- NOT proceed with transmitting the request. It should instead pursue
- the course of action due an invalid URI in the context it occurs.
-
- The constructed request can be invalid in many ways. These
- include, but are not limited to, syntax error in header fields,
- invalid combinations of URI parameters, or an incorrect
- description of the message body.
-
-
-
-Rosenberg, et. al. Standards Track [Page 156]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Sending a request formed from a given URI may require capabilities
- unavailable to the implementation. The URI might indicate use of an
- unimplemented transport or extension, for example. An implementation
- SHOULD refuse to send these requests rather than modifying them to
- match their capabilities. An implementation MUST NOT send a request
- requiring an extension that it does not support.
-
- For example, such a request can be formed through the presence of
- a Require header parameter or a method URI parameter with an
- unknown or explicitly unsupported value.
-
-19.1.6 Relating SIP URIs and tel URLs
-
- When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the
- entire telephone-subscriber portion of the tel URL, including any
- parameters, is placed into the userinfo part of the SIP or SIPS URI.
-
- Thus, tel:+358-555-1234567;postd=pp22 becomes
-
- sip:+358-555-1234567;postd=pp22@foo.com;user=phone
-
- or
- sips:+358-555-1234567;postd=pp22@foo.com;user=phone
-
- not
- sip:+358-555-1234567@foo.com;postd=pp22;user=phone
-
- or
-
- sips:+358-555-1234567@foo.com;postd=pp22;user=phone
-
- In general, equivalent "tel" URLs converted to SIP or SIPS URIs in
- this fashion may not produce equivalent SIP or SIPS URIs. The
- userinfo of SIP and SIPS URIs are compared as a case-sensitive
- string. Variance in case-insensitive portions of tel URLs and
- reordering of tel URL parameters does not affect tel URL equivalence,
- but does affect the equivalence of SIP URIs formed from them.
-
- For example,
-
- tel:+358-555-1234567;postd=pp22
- tel:+358-555-1234567;POSTD=PP22
-
- are equivalent, while
-
- sip:+358-555-1234567;postd=pp22@foo.com;user=phone
- sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 157]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- are not.
-
- Likewise,
-
- tel:+358-555-1234567;postd=pp22;isub=1411
- tel:+358-555-1234567;isub=1411;postd=pp22
-
- are equivalent, while
-
- sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
- sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone
-
- are not.
-
- To mitigate this problem, elements constructing telephone-subscriber
- fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold
- any case-insensitive portion of telephone-subscriber to lower case,
- and order the telephone-subscriber parameters lexically by parameter
- name, excepting isdn-subaddress and post-dial, which occur first and
- in that order. (All components of a tel URL except for future-
- extension parameters are defined to be compared case-insensitive.)
-
- Following this suggestion, both
-
- tel:+358-555-1234567;postd=pp22
- tel:+358-555-1234567;POSTD=PP22
-
- become
-
- sip:+358-555-1234567;postd=pp22@foo.com;user=phone
-
- and both
-
- tel:+358-555-1234567;tsp=a.b;phone-context=5
- tel:+358-555-1234567;phone-context=5;tsp=a.b
-
- become
-
- sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone
-
-19.2 Option Tags
-
- Option tags are unique identifiers used to designate new options
- (extensions) in SIP. These tags are used in Require (Section 20.32),
- Proxy-Require (Section 20.29), Supported (Section 20.37) and
- Unsupported (Section 20.40) header fields. Note that these options
- appear as parameters in those header fields in an option-tag = token
- form (see Section 25 for the definition of token).
-
-
-
-Rosenberg, et. al. Standards Track [Page 158]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Option tags are defined in standards track RFCs. This is a change
- from past practice, and is instituted to ensure continuing multi-
- vendor interoperability (see discussion in Section 20.32 and Section
- 20.37). An IANA registry of option tags is used to ensure easy
- reference.
-
-19.3 Tags
-
- The "tag" parameter is used in the To and From header fields of SIP
- messages. It serves as a general mechanism to identify a dialog,
- which is the combination of the Call-ID along with two tags, one from
- each participant in the dialog. When a UA sends a request outside of
- a dialog, it contains a From tag only, providing "half" of the dialog
- ID. The dialog is completed from the response(s), each of which
- contributes the second half in the To header field. The forking of
- SIP requests means that multiple dialogs can be established from a
- single request. This also explains the need for the two-sided dialog
- identifier; without a contribution from the recipients, the
- originator could not disambiguate the multiple dialogs established
- from a single request.
-
- When a tag is generated by a UA for insertion into a request or
- response, it MUST be globally unique and cryptographically random
- with at least 32 bits of randomness. A property of this selection
- requirement is that a UA will place a different tag into the From
- header of an INVITE than it would place into the To header of the
- response to the same INVITE. This is needed in order for a UA to
- invite itself to a session, a common case for "hairpinning" of calls
- in PSTN gateways. Similarly, two INVITEs for different calls will
- have different From tags, and two responses for different calls will
- have different To tags.
-
- Besides the requirement for global uniqueness, the algorithm for
- generating a tag is implementation-specific. Tags are helpful in
- fault tolerant systems, where a dialog is to be recovered on an
- alternate server after a failure. A UAS can select the tag in such a
- way that a backup can recognize a request as part of a dialog on the
- failed server, and therefore determine that it should attempt to
- recover the dialog and any other state associated with it.
-
-20 Header Fields
-
- The general syntax for header fields is covered in Section 7.3. This
- section lists the full set of header fields along with notes on
- syntax, meaning, and usage. Throughout this section, we use [HX.Y]
- to refer to Section X.Y of the current HTTP/1.1 specification RFC
- 2616 [8]. Examples of each header field are given.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 159]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Information about header fields in relation to methods and proxy
- processing is summarized in Tables 2 and 3.
-
- The "where" column describes the request and response types in which
- the header field can be used. Values in this column are:
-
- R: header field may only appear in requests;
-
- r: header field may only appear in responses;
-
- 2xx, 4xx, etc.: A numerical value or range indicates response
- codes with which the header field can be used;
-
- c: header field is copied from the request to the response.
-
- An empty entry in the "where" column indicates that the header
- field may be present in all requests and responses.
-
- The "proxy" column describes the operations a proxy may perform on a
- header field:
-
- a: A proxy can add or concatenate the header field if not present.
-
- m: A proxy can modify an existing header field value.
-
- d: A proxy can delete a header field value.
-
- r: A proxy must be able to read the header field, and thus this
- header field cannot be encrypted.
-
- The next six columns relate to the presence of a header field in a
- method:
-
- c: Conditional; requirements on the header field depend on the
- context of the message.
-
- m: The header field is mandatory.
-
- m*: The header field SHOULD be sent, but clients/servers need to
- be prepared to receive messages without that header field.
-
- o: The header field is optional.
-
- t: The header field SHOULD be sent, but clients/servers need to be
- prepared to receive messages without that header field.
-
- If a stream-based protocol (such as TCP) is used as a
- transport, then the header field MUST be sent.
-
-
-
-Rosenberg, et. al. Standards Track [Page 160]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- *: The header field is required if the message body is not empty.
- See Sections 20.14, 20.15 and 7.4 for details.
-
- -: The header field is not applicable.
-
- "Optional" means that an element MAY include the header field in a
- request or response, and a UA MAY ignore the header field if present
- in the request or response (The exception to this rule is the Require
- header field discussed in 20.32). A "mandatory" header field MUST be
- present in a request, and MUST be understood by the UAS receiving the
- request. A mandatory response header field MUST be present in the
- response, and the header field MUST be understood by the UAC
- processing the response. "Not applicable" means that the header
- field MUST NOT be present in a request. If one is placed in a
- request by mistake, it MUST be ignored by the UAS receiving the
- request. Similarly, a header field labeled "not applicable" for a
- response means that the UAS MUST NOT place the header field in the
- response, and the UAC MUST ignore the header field in the response.
-
- A UA SHOULD ignore extension header parameters that are not
- understood.
-
- A compact form of some common header field names is also defined for
- use when overall message size is an issue.
-
- The Contact, From, and To header fields contain a URI. If the URI
- contains a comma, question mark or semicolon, the URI MUST be
- enclosed in angle brackets (< and >). Any URI parameters are
- contained within these brackets. If the URI is not enclosed in angle
- brackets, any semicolon-delimited parameters are header-parameters,
- not URI parameters.
-
-20.1 Accept
-
- The Accept header field follows the syntax defined in [H14.1]. The
- semantics are also identical, with the exception that if no Accept
- header field is present, the server SHOULD assume a default value of
- application/sdp.
-
- An empty Accept header field means that no formats are acceptable.
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 161]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Example:
-
- Header field where proxy ACK BYE CAN INV OPT REG
- ___________________________________________________________
- Accept R - o - o m* o
- Accept 2xx - - - o m* o
- Accept 415 - c - c c c
- Accept-Encoding R - o - o o o
- Accept-Encoding 2xx - - - o m* o
- Accept-Encoding 415 - c - c c c
- Accept-Language R - o - o o o
- Accept-Language 2xx - - - o m* o
- Accept-Language 415 - c - c c c
- Alert-Info R ar - - - o - -
- Alert-Info 180 ar - - - o - -
- Allow R - o - o o o
- Allow 2xx - o - m* m* o
- Allow r - o - o o o
- Allow 405 - m - m m m
- Authentication-Info 2xx - o - o o o
- Authorization R o o o o o o
- Call-ID c r m m m m m m
- Call-Info ar - - - o o o
- Contact R o - - m o o
- Contact 1xx - - - o - -
- Contact 2xx - - - m o o
- Contact 3xx d - o - o o o
- Contact 485 - o - o o o
- Content-Disposition o o - o o o
- Content-Encoding o o - o o o
- Content-Language o o - o o o
- Content-Length ar t t t t t t
- Content-Type * * - * * *
- CSeq c r m m m m m m
- Date a o o o o o o
- Error-Info 300-699 a - o o o o o
- Expires - - - o - o
- From c r m m m m m m
- In-Reply-To R - - - o - -
- Max-Forwards R amr m m m m m m
- Min-Expires 423 - - - - - m
- MIME-Version o o - o o o
- Organization ar - - - o o o
-
- Table 2: Summary of header fields, A--O
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 162]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Header field where proxy ACK BYE CAN INV OPT REG
- ___________________________________________________________________
- Priority R ar - - - o - -
- Proxy-Authenticate 407 ar - m - m m m
- Proxy-Authenticate 401 ar - o o o o o
- Proxy-Authorization R dr o o - o o o
- Proxy-Require R ar - o - o o o
- Record-Route R ar o o o o o -
- Record-Route 2xx,18x mr - o o o o -
- Reply-To - - - o - -
- Require ar - c - c c c
- Retry-After 404,413,480,486 - o o o o o
- 500,503 - o o o o o
- 600,603 - o o o o o
- Route R adr c c c c c c
- Server r - o o o o o
- Subject R - - - o - -
- Supported R - o o m* o o
- Supported 2xx - o o m* m* o
- Timestamp o o o o o o
- To c(1) r m m m m m m
- Unsupported 420 - m - m m m
- User-Agent o o o o o o
- Via R amr m m m m m m
- Via rc dr m m m m m m
- Warning r - o o o o o
- WWW-Authenticate 401 ar - m - m m m
- WWW-Authenticate 407 ar - o - o o o
-
- Table 3: Summary of header fields, P--Z; (1): copied with possible
- addition of tag
-
- Accept: application/sdp;level=1, application/x-private, text/html
-
-20.2 Accept-Encoding
-
- The Accept-Encoding header field is similar to Accept, but restricts
- the content-codings [H3.5] that are acceptable in the response. See
- [H14.3]. The semantics in SIP are identical to those defined in
- [H14.3].
-
- An empty Accept-Encoding header field is permissible. It is
- equivalent to Accept-Encoding: identity, that is, only the identity
- encoding, meaning no encoding, is permissible.
-
- If no Accept-Encoding header field is present, the server SHOULD
- assume a default value of identity.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 163]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- This differs slightly from the HTTP definition, which indicates that
- when not present, any encoding can be used, but the identity encoding
- is preferred.
-
- Example:
-
- Accept-Encoding: gzip
-
-20.3 Accept-Language
-
- The Accept-Language header field is used in requests to indicate the
- preferred languages for reason phrases, session descriptions, or
- status responses carried as message bodies in the response. If no
- Accept-Language header field is present, the server SHOULD assume all
- languages are acceptable to the client.
-
- The Accept-Language header field follows the syntax defined in
- [H14.4]. The rules for ordering the languages based on the "q"
- parameter apply to SIP as well.
-
- Example:
-
- Accept-Language: da, en-gb;q=0.8, en;q=0.7
-
-20.4 Alert-Info
-
- When present in an INVITE request, the Alert-Info header field
- specifies an alternative ring tone to the UAS. When present in a 180
- (Ringing) response, the Alert-Info header field specifies an
- alternative ringback tone to the UAC. A typical usage is for a proxy
- to insert this header field to provide a distinctive ring feature.
-
- The Alert-Info header field can introduce security risks. These
- risks and the ways to handle them are discussed in Section 20.9,
- which discusses the Call-Info header field since the risks are
- identical.
-
- In addition, a user SHOULD be able to disable this feature
- selectively.
-
- This helps prevent disruptions that could result from the use of
- this header field by untrusted elements.
-
- Example:
-
- Alert-Info: <http://www.example.com/sounds/moo.wav>
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 164]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-20.5 Allow
-
- The Allow header field lists the set of methods supported by the UA
- generating the message.
-
- All methods, including ACK and CANCEL, understood by the UA MUST be
- included in the list of methods in the Allow header field, when
- present. The absence of an Allow header field MUST NOT be
- interpreted to mean that the UA sending the message supports no
- methods. Rather, it implies that the UA is not providing any
- information on what methods it supports.
-
- Supplying an Allow header field in responses to methods other than
- OPTIONS reduces the number of messages needed.
-
- Example:
-
- Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
-
-20.6 Authentication-Info
-
- The Authentication-Info header field provides for mutual
- authentication with HTTP Digest. A UAS MAY include this header field
- in a 2xx response to a request that was successfully authenticated
- using digest based on the Authorization header field.
-
- Syntax and semantics follow those specified in RFC 2617 [17].
-
- Example:
-
- Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
-
-20.7 Authorization
-
- The Authorization header field contains authentication credentials of
- a UA. Section 22.2 overviews the use of the Authorization header
- field, and Section 22.4 describes the syntax and semantics when used
- with HTTP authentication.
-
- This header field, along with Proxy-Authorization, breaks the general
- rules about multiple header field values. Although not a comma-
- separated list, this header field name may be present multiple times,
- and MUST NOT be combined into a single header line using the usual
- rules described in Section 7.3.
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 165]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- In the example below, there are no quotes around the Digest
- parameter:
-
- Authorization: Digest username="Alice", realm="atlanta.com",
- nonce="84a4cc6f3082121f32b42a2187831a9e",
- response="7587245234b3434cc3412213e5f113a5432"
-
-20.8 Call-ID
-
- The Call-ID header field uniquely identifies a particular invitation
- or all registrations of a particular client. A single multimedia
- conference can give rise to several calls with different Call-IDs,
- for example, if a user invites a single individual several times to
- the same (long-running) conference. Call-IDs are case-sensitive and
- are simply compared byte-by-byte.
-
- The compact form of the Call-ID header field is i.
-
- Examples:
-
- Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
- i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
-
-20.9 Call-Info
-
- The Call-Info header field provides additional information about the
- caller or callee, depending on whether it is found in a request or
- response. The purpose of the URI is described by the "purpose"
- parameter. The "icon" parameter designates an image suitable as an
- iconic representation of the caller or callee. The "info" parameter
- describes the caller or callee in general, for example, through a web
- page. The "card" parameter provides a business card, for example, in
- vCard [36] or LDIF [37] formats. Additional tokens can be registered
- using IANA and the procedures in Section 27.
-
- Use of the Call-Info header field can pose a security risk. If a
- callee fetches the URIs provided by a malicious caller, the callee
- may be at risk for displaying inappropriate or offensive content,
- dangerous or illegal content, and so on. Therefore, it is
- RECOMMENDED that a UA only render the information in the Call-Info
- header field if it can verify the authenticity of the element that
- originated the header field and trusts that element. This need not
- be the peer UA; a proxy can insert this header field into requests.
-
- Example:
-
- Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
- <http://www.example.com/alice/> ;purpose=info
-
-
-
-Rosenberg, et. al. Standards Track [Page 166]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-20.10 Contact
-
- A Contact header field value provides a URI whose meaning depends on
- the type of request or response it is in.
-
- A Contact header field value can contain a display name, a URI with
- URI parameters, and header parameters.
-
- This document defines the Contact parameters "q" and "expires".
- These parameters are only used when the Contact is present in a
- REGISTER request or response, or in a 3xx response. Additional
- parameters may be defined in other specifications.
-
- When the header field value contains a display name, the URI
- including all URI parameters is enclosed in "<" and ">". If no "<"
- and ">" are present, all parameters after the URI are header
- parameters, not URI parameters. The display name can be tokens, or a
- quoted string, if a larger character set is desired.
-
- Even if the "display-name" is empty, the "name-addr" form MUST be
- used if the "addr-spec" contains a comma, semicolon, or question
- mark. There may or may not be LWS between the display-name and the
- "<".
-
- These rules for parsing a display name, URI and URI parameters, and
- header parameters also apply for the header fields To and From.
-
- The Contact header field has a role similar to the Location header
- field in HTTP. However, the HTTP header field only allows one
- address, unquoted. Since URIs can contain commas and semicolons
- as reserved characters, they can be mistaken for header or
- parameter delimiters, respectively.
-
- The compact form of the Contact header field is m (for "moved").
-
- Examples:
-
- Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
- ;q=0.7; expires=3600,
- "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
- m: <sips:bob@192.0.2.4>;expires=60
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 167]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-20.11 Content-Disposition
-
- The Content-Disposition header field describes how the message body
- or, for multipart messages, a message body part is to be interpreted
- by the UAC or UAS. This SIP header field extends the MIME Content-
- Type (RFC 2183 [18]).
-
- Several new "disposition-types" of the Content-Disposition header are
- defined by SIP. The value "session" indicates that the body part
- describes a session, for either calls or early (pre-call) media. The
- value "render" indicates that the body part should be displayed or
- otherwise rendered to the user. Note that the value "render" is used
- rather than "inline" to avoid the connotation that the MIME body is
- displayed as a part of the rendering of the entire message (since the
- MIME bodies of SIP messages oftentimes are not displayed to users).
- For backward-compatibility, if the Content-Disposition header field
- is missing, the server SHOULD assume bodies of Content-Type
- application/sdp are the disposition "session", while other content
- types are "render".
-
- The disposition type "icon" indicates that the body part contains an
- image suitable as an iconic representation of the caller or callee
- that could be rendered informationally by a user agent when a message
- has been received, or persistently while a dialog takes place. The
- value "alert" indicates that the body part contains information, such
- as an audio clip, that should be rendered by the user agent in an
- attempt to alert the user to the receipt of a request, generally a
- request that initiates a dialog; this alerting body could for example
- be rendered as a ring tone for a phone call after a 180 Ringing
- provisional response has been sent.
-
- Any MIME body with a "disposition-type" that renders content to the
- user should only be processed when a message has been properly
- authenticated.
-
- The handling parameter, handling-param, describes how the UAS should
- react if it receives a message body whose content type or disposition
- type it does not understand. The parameter has defined values of
- "optional" and "required". If the handling parameter is missing, the
- value "required" SHOULD be assumed. The handling parameter is
- described in RFC 3204 [19].
-
- If this header field is missing, the MIME type determines the default
- content disposition. If there is none, "render" is assumed.
-
- Example:
-
- Content-Disposition: session
-
-
-
-Rosenberg, et. al. Standards Track [Page 168]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-20.12 Content-Encoding
-
- The Content-Encoding header field is used as a modifier to the
- "media-type". When present, its value indicates what additional
- content codings have been applied to the entity-body, and thus what
- decoding mechanisms MUST be applied in order to obtain the media-type
- referenced by the Content-Type header field. Content-Encoding is
- primarily used to allow a body to be compressed without losing the
- identity of its underlying media type.
-
- If multiple encodings have been applied to an entity-body, the
- content codings MUST be listed in the order in which they were
- applied.
-
- All content-coding values are case-insensitive. IANA acts as a
- registry for content-coding value tokens. See [H3.5] for a
- definition of the syntax for content-coding.
-
- Clients MAY apply content encodings to the body in requests. A
- server MAY apply content encodings to the bodies in responses. The
- server MUST only use encodings listed in the Accept-Encoding header
- field in the request.
-
- The compact form of the Content-Encoding header field is e.
- Examples:
-
- Content-Encoding: gzip
- e: tar
-
-20.13 Content-Language
-
- See [H14.12]. Example:
-
- Content-Language: fr
-
-20.14 Content-Length
-
- The Content-Length header field indicates the size of the message-
- body, in decimal number of octets, sent to the recipient.
- Applications SHOULD use this field to indicate the size of the
- message-body to be transferred, regardless of the media type of the
- entity. If a stream-based protocol (such as TCP) is used as
- transport, the header field MUST be used.
-
- The size of the message-body does not include the CRLF separating
- header fields and body. Any Content-Length greater than or equal to
- zero is a valid value. If no body is present in a message, then the
- Content-Length header field value MUST be set to zero.
-
-
-
-Rosenberg, et. al. Standards Track [Page 169]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The ability to omit Content-Length simplifies the creation of
- cgi-like scripts that dynamically generate responses.
-
- The compact form of the header field is l.
-
- Examples:
-
- Content-Length: 349
- l: 173
-
-20.15 Content-Type
-
- The Content-Type header field indicates the media type of the
- message-body sent to the recipient. The "media-type" element is
- defined in [H3.7]. The Content-Type header field MUST be present if
- the body is not empty. If the body is empty, and a Content-Type
- header field is present, it indicates that the body of the specific
- type has zero length (for example, an empty audio file).
-
- The compact form of the header field is c.
-
- Examples:
-
- Content-Type: application/sdp
- c: text/html; charset=ISO-8859-4
-
-20.16 CSeq
-
- A CSeq header field in a request contains a single decimal sequence
- number and the request method. The sequence number MUST be
- expressible as a 32-bit unsigned integer. The method part of CSeq is
- case-sensitive. The CSeq header field serves to order transactions
- within a dialog, to provide a means to uniquely identify
- transactions, and to differentiate between new requests and request
- retransmissions. Two CSeq header fields are considered equal if the
- sequence number and the request method are identical. Example:
-
- CSeq: 4711 INVITE
-
-20.17 Date
-
- The Date header field contains the date and time. Unlike HTTP/1.1,
- SIP only supports the most recent RFC 1123 [20] format for dates. As
- in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while
- RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive.
-
- The Date header field reflects the time when the request or response
- is first sent.
-
-
-
-Rosenberg, et. al. Standards Track [Page 170]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The Date header field can be used by simple end systems without a
- battery-backed clock to acquire a notion of current time.
- However, in its GMT form, it requires clients to know their offset
- from GMT.
-
- Example:
-
- Date: Sat, 13 Nov 2010 23:29:00 GMT
-
-20.18 Error-Info
-
- The Error-Info header field provides a pointer to additional
- information about the error status response.
-
- SIP UACs have user interface capabilities ranging from pop-up
- windows and audio on PC softclients to audio-only on "black"
- phones or endpoints connected via gateways. Rather than forcing a
- server generating an error to choose between sending an error
- status code with a detailed reason phrase and playing an audio
- recording, the Error-Info header field allows both to be sent.
- The UAC then has the choice of which error indicator to render to
- the caller.
-
- A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if
- it were a Contact in a redirect and generate a new INVITE, resulting
- in a recorded announcement session being established. A non-SIP URI
- MAY be rendered to the user.
-
- Examples:
-
- SIP/2.0 404 The number you have dialed is not in service
- Error-Info: <sip:not-in-service-recording@atlanta.com>
-
-20.19 Expires
-
- The Expires header field gives the relative time after which the
- message (or content) expires.
-
- The precise meaning of this is method dependent.
-
- The expiration time in an INVITE does not affect the duration of the
- actual session that may result from the invitation. Session
- description protocols may offer the ability to express time limits on
- the session duration, however.
-
- The value of this field is an integral number of seconds (in decimal)
- between 0 and (2**32)-1, measured from the receipt of the request.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 171]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Example:
-
- Expires: 5
-
-20.20 From
-
- The From header field indicates the initiator of the request. This
- may be different from the initiator of the dialog. Requests sent by
- the callee to the caller use the callee's address in the From header
- field.
-
- The optional "display-name" is meant to be rendered by a human user
- interface. A system SHOULD use the display name "Anonymous" if the
- identity of the client is to remain hidden. Even if the "display-
- name" is empty, the "name-addr" form MUST be used if the "addr-spec"
- contains a comma, question mark, or semicolon. Syntax issues are
- discussed in Section 7.3.1.
-
- Two From header fields are equivalent if their URIs match, and their
- parameters match. Extension parameters in one header field, not
- present in the other are ignored for the purposes of comparison. This
- means that the display name and presence or absence of angle brackets
- do not affect matching.
-
- See Section 20.10 for the rules for parsing a display name, URI and
- URI parameters, and header field parameters.
-
- The compact form of the From header field is f.
-
- Examples:
-
- From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
- From: sip:+12125551212@server.phone2net.com;tag=887s
- f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
-
-20.21 In-Reply-To
-
- The In-Reply-To header field enumerates the Call-IDs that this call
- references or returns. These Call-IDs may have been cached by the
- client then included in this header field in a return call.
-
- This allows automatic call distribution systems to route return
- calls to the originator of the first call. This also allows
- callees to filter calls, so that only return calls for calls they
- originated will be accepted. This field is not a substitute for
- request authentication.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 172]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Example:
-
- In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
-
-20.22 Max-Forwards
-
- The Max-Forwards header field must be used with any SIP method to
- limit the number of proxies or gateways that can forward the request
- to the next downstream server. This can also be useful when the
- client is attempting to trace a request chain that appears to be
- failing or looping in mid-chain.
-
- The Max-Forwards value is an integer in the range 0-255 indicating
- the remaining number of times this request message is allowed to be
- forwarded. This count is decremented by each server that forwards
- the request. The recommended initial value is 70.
-
- This header field should be inserted by elements that can not
- otherwise guarantee loop detection. For example, a B2BUA should
- insert a Max-Forwards header field.
-
- Example:
-
- Max-Forwards: 6
-
-20.23 Min-Expires
-
- The Min-Expires header field conveys the minimum refresh interval
- supported for soft-state elements managed by that server. This
- includes Contact header fields that are stored by a registrar. The
- header field contains a decimal integer number of seconds from 0 to
- (2**32)-1. The use of the header field in a 423 (Interval Too Brief)
- response is described in Sections 10.2.8, 10.3, and 21.4.17.
-
- Example:
-
- Min-Expires: 60
-
-20.24 MIME-Version
-
- See [H19.4.1].
-
- Example:
-
- MIME-Version: 1.0
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 173]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-20.25 Organization
-
- The Organization header field conveys the name of the organization to
- which the SIP element issuing the request or response belongs.
-
- The field MAY be used by client software to filter calls.
-
- Example:
-
- Organization: Boxes by Bob
-
-20.26 Priority
-
- The Priority header field indicates the urgency of the request as
- perceived by the client. The Priority header field describes the
- priority that the SIP request should have to the receiving human or
- its agent. For example, it may be factored into decisions about call
- routing and acceptance. For these decisions, a message containing no
- Priority header field SHOULD be treated as if it specified a Priority
- of "normal". The Priority header field does not influence the use of
- communications resources such as packet forwarding priority in
- routers or access to circuits in PSTN gateways. The header field can
- have the values "non-urgent", "normal", "urgent", and "emergency",
- but additional values can be defined elsewhere. It is RECOMMENDED
- that the value of "emergency" only be used when life, limb, or
- property are in imminent danger. Otherwise, there are no semantics
- defined for this header field.
-
- These are the values of RFC 2076 [38], with the addition of
- "emergency".
-
- Examples:
-
- Subject: A tornado is heading our way!
- Priority: emergency
-
- or
-
- Subject: Weekend plans
- Priority: non-urgent
-
-20.27 Proxy-Authenticate
-
- A Proxy-Authenticate header field value contains an authentication
- challenge.
-
- The use of this header field is defined in [H14.33]. See Section
- 22.3 for further details on its usage.
-
-
-
-Rosenberg, et. al. Standards Track [Page 174]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Example:
-
- Proxy-Authenticate: Digest realm="atlanta.com",
- domain="sip:ss1.carrier.com", qop="auth",
- nonce="f84f1cec41e6cbe5aea9c8e88d359",
- opaque="", stale=FALSE, algorithm=MD5
-
-20.28 Proxy-Authorization
-
- The Proxy-Authorization header field allows the client to identify
- itself (or its user) to a proxy that requires authentication. A
- Proxy-Authorization field value consists of credentials containing
- the authentication information of the user agent for the proxy and/or
- realm of the resource being requested.
-
- See Section 22.3 for a definition of the usage of this header field.
-
- This header field, along with Authorization, breaks the general rules
- about multiple header field names. Although not a comma-separated
- list, this header field name may be present multiple times, and MUST
- NOT be combined into a single header line using the usual rules
- described in Section 7.3.1.
-
- Example:
-
- Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
- nonce="c60f3082ee1212b402a21831ae",
- response="245f23415f11432b3434341c022"
-
-20.29 Proxy-Require
-
- The Proxy-Require header field is used to indicate proxy-sensitive
- features that must be supported by the proxy. See Section 20.32 for
- more details on the mechanics of this message and a usage example.
-
- Example:
-
- Proxy-Require: foo
-
-20.30 Record-Route
-
- The Record-Route header field is inserted by proxies in a request to
- force future requests in the dialog to be routed through the proxy.
-
- Examples of its use with the Route header field are described in
- Sections 16.12.1.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 175]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Example:
-
- Record-Route: <sip:server10.biloxi.com;lr>,
- <sip:bigbox3.site3.atlanta.com;lr>
-
-20.31 Reply-To
-
- The Reply-To header field contains a logical return URI that may be
- different from the From header field. For example, the URI MAY be
- used to return missed calls or unestablished sessions. If the user
- wished to remain anonymous, the header field SHOULD either be omitted
- from the request or populated in such a way that does not reveal any
- private information.
-
- Even if the "display-name" is empty, the "name-addr" form MUST be
- used if the "addr-spec" contains a comma, question mark, or
- semicolon. Syntax issues are discussed in Section 7.3.1.
-
- Example:
-
- Reply-To: Bob <sip:bob@biloxi.com>
-
-20.32 Require
-
- The Require header field is used by UACs to tell UASs about options
- that the UAC expects the UAS to support in order to process the
- request. Although an optional header field, the Require MUST NOT be
- ignored if it is present.
-
- The Require header field contains a list of option tags, described in
- Section 19.2. Each option tag defines a SIP extension that MUST be
- understood to process the request. Frequently, this is used to
- indicate that a specific set of extension header fields need to be
- understood. A UAC compliant to this specification MUST only include
- option tags corresponding to standards-track RFCs.
-
- Example:
-
- Require: 100rel
-
-20.33 Retry-After
-
- The Retry-After header field can be used with a 500 (Server Internal
- Error) or 503 (Service Unavailable) response to indicate how long the
- service is expected to be unavailable to the requesting client and
- with a 404 (Not Found), 413 (Request Entity Too Large), 480
- (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 176]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- (Decline) response to indicate when the called party anticipates
- being available again. The value of this field is a positive integer
- number of seconds (in decimal) after the time of the response.
-
- An optional comment can be used to indicate additional information
- about the time of callback. An optional "duration" parameter
- indicates how long the called party will be reachable starting at the
- initial time of availability. If no duration parameter is given, the
- service is assumed to be available indefinitely.
-
- Examples:
-
- Retry-After: 18000;duration=3600
- Retry-After: 120 (I'm in a meeting)
-
-20.34 Route
-
- The Route header field is used to force routing for a request through
- the listed set of proxies. Examples of the use of the Route header
- field are in Section 16.12.1.
-
- Example:
-
- Route: <sip:bigbox3.site3.atlanta.com;lr>,
- <sip:server10.biloxi.com;lr>
-
-20.35 Server
-
- The Server header field contains information about the software used
- by the UAS to handle the request.
-
- Revealing the specific software version of the server might allow the
- server to become more vulnerable to attacks against software that is
- known to contain security holes. Implementers SHOULD make the Server
- header field a configurable option.
-
- Example:
-
- Server: HomeServer v2
-
-20.36 Subject
-
- The Subject header field provides a summary or indicates the nature
- of the call, allowing call filtering without having to parse the
- session description. The session description does not have to use
- the same subject indication as the invitation.
-
- The compact form of the Subject header field is s.
-
-
-
-Rosenberg, et. al. Standards Track [Page 177]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Example:
-
- Subject: Need more boxes
- s: Tech Support
-
-20.37 Supported
-
- The Supported header field enumerates all the extensions supported by
- the UAC or UAS.
-
- The Supported header field contains a list of option tags, described
- in Section 19.2, that are understood by the UAC or UAS. A UA
- compliant to this specification MUST only include option tags
- corresponding to standards-track RFCs. If empty, it means that no
- extensions are supported.
-
- The compact form of the Supported header field is k.
-
- Example:
-
- Supported: 100rel
-
-20.38 Timestamp
-
- The Timestamp header field describes when the UAC sent the request to
- the UAS.
-
- See Section 8.2.6 for details on how to generate a response to a
- request that contains the header field. Although there is no
- normative behavior defined here that makes use of the header, it
- allows for extensions or SIP applications to obtain RTT estimates.
-
- Example:
-
- Timestamp: 54
-
-20.39 To
-
- The To header field specifies the logical recipient of the request.
-
- The optional "display-name" is meant to be rendered by a human-user
- interface. The "tag" parameter serves as a general mechanism for
- dialog identification.
-
- See Section 19.3 for details of the "tag" parameter.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 178]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Comparison of To header fields for equality is identical to
- comparison of From header fields. See Section 20.10 for the rules
- for parsing a display name, URI and URI parameters, and header field
- parameters.
-
- The compact form of the To header field is t.
-
- The following are examples of valid To header fields:
-
- To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
- t: sip:+12125551212@server.phone2net.com
-
-20.40 Unsupported
-
- The Unsupported header field lists the features not supported by the
- UAS. See Section 20.32 for motivation.
-
- Example:
-
- Unsupported: foo
-
-20.41 User-Agent
-
- The User-Agent header field contains information about the UAC
- originating the request. The semantics of this header field are
- defined in [H14.43].
-
- Revealing the specific software version of the user agent might allow
- the user agent to become more vulnerable to attacks against software
- that is known to contain security holes. Implementers SHOULD make
- the User-Agent header field a configurable option.
-
- Example:
-
- User-Agent: Softphone Beta1.5
-
-20.42 Via
-
- The Via header field indicates the path taken by the request so far
- and indicates the path that should be followed in routing responses.
- The branch ID parameter in the Via header field values serves as a
- transaction identifier, and is used by proxies to detect loops.
-
- A Via header field value contains the transport protocol used to send
- the message, the client's host name or network address, and possibly
- the port number at which it wishes to receive responses. A Via
- header field value can also contain parameters such as "maddr",
- "ttl", "received", and "branch", whose meaning and use are described
-
-
-
-Rosenberg, et. al. Standards Track [Page 179]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- in other sections. For implementations compliant to this
- specification, the value of the branch parameter MUST start with the
- magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.
-
- Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
- "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the
- protocol still indicates "SIP", and the transport protocol is TLS.
-
-Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
-Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
- ;branch=z9hG4bK77asjd
-
- The compact form of the Via header field is v.
-
- In this example, the message originated from a multi-homed host with
- two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong
- as to which network interface would be used. Erlang.bell-
- telephone.com noticed the mismatch and added a parameter to the
- previous hop's Via header field value, containing the address that
- the packet actually came from.
-
- The host or network address and port number are not required to
- follow the SIP URI syntax. Specifically, LWS on either side of the
- ":" or "/" is allowed, as shown here:
-
- Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
- ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
-
- Even though this specification mandates that the branch parameter be
- present in all requests, the BNF for the header field indicates that
- it is optional. This allows interoperation with RFC 2543 elements,
- which did not have to insert the branch parameter.
-
- Two Via header fields are equal if their sent-protocol and sent-by
- fields are equal, both have the same set of parameters, and the
- values of all parameters are equal.
-
-20.43 Warning
-
- The Warning header field is used to carry additional information
- about the status of a response. Warning header field values are sent
- with responses and contain a three-digit warning code, host name, and
- warning text.
-
- The "warn-text" should be in a natural language that is most likely
- to be intelligible to the human user receiving the response. This
- decision can be based on any available knowledge, such as the
- location of the user, the Accept-Language field in a request, or the
-
-
-
-Rosenberg, et. al. Standards Track [Page 180]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Content-Language field in a response. The default language is i-
- default [21].
-
- The currently-defined "warn-code"s are listed below, with a
- recommended warn-text in English and a description of their meaning.
- These warnings describe failures induced by the session description.
- The first digit of warning codes beginning with "3" indicates
- warnings specific to SIP. Warnings 300 through 329 are reserved for
- indicating problems with keywords in the session description, 330
- through 339 are warnings related to basic network services requested
- in the session description, 370 through 379 are warnings related to
- quantitative QoS parameters requested in the session description, and
- 390 through 399 are miscellaneous warnings that do not fall into one
- of the above categories.
-
- 300 Incompatible network protocol: One or more network protocols
- contained in the session description are not available.
-
- 301 Incompatible network address formats: One or more network
- address formats contained in the session description are not
- available.
-
- 302 Incompatible transport protocol: One or more transport
- protocols described in the session description are not
- available.
-
- 303 Incompatible bandwidth units: One or more bandwidth
- measurement units contained in the session description were
- not understood.
-
- 304 Media type not available: One or more media types contained in
- the session description are not available.
-
- 305 Incompatible media format: One or more media formats contained
- in the session description are not available.
-
- 306 Attribute not understood: One or more of the media attributes
- in the session description are not supported.
-
- 307 Session description parameter not understood: A parameter
- other than those listed above was not understood.
-
- 330 Multicast not available: The site where the user is located
- does not support multicast.
-
- 331 Unicast not available: The site where the user is located does
- not support unicast communication (usually due to the presence
- of a firewall).
-
-
-
-Rosenberg, et. al. Standards Track [Page 181]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- 370 Insufficient bandwidth: The bandwidth specified in the session
- description or defined by the media exceeds that known to be
- available.
-
- 399 Miscellaneous warning: The warning text can include arbitrary
- information to be presented to a human user or logged. A
- system receiving this warning MUST NOT take any automated
- action.
-
- 1xx and 2xx have been taken by HTTP/1.1.
-
- Additional "warn-code"s can be defined through IANA, as defined in
- Section 27.2.
-
- Examples:
-
- Warning: 307 isi.edu "Session parameter 'foo' not understood"
- Warning: 301 isi.edu "Incompatible network address type 'E.164'"
-
-20.44 WWW-Authenticate
-
- A WWW-Authenticate header field value contains an authentication
- challenge. See Section 22.2 for further details on its usage.
-
- Example:
-
- WWW-Authenticate: Digest realm="atlanta.com",
- domain="sip:boxesbybob.com", qop="auth",
- nonce="f84f1cec41e6cbe5aea9c8e88d359",
- opaque="", stale=FALSE, algorithm=MD5
-
-21 Response Codes
-
- The response codes are consistent with, and extend, HTTP/1.1 response
- codes. Not all HTTP/1.1 response codes are appropriate, and only
- those that are appropriate are given here. Other HTTP/1.1 response
- codes SHOULD NOT be used. Also, SIP defines a new class, 6xx.
-
-21.1 Provisional 1xx
-
- Provisional responses, also known as informational responses,
- indicate that the server contacted is performing some further action
- and does not yet have a definitive response. A server sends a 1xx
- response if it expects to take more than 200 ms to obtain a final
- response. Note that 1xx responses are not transmitted reliably.
- They never cause the client to send an ACK. Provisional (1xx)
- responses MAY contain message bodies, including session descriptions.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 182]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.1.1 100 Trying
-
- This response indicates that the request has been received by the
- next-hop server and that some unspecified action is being taken on
- behalf of this call (for example, a database is being consulted).
- This response, like all other provisional responses, stops
- retransmissions of an INVITE by a UAC. The 100 (Trying) response is
- different from other provisional responses, in that it is never
- forwarded upstream by a stateful proxy.
-
-21.1.2 180 Ringing
-
- The UA receiving the INVITE is trying to alert the user. This
- response MAY be used to initiate local ringback.
-
-21.1.3 181 Call Is Being Forwarded
-
- A server MAY use this status code to indicate that the call is being
- forwarded to a different set of destinations.
-
-21.1.4 182 Queued
-
- The called party is temporarily unavailable, but the server has
- decided to queue the call rather than reject it. When the callee
- becomes available, it will return the appropriate final status
- response. The reason phrase MAY give further details about the
- status of the call, for example, "5 calls queued; expected waiting
- time is 15 minutes". The server MAY issue several 182 (Queued)
- responses to update the caller about the status of the queued call.
-
-21.1.5 183 Session Progress
-
- The 183 (Session Progress) response is used to convey information
- about the progress of the call that is not otherwise classified. The
- Reason-Phrase, header fields, or message body MAY be used to convey
- more details about the call progress.
-
-21.2 Successful 2xx
-
- The request was successful.
-
-21.2.1 200 OK
-
- The request has succeeded. The information returned with the
- response depends on the method used in the request.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 183]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.3 Redirection 3xx
-
- 3xx responses give information about the user's new location, or
- about alternative services that might be able to satisfy the call.
-
-21.3.1 300 Multiple Choices
-
- The address in the request resolved to several choices, each with its
- own specific location, and the user (or UA) can select a preferred
- communication end point and redirect its request to that location.
-
- The response MAY include a message body containing a list of resource
- characteristics and location(s) from which the user or UA can choose
- the one most appropriate, if allowed by the Accept request header
- field. However, no MIME types have been defined for this message
- body.
-
- The choices SHOULD also be listed as Contact fields (Section 20.10).
- Unlike HTTP, the SIP response MAY contain several Contact fields or a
- list of addresses in a Contact field. UAs MAY use the Contact header
- field value for automatic redirection or MAY ask the user to confirm
- a choice. However, this specification does not define any standard
- for such automatic selection.
-
- This status response is appropriate if the callee can be reached
- at several different locations and the server cannot or prefers
- not to proxy the request.
-
-21.3.2 301 Moved Permanently
-
- The user can no longer be found at the address in the Request-URI,
- and the requesting client SHOULD retry at the new address given by
- the Contact header field (Section 20.10). The requestor SHOULD
- update any local directories, address books, and user location caches
- with this new value and redirect future requests to the address(es)
- listed.
-
-21.3.3 302 Moved Temporarily
-
- The requesting client SHOULD retry the request at the new address(es)
- given by the Contact header field (Section 20.10). The Request-URI
- of the new request uses the value of the Contact header field in the
- response.
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 184]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The duration of the validity of the Contact URI can be indicated
- through an Expires (Section 20.19) header field or an expires
- parameter in the Contact header field. Both proxies and UAs MAY
- cache this URI for the duration of the expiration time. If there is
- no explicit expiration time, the address is only valid once for
- recursing, and MUST NOT be cached for future transactions.
-
- If the URI cached from the Contact header field fails, the Request-
- URI from the redirected request MAY be tried again a single time.
-
- The temporary URI may have become out-of-date sooner than the
- expiration time, and a new temporary URI may be available.
-
-21.3.4 305 Use Proxy
-
- The requested resource MUST be accessed through the proxy given by
- the Contact field. The Contact field gives the URI of the proxy.
- The recipient is expected to repeat this single request via the
- proxy. 305 (Use Proxy) responses MUST only be generated by UASs.
-
-21.3.5 380 Alternative Service
-
- The call was not successful, but alternative services are possible.
-
- The alternative services are described in the message body of the
- response. Formats for such bodies are not defined here, and may be
- the subject of future standardization.
-
-21.4 Request Failure 4xx
-
- 4xx responses are definite failure responses from a particular
- server. The client SHOULD NOT retry the same request without
- modification (for example, adding appropriate authorization).
- However, the same request to a different server might be successful.
-
-21.4.1 400 Bad Request
-
- The request could not be understood due to malformed syntax. The
- Reason-Phrase SHOULD identify the syntax problem in more detail, for
- example, "Missing Call-ID header field".
-
-21.4.2 401 Unauthorized
-
- The request requires user authentication. This response is issued by
- UASs and registrars, while 407 (Proxy Authentication Required) is
- used by proxy servers.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 185]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.4.3 402 Payment Required
-
- Reserved for future use.
-
-21.4.4 403 Forbidden
-
- The server understood the request, but is refusing to fulfill it.
- Authorization will not help, and the request SHOULD NOT be repeated.
-
-21.4.5 404 Not Found
-
- The server has definitive information that the user does not exist at
- the domain specified in the Request-URI. This status is also
- returned if the domain in the Request-URI does not match any of the
- domains handled by the recipient of the request.
-
-21.4.6 405 Method Not Allowed
-
- The method specified in the Request-Line is understood, but not
- allowed for the address identified by the Request-URI.
-
- The response MUST include an Allow header field containing a list of
- valid methods for the indicated address.
-
-21.4.7 406 Not Acceptable
-
- The resource identified by the request is only capable of generating
- response entities that have content characteristics not acceptable
- according to the Accept header field sent in the request.
-
-21.4.8 407 Proxy Authentication Required
-
- This code is similar to 401 (Unauthorized), but indicates that the
- client MUST first authenticate itself with the proxy. SIP access
- authentication is explained in Sections 26 and 22.3.
-
- This status code can be used for applications where access to the
- communication channel (for example, a telephony gateway) rather than
- the callee requires authentication.
-
-21.4.9 408 Request Timeout
-
- The server could not produce a response within a suitable amount of
- time, for example, if it could not determine the location of the user
- in time. The client MAY repeat the request without modifications at
- any later time.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 186]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.4.10 410 Gone
-
- The requested resource is no longer available at the server and no
- forwarding address is known. This condition is expected to be
- considered permanent. If the server does not know, or has no
- facility to determine, whether or not the condition is permanent, the
- status code 404 (Not Found) SHOULD be used instead.
-
-21.4.11 413 Request Entity Too Large
-
- The server is refusing to process a request because the request
- entity-body is larger than the server is willing or able to process.
- The server MAY close the connection to prevent the client from
- continuing the request.
-
- If the condition is temporary, the server SHOULD include a Retry-
- After header field to indicate that it is temporary and after what
- time the client MAY try again.
-
-21.4.12 414 Request-URI Too Long
-
- The server is refusing to service the request because the Request-URI
- is longer than the server is willing to interpret.
-
-21.4.13 415 Unsupported Media Type
-
- The server is refusing to service the request because the message
- body of the request is in a format not supported by the server for
- the requested method. The server MUST return a list of acceptable
- formats using the Accept, Accept-Encoding, or Accept-Language header
- field, depending on the specific problem with the content. UAC
- processing of this response is described in Section 8.1.3.5.
-
-21.4.14 416 Unsupported URI Scheme
-
- The server cannot process the request because the scheme of the URI
- in the Request-URI is unknown to the server. Client processing of
- this response is described in Section 8.1.3.5.
-
-21.4.15 420 Bad Extension
-
- The server did not understand the protocol extension specified in a
- Proxy-Require (Section 20.29) or Require (Section 20.32) header
- field. The server MUST include a list of the unsupported extensions
- in an Unsupported header field in the response. UAC processing of
- this response is described in Section 8.1.3.5.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 187]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.4.16 421 Extension Required
-
- The UAS needs a particular extension to process the request, but this
- extension is not listed in a Supported header field in the request.
- Responses with this status code MUST contain a Require header field
- listing the required extensions.
-
- A UAS SHOULD NOT use this response unless it truly cannot provide any
- useful service to the client. Instead, if a desirable extension is
- not listed in the Supported header field, servers SHOULD process the
- request using baseline SIP capabilities and any extensions supported
- by the client.
-
-21.4.17 423 Interval Too Brief
-
- The server is rejecting the request because the expiration time of
- the resource refreshed by the request is too short. This response
- can be used by a registrar to reject a registration whose Contact
- header field expiration time was too small. The use of this response
- and the related Min-Expires header field are described in Sections
- 10.2.8, 10.3, and 20.23.
-
-21.4.18 480 Temporarily Unavailable
-
- The callee's end system was contacted successfully but the callee is
- currently unavailable (for example, is not logged in, logged in but
- in a state that precludes communication with the callee, or has
- activated the "do not disturb" feature). The response MAY indicate a
- better time to call in the Retry-After header field. The user could
- also be available elsewhere (unbeknownst to this server). The reason
- phrase SHOULD indicate a more precise cause as to why the callee is
- unavailable. This value SHOULD be settable by the UA. Status 486
- (Busy Here) MAY be used to more precisely indicate a particular
- reason for the call failure.
-
- This status is also returned by a redirect or proxy server that
- recognizes the user identified by the Request-URI, but does not
- currently have a valid forwarding location for that user.
-
-21.4.19 481 Call/Transaction Does Not Exist
-
- This status indicates that the UAS received a request that does not
- match any existing dialog or transaction.
-
-21.4.20 482 Loop Detected
-
- The server has detected a loop (Section 16.3 Item 4).
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 188]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.4.21 483 Too Many Hops
-
- The server received a request that contains a Max-Forwards (Section
- 20.22) header field with the value zero.
-
-21.4.22 484 Address Incomplete
-
- The server received a request with a Request-URI that was incomplete.
- Additional information SHOULD be provided in the reason phrase.
-
- This status code allows overlapped dialing. With overlapped
- dialing, the client does not know the length of the dialing
- string. It sends strings of increasing lengths, prompting the
- user for more input, until it no longer receives a 484 (Address
- Incomplete) status response.
-
-21.4.23 485 Ambiguous
-
- The Request-URI was ambiguous. The response MAY contain a listing of
- possible unambiguous addresses in Contact header fields. Revealing
- alternatives can infringe on privacy of the user or the organization.
- It MUST be possible to configure a server to respond with status 404
- (Not Found) or to suppress the listing of possible choices for
- ambiguous Request-URIs.
-
- Example response to a request with the Request-URI
- sip:lee@example.com:
-
- SIP/2.0 485 Ambiguous
- Contact: Carol Lee <sip:carol.lee@example.com>
- Contact: Ping Lee <sip:p.lee@example.com>
- Contact: Lee M. Foote <sips:lee.foote@example.com>
-
- Some email and voice mail systems provide this functionality. A
- status code separate from 3xx is used since the semantics are
- different: for 300, it is assumed that the same person or service
- will be reached by the choices provided. While an automated
- choice or sequential search makes sense for a 3xx response, user
- intervention is required for a 485 (Ambiguous) response.
-
-21.4.24 486 Busy Here
-
- The callee's end system was contacted successfully, but the callee is
- currently not willing or able to take additional calls at this end
- system. The response MAY indicate a better time to call in the
- Retry-After header field. The user could also be available
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 189]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- elsewhere, such as through a voice mail service. Status 600 (Busy
- Everywhere) SHOULD be used if the client knows that no other end
- system will be able to accept this call.
-
-21.4.25 487 Request Terminated
-
- The request was terminated by a BYE or CANCEL request. This response
- is never returned for a CANCEL request itself.
-
-21.4.26 488 Not Acceptable Here
-
- The response has the same meaning as 606 (Not Acceptable), but only
- applies to the specific resource addressed by the Request-URI and the
- request may succeed elsewhere.
-
- A message body containing a description of media capabilities MAY be
- present in the response, which is formatted according to the Accept
- header field in the INVITE (or application/sdp if not present), the
- same as a message body in a 200 (OK) response to an OPTIONS request.
-
-21.4.27 491 Request Pending
-
- The request was received by a UAS that had a pending request within
- the same dialog. Section 14.2 describes how such "glare" situations
- are resolved.
-
-21.4.28 493 Undecipherable
-
- The request was received by a UAS that contained an encrypted MIME
- body for which the recipient does not possess or will not provide an
- appropriate decryption key. This response MAY have a single body
- containing an appropriate public key that should be used to encrypt
- MIME bodies sent to this UA. Details of the usage of this response
- code can be found in Section 23.2.
-
-21.5 Server Failure 5xx
-
- 5xx responses are failure responses given when a server itself has
- erred.
-
-21.5.1 500 Server Internal Error
-
- The server encountered an unexpected condition that prevented it from
- fulfilling the request. The client MAY display the specific error
- condition and MAY retry the request after several seconds.
-
- If the condition is temporary, the server MAY indicate when the
- client may retry the request using the Retry-After header field.
-
-
-
-Rosenberg, et. al. Standards Track [Page 190]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.5.2 501 Not Implemented
-
- The server does not support the functionality required to fulfill the
- request. This is the appropriate response when a UAS does not
- recognize the request method and is not capable of supporting it for
- any user. (Proxies forward all requests regardless of method.)
-
- Note that a 405 (Method Not Allowed) is sent when the server
- recognizes the request method, but that method is not allowed or
- supported.
-
-21.5.3 502 Bad Gateway
-
- The server, while acting as a gateway or proxy, received an invalid
- response from the downstream server it accessed in attempting to
- fulfill the request.
-
-21.5.4 503 Service Unavailable
-
- The server is temporarily unable to process the request due to a
- temporary overloading or maintenance of the server. The server MAY
- indicate when the client should retry the request in a Retry-After
- header field. If no Retry-After is given, the client MUST act as if
- it had received a 500 (Server Internal Error) response.
-
- A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
- attempt to forward the request to an alternate server. It SHOULD NOT
- forward any other requests to that server for the duration specified
- in the Retry-After header field, if present.
-
- Servers MAY refuse the connection or drop the request instead of
- responding with 503 (Service Unavailable).
-
-21.5.5 504 Server Time-out
-
- The server did not receive a timely response from an external server
- it accessed in attempting to process the request. 408 (Request
- Timeout) should be used instead if there was no response within the
- period specified in the Expires header field from the upstream
- server.
-
-21.5.6 505 Version Not Supported
-
- The server does not support, or refuses to support, the SIP protocol
- version that was used in the request. The server is indicating that
- it is unable or unwilling to complete the request using the same
- major version as the client, other than with this error message.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 191]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-21.5.7 513 Message Too Large
-
- The server was unable to process the request since the message length
- exceeded its capabilities.
-
-21.6 Global Failures 6xx
-
- 6xx responses indicate that a server has definitive information about
- a particular user, not just the particular instance indicated in the
- Request-URI.
-
-21.6.1 600 Busy Everywhere
-
- The callee's end system was contacted successfully but the callee is
- busy and does not wish to take the call at this time. The response
- MAY indicate a better time to call in the Retry-After header field.
- If the callee does not wish to reveal the reason for declining the
- call, the callee uses status code 603 (Decline) instead. This status
- response is returned only if the client knows that no other end point
- (such as a voice mail system) will answer the request. Otherwise,
- 486 (Busy Here) should be returned.
-
-21.6.2 603 Decline
-
- The callee's machine was successfully contacted but the user
- explicitly does not wish to or cannot participate. The response MAY
- indicate a better time to call in the Retry-After header field. This
- status response is returned only if the client knows that no other
- end point will answer the request.
-
-21.6.3 604 Does Not Exist Anywhere
-
- The server has authoritative information that the user indicated in
- the Request-URI does not exist anywhere.
-
-21.6.4 606 Not Acceptable
-
- The user's agent was contacted successfully but some aspects of the
- session description such as the requested media, bandwidth, or
- addressing style were not acceptable.
-
- A 606 (Not Acceptable) response means that the user wishes to
- communicate, but cannot adequately support the session described.
- The 606 (Not Acceptable) response MAY contain a list of reasons in a
- Warning header field describing why the session described cannot be
- supported. Warning reason codes are listed in Section 20.43.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 192]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- A message body containing a description of media capabilities MAY be
- present in the response, which is formatted according to the Accept
- header field in the INVITE (or application/sdp if not present), the
- same as a message body in a 200 (OK) response to an OPTIONS request.
-
- It is hoped that negotiation will not frequently be needed, and when
- a new user is being invited to join an already existing conference,
- negotiation may not be possible. It is up to the invitation
- initiator to decide whether or not to act on a 606 (Not Acceptable)
- response.
-
- This status response is returned only if the client knows that no
- other end point will answer the request.
-
-22 Usage of HTTP Authentication
-
- SIP provides a stateless, challenge-based mechanism for
- authentication that is based on authentication in HTTP. Any time
- that a proxy server or UA receives a request (with the exceptions
- given in Section 22.1), it MAY challenge the initiator of the request
- to provide assurance of its identity. Once the originator has been
- identified, the recipient of the request SHOULD ascertain whether or
- not this user is authorized to make the request in question. No
- authorization systems are recommended or discussed in this document.
-
- The "Digest" authentication mechanism described in this section
- provides message authentication and replay protection only, without
- message integrity or confidentiality. Protective measures above and
- beyond those provided by Digest need to be taken to prevent active
- attackers from modifying SIP requests and responses.
-
- Note that due to its weak security, the usage of "Basic"
- authentication has been deprecated. Servers MUST NOT accept
- credentials using the "Basic" authorization scheme, and servers also
- MUST NOT challenge with "Basic". This is a change from RFC 2543.
-
-22.1 Framework
-
- The framework for SIP authentication closely parallels that of HTTP
- (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param,
- challenge, realm, realm-value, and credentials is identical (although
- the usage of "Basic" as a scheme is not permitted). In SIP, a UAS
- uses the 401 (Unauthorized) response to challenge the identity of a
- UAC. Additionally, registrars and redirect servers MAY make use of
- 401 (Unauthorized) responses for authentication, but proxies MUST
- NOT, and instead MAY use the 407 (Proxy Authentication Required)
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 193]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- response. The requirements for inclusion of the Proxy-Authenticate,
- Proxy-Authorization, WWW-Authenticate, and Authorization in the
- various messages are identical to those described in RFC 2617 [17].
-
- Since SIP does not have the concept of a canonical root URL, the
- notion of protection spaces is interpreted differently in SIP. The
- realm string alone defines the protection domain. This is a change
- from RFC 2543, in which the Request-URI and the realm together
- defined the protection domain.
-
- This previous definition of protection domain caused some amount
- of confusion since the Request-URI sent by the UAC and the
- Request-URI received by the challenging server might be different,
- and indeed the final form of the Request-URI might not be known to
- the UAC. Also, the previous definition depended on the presence
- of a SIP URI in the Request-URI and seemed to rule out alternative
- URI schemes (for example, the tel URL).
-
- Operators of user agents or proxy servers that will authenticate
- received requests MUST adhere to the following guidelines for
- creation of a realm string for their server:
-
- o Realm strings MUST be globally unique. It is RECOMMENDED that
- a realm string contain a hostname or domain name, following the
- recommendation in Section 3.2.1 of RFC 2617 [17].
-
- o Realm strings SHOULD present a human-readable identifier that
- can be rendered to a user.
-
- For example:
-
- INVITE sip:bob@biloxi.com SIP/2.0
- Authorization: Digest realm="biloxi.com", <...>
-
- Generally, SIP authentication is meaningful for a specific realm, a
- protection domain. Thus, for Digest authentication, each such
- protection domain has its own set of usernames and passwords. If a
- server does not require authentication for a particular request, it
- MAY accept a default username, "anonymous", which has no password
- (password of ""). Similarly, UACs representing many users, such as
- PSTN gateways, MAY have their own device-specific username and
- password, rather than accounts for particular users, for their realm.
-
- While a server can legitimately challenge most SIP requests, there
- are two requests defined by this document that require special
- handling for authentication: ACK and CANCEL.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 194]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Under an authentication scheme that uses responses to carry values
- used to compute nonces (such as Digest), some problems come up for
- any requests that take no response, including ACK. For this reason,
- any credentials in the INVITE that were accepted by a server MUST be
- accepted by that server for the ACK. UACs creating an ACK message
- will duplicate all of the Authorization and Proxy-Authorization
- header field values that appeared in the INVITE to which the ACK
- corresponds. Servers MUST NOT attempt to challenge an ACK.
-
- Although the CANCEL method does take a response (a 2xx), servers MUST
- NOT attempt to challenge CANCEL requests since these requests cannot
- be resubmitted. Generally, a CANCEL request SHOULD be accepted by a
- server if it comes from the same hop that sent the request being
- canceled (provided that some sort of transport or network layer
- security association, as described in Section 26.2.1, is in place).
-
- When a UAC receives a challenge, it SHOULD render to the user the
- contents of the "realm" parameter in the challenge (which appears in
- either a WWW-Authenticate header field or Proxy-Authenticate header
- field) if the UAC device does not already know of a credential for
- the realm in question. A service provider that pre-configures UAs
- with credentials for its realm should be aware that users will not
- have the opportunity to present their own credentials for this realm
- when challenged at a pre-configured device.
-
- Finally, note that even if a UAC can locate credentials that are
- associated with the proper realm, the potential exists that these
- credentials may no longer be valid or that the challenging server
- will not accept these credentials for whatever reason (especially
- when "anonymous" with no password is submitted). In this instance a
- server may repeat its challenge, or it may respond with a 403
- Forbidden. A UAC MUST NOT re-attempt requests with the credentials
- that have just been rejected (though the request may be retried if
- the nonce was stale).
-
-22.2 User-to-User Authentication
-
- When a UAS receives a request from a UAC, the UAS MAY authenticate
- the originator before the request is processed. If no credentials
- (in the Authorization header field) are provided in the request, the
- UAS can challenge the originator to provide credentials by rejecting
- the request with a 401 (Unauthorized) status code.
-
- The WWW-Authenticate response-header field MUST be included in 401
- (Unauthorized) response messages. The field value consists of at
- least one challenge that indicates the authentication scheme(s) and
- parameters applicable to the realm.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 195]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- An example of the WWW-Authenticate header field in a 401 challenge
- is:
-
- WWW-Authenticate: Digest
- realm="biloxi.com",
- qop="auth,auth-int",
- nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
- opaque="5ccc069c403ebaf9f0171e9517f40e41"
-
- When the originating UAC receives the 401 (Unauthorized), it SHOULD,
- if it is able, re-originate the request with the proper credentials.
- The UAC may require input from the originating user before
- proceeding. Once authentication credentials have been supplied
- (either directly by the user, or discovered in an internal keyring),
- UAs SHOULD cache the credentials for a given value of the To header
- field and "realm" and attempt to re-use these values on the next
- request for that destination. UAs MAY cache credentials in any way
- they would like.
-
- If no credentials for a realm can be located, UACs MAY attempt to
- retry the request with a username of "anonymous" and no password (a
- password of "").
-
- Once credentials have been located, any UA that wishes to
- authenticate itself with a UAS or registrar -- usually, but not
- necessarily, after receiving a 401 (Unauthorized) response -- MAY do
- so by including an Authorization header field with the request. The
- Authorization field value consists of credentials containing the
- authentication information of the UA for the realm of the resource
- being requested as well as parameters required in support of
- authentication and replay protection.
-
- An example of the Authorization header field is:
-
- Authorization: Digest username="bob",
- realm="biloxi.com",
- nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
- uri="sip:bob@biloxi.com",
- qop=auth,
- nc=00000001,
- cnonce="0a4f113b",
- response="6629fae49393a05397450978507c4ef1",
- opaque="5ccc069c403ebaf9f0171e9517f40e41"
-
- When a UAC resubmits a request with its credentials after receiving a
- 401 (Unauthorized) or 407 (Proxy Authentication Required) response,
- it MUST increment the CSeq header field value as it would normally
- when sending an updated request.
-
-
-
-Rosenberg, et. al. Standards Track [Page 196]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-22.3 Proxy-to-User Authentication
-
- Similarly, when a UAC sends a request to a proxy server, the proxy
- server MAY authenticate the originator before the request is
- processed. If no credentials (in the Proxy-Authorization header
- field) are provided in the request, the proxy can challenge the
- originator to provide credentials by rejecting the request with a 407
- (Proxy Authentication Required) status code. The proxy MUST populate
- the 407 (Proxy Authentication Required) message with a Proxy-
- Authenticate header field value applicable to the proxy for the
- requested resource.
-
- The use of Proxy-Authenticate and Proxy-Authorization parallel that
- described in [17], with one difference. Proxies MUST NOT add values
- to the Proxy-Authorization header field. All 407 (Proxy
- Authentication Required) responses MUST be forwarded upstream toward
- the UAC following the procedures for any other response. It is the
- UAC's responsibility to add the Proxy-Authorization header field
- value containing credentials for the realm of the proxy that has
- asked for authentication.
-
- If a proxy were to resubmit a request adding a Proxy-Authorization
- header field value, it would need to increment the CSeq in the new
- request. However, this would cause the UAC that submitted the
- original request to discard a response from the UAS, as the CSeq
- value would be different.
-
- When the originating UAC receives the 407 (Proxy Authentication
- Required) it SHOULD, if it is able, re-originate the request with the
- proper credentials. It should follow the same procedures for the
- display of the "realm" parameter that are given above for responding
- to 401.
-
- If no credentials for a realm can be located, UACs MAY attempt to
- retry the request with a username of "anonymous" and no password (a
- password of "").
-
- The UAC SHOULD also cache the credentials used in the re-originated
- request.
-
- The following rule is RECOMMENDED for proxy credential caching:
-
- If a UA receives a Proxy-Authenticate header field value in a 401/407
- response to a request with a particular Call-ID, it should
- incorporate credentials for that realm in all subsequent requests
- that contain the same Call-ID. These credentials MUST NOT be cached
- across dialogs; however, if a UA is configured with the realm of its
- local outbound proxy, when one exists, then the UA MAY cache
-
-
-
-Rosenberg, et. al. Standards Track [Page 197]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- credentials for that realm across dialogs. Note that this does mean
- a future request in a dialog could contain credentials that are not
- needed by any proxy along the Route header path.
-
- Any UA that wishes to authenticate itself to a proxy server --
- usually, but not necessarily, after receiving a 407 (Proxy
- Authentication Required) response -- MAY do so by including a Proxy-
- Authorization header field value with the request. The Proxy-
- Authorization request-header field allows the client to identify
- itself (or its user) to a proxy that requires authentication. The
- Proxy-Authorization header field value consists of credentials
- containing the authentication information of the UA for the proxy
- and/or realm of the resource being requested.
-
- A Proxy-Authorization header field value applies only to the proxy
- whose realm is identified in the "realm" parameter (this proxy may
- previously have demanded authentication using the Proxy-Authenticate
- field). When multiple proxies are used in a chain, a Proxy-
- Authorization header field value MUST NOT be consumed by any proxy
- whose realm does not match the "realm" parameter specified in that
- value.
-
- Note that if an authentication scheme that does not support realms is
- used in the Proxy-Authorization header field, a proxy server MUST
- attempt to parse all Proxy-Authorization header field values to
- determine whether one of them has what the proxy server considers to
- be valid credentials. Because this is potentially very time-
- consuming in large networks, proxy servers SHOULD use an
- authentication scheme that supports realms in the Proxy-Authorization
- header field.
-
- If a request is forked (as described in Section 16.7), various proxy
- servers and/or UAs may wish to challenge the UAC. In this case, the
- forking proxy server is responsible for aggregating these challenges
- into a single response. Each WWW-Authenticate and Proxy-Authenticate
- value received in responses to the forked request MUST be placed into
- the single response that is sent by the forking proxy to the UA; the
- ordering of these header field values is not significant.
-
- When a proxy server issues a challenge in response to a request,
- it will not proxy the request until the UAC has retried the
- request with valid credentials. A forking proxy may forward a
- request simultaneously to multiple proxy servers that require
- authentication, each of which in turn will not forward the request
- until the originating UAC has authenticated itself in their
- respective realm. If the UAC does not provide credentials for
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 198]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- each challenge, the proxy servers that issued the challenges will
- not forward requests to the UA where the destination user might be
- located, and therefore, the virtues of forking are largely lost.
-
- When resubmitting its request in response to a 401 (Unauthorized) or
- 407 (Proxy Authentication Required) that contains multiple
- challenges, a UAC MAY include an Authorization value for each WWW-
- Authenticate value and a Proxy-Authorization value for each Proxy-
- Authenticate value for which the UAC wishes to supply a credential.
- As noted above, multiple credentials in a request SHOULD be
- differentiated by the "realm" parameter.
-
- It is possible for multiple challenges associated with the same realm
- to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication
- Required). This can occur, for example, when multiple proxies within
- the same administrative domain, which use a common realm, are reached
- by a forking request. When it retries a request, a UAC MAY therefore
- supply multiple credentials in Authorization or Proxy-Authorization
- header fields with the same "realm" parameter value. The same
- credentials SHOULD be used for the same realm.
-
-22.4 The Digest Authentication Scheme
-
- This section describes the modifications and clarifications required
- to apply the HTTP Digest authentication scheme to SIP. The SIP
- scheme usage is almost completely identical to that for HTTP [17].
-
- Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39],
- SIP servers supporting RFC 2617 MUST ensure they are backwards
- compatible with RFC 2069. Procedures for this backwards
- compatibility are specified in RFC 2617. Note, however, that SIP
- servers MUST NOT accept or request Basic authentication.
-
- The rules for Digest authentication follow those defined in [17],
- with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following
- differences:
-
- 1. The URI included in the challenge has the following BNF:
-
- URI = SIP-URI / SIPS-URI
-
- 2. The BNF in RFC 2617 has an error in that the 'uri' parameter
- of the Authorization header field for HTTP Digest
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 199]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- authentication is not enclosed in quotation marks. (The
- example in Section 3.5 of RFC 2617 is correct.) For SIP, the
- 'uri' MUST be enclosed in quotation marks.
-
- 3. The BNF for digest-uri-value is:
-
- digest-uri-value = Request-URI ; as defined in Section 25
-
- 4. The example procedure for choosing a nonce based on Etag does
- not work for SIP.
-
- 5. The text in RFC 2617 [17] regarding cache operation does not
- apply to SIP.
-
- 6. RFC 2617 [17] requires that a server check that the URI in the
- request line and the URI included in the Authorization header
- field point to the same resource. In a SIP context, these two
- URIs may refer to different users, due to forwarding at some
- proxy. Therefore, in SIP, a server MAY check that the
- Request-URI in the Authorization header field value
- corresponds to a user for whom the server is willing to accept
- forwarded or direct requests, but it is not necessarily a
- failure if the two fields are not equivalent.
-
- 7. As a clarification to the calculation of the A2 value for
- message integrity assurance in the Digest authentication
- scheme, implementers should assume, when the entity-body is
- empty (that is, when SIP messages have no body) that the hash
- of the entity-body resolves to the MD5 hash of an empty
- string, or:
-
- H(entity-body) = MD5("") =
- "d41d8cd98f00b204e9800998ecf8427e"
-
- 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an
- Authorization (and by extension Proxy-Authorization) header
- field if no qop directive has been sent. Therefore, any
- algorithms that have a dependency on the cnonce (including
- "MD5-Sess") require that the qop directive be sent. Use of
- the "qop" parameter is optional in RFC 2617 for the purposes
- of backwards compatibility with RFC 2069; since RFC 2543 was
- based on RFC 2069, the "qop" parameter must unfortunately
- remain optional for clients and servers to receive. However,
- servers MUST always send a "qop" parameter in WWW-Authenticate
- and Proxy-Authenticate header field values. If a client
- receives a "qop" parameter in a challenge header field, it
- MUST send the "qop" parameter in any resulting authorization
- header field.
-
-
-
-Rosenberg, et. al. Standards Track [Page 200]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- RFC 2543 did not allow usage of the Authentication-Info header field
- (it effectively used RFC 2069). However, we now allow usage of this
- header field, since it provides integrity checks over the bodies and
- provides mutual authentication. RFC 2617 [17] defines mechanisms for
- backwards compatibility using the qop attribute in the request.
- These mechanisms MUST be used by a server to determine if the client
- supports the new mechanisms in RFC 2617 that were not specified in
- RFC 2069.
-
-23 S/MIME
-
- SIP messages carry MIME bodies and the MIME standard includes
- mechanisms for securing MIME contents to ensure both integrity and
- confidentiality (including the 'multipart/signed' and
- 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23]
- and RFC 2633 [24]). Implementers should note, however, that there
- may be rare network intermediaries (not typical proxy servers) that
- rely on viewing or modifying the bodies of SIP messages (especially
- SDP), and that secure MIME may prevent these sorts of intermediaries
- from functioning.
-
- This applies particularly to certain types of firewalls.
-
- The PGP mechanism for encrypting the header fields and bodies of
- SIP messages described in RFC 2543 has been deprecated.
-
-23.1 S/MIME Certificates
-
- The certificates that are used to identify an end-user for the
- purposes of S/MIME differ from those used by servers in one important
- respect - rather than asserting that the identity of the holder
- corresponds to a particular hostname, these certificates assert that
- the holder is identified by an end-user address. This address is
- composed of the concatenation of the "userinfo" "@" and "domainname"
- portions of a SIP or SIPS URI (in other words, an email address of
- the form "bob@biloxi.com"), most commonly corresponding to a user's
- address-of-record.
-
- These certificates are also associated with keys that are used to
- sign or encrypt bodies of SIP messages. Bodies are signed with the
- private key of the sender (who may include their public key with the
- message as appropriate), but bodies are encrypted with the public key
- of the intended recipient. Obviously, senders must have
- foreknowledge of the public key of recipients in order to encrypt
- message bodies. Public keys can be stored within a UA on a virtual
- keyring.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 201]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Each user agent that supports S/MIME MUST contain a keyring
- specifically for end-users' certificates. This keyring should map
- between addresses of record and corresponding certificates. Over
- time, users SHOULD use the same certificate when they populate the
- originating URI of signaling (the From header field) with the same
- address-of-record.
-
- Any mechanisms depending on the existence of end-user certificates
- are seriously limited in that there is virtually no consolidated
- authority today that provides certificates for end-user applications.
- However, users SHOULD acquire certificates from known public
- certificate authorities. As an alternative, users MAY create self-
- signed certificates. The implications of self-signed certificates
- are explored further in Section 26.4.2. Implementations may also use
- pre-configured certificates in deployments in which a previous trust
- relationship exists between all SIP entities.
-
- Above and beyond the problem of acquiring an end-user certificate,
- there are few well-known centralized directories that distribute
- end-user certificates. However, the holder of a certificate SHOULD
- publish their certificate in any public directories as appropriate.
- Similarly, UACs SHOULD support a mechanism for importing (manually or
- automatically) certificates discovered in public directories
- corresponding to the target URIs of SIP requests.
-
-23.2 S/MIME Key Exchange
-
- SIP itself can also be used as a means to distribute public keys in
- the following manner.
-
- Whenever the CMS SignedData message is used in S/MIME for SIP, it
- MUST contain the certificate bearing the public key necessary to
- verify the signature.
-
- When a UAC sends a request containing an S/MIME body that initiates a
- dialog, or sends a non-INVITE request outside the context of a
- dialog, the UAC SHOULD structure the body as an S/MIME
- 'multipart/signed' CMS SignedData body. If the desired CMS service
- is EnvelopedData (and the public key of the target user is known),
- the UAC SHOULD send the EnvelopedData message encapsulated within a
- SignedData message.
-
- When a UAS receives a request containing an S/MIME CMS body that
- includes a certificate, the UAS SHOULD first validate the
- certificate, if possible, with any available root certificates for
- certificate authorities. The UAS SHOULD also determine the subject
- of the certificate (for S/MIME, the SubjectAltName will contain the
- appropriate identity) and compare this value to the From header field
-
-
-
-Rosenberg, et. al. Standards Track [Page 202]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- of the request. If the certificate cannot be verified, because it is
- self-signed, or signed by no known authority, or if it is verifiable
- but its subject does not correspond to the From header field of
- request, the UAS MUST notify its user of the status of the
- certificate (including the subject of the certificate, its signer,
- and any key fingerprint information) and request explicit permission
- before proceeding. If the certificate was successfully verified and
- the subject of the certificate corresponds to the From header field
- of the SIP request, or if the user (after notification) explicitly
- authorizes the use of the certificate, the UAS SHOULD add this
- certificate to a local keyring, indexed by the address-of-record of
- the holder of the certificate.
-
- When a UAS sends a response containing an S/MIME body that answers
- the first request in a dialog, or a response to a non-INVITE request
- outside the context of a dialog, the UAS SHOULD structure the body as
- an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS
- service is EnvelopedData, the UAS SHOULD send the EnvelopedData
- message encapsulated within a SignedData message.
-
- When a UAC receives a response containing an S/MIME CMS body that
- includes a certificate, the UAC SHOULD first validate the
- certificate, if possible, with any appropriate root certificate. The
- UAC SHOULD also determine the subject of the certificate and compare
- this value to the To field of the response; although the two may very
- well be different, and this is not necessarily indicative of a
- security breach. If the certificate cannot be verified because it is
- self-signed, or signed by no known authority, the UAC MUST notify its
- user of the status of the certificate (including the subject of the
- certificate, its signator, and any key fingerprint information) and
- request explicit permission before proceeding. If the certificate
- was successfully verified, and the subject of the certificate
- corresponds to the To header field in the response, or if the user
- (after notification) explicitly authorizes the use of the
- certificate, the UAC SHOULD add this certificate to a local keyring,
- indexed by the address-of-record of the holder of the certificate.
- If the UAC had not transmitted its own certificate to the UAS in any
- previous transaction, it SHOULD use a CMS SignedData body for its
- next request or response.
-
- On future occasions, when the UA receives requests or responses that
- contain a From header field corresponding to a value in its keyring,
- the UA SHOULD compare the certificate offered in these messages with
- the existing certificate in its keyring. If there is a discrepancy,
- the UA MUST notify its user of a change of the certificate
- (preferably in terms that indicate that this is a potential security
- breach) and acquire the user's permission before continuing to
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 203]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- process the signaling. If the user authorizes this certificate, it
- SHOULD be added to the keyring alongside any previous value(s) for
- this address-of-record.
-
- Note well however, that this key exchange mechanism does not
- guarantee the secure exchange of keys when self-signed certificates,
- or certificates signed by an obscure authority, are used - it is
- vulnerable to well-known attacks. In the opinion of the authors,
- however, the security it provides is proverbially better than
- nothing; it is in fact comparable to the widely used SSH application.
- These limitations are explored in greater detail in Section 26.4.2.
-
- If a UA receives an S/MIME body that has been encrypted with a public
- key unknown to the recipient, it MUST reject the request with a 493
- (Undecipherable) response. This response SHOULD contain a valid
- certificate for the respondent (corresponding, if possible, to any
- address of record given in the To header field of the rejected
- request) within a MIME body with a 'certs-only' "smime-type"
- parameter.
-
- A 493 (Undecipherable) sent without any certificate indicates that
- the respondent cannot or will not utilize S/MIME encrypted messages,
- though they may still support S/MIME signatures.
-
- Note that a user agent that receives a request containing an S/MIME
- body that is not optional (with a Content-Disposition header
- "handling" parameter of "required") MUST reject the request with a
- 415 Unsupported Media Type response if the MIME type is not
- understood. A user agent that receives such a response when S/MIME
- is sent SHOULD notify its user that the remote device does not
- support S/MIME, and it MAY subsequently resend the request without
- S/MIME, if appropriate; however, this 415 response may constitute a
- downgrade attack.
-
- If a user agent sends an S/MIME body in a request, but receives a
- response that contains a MIME body that is not secured, the UAC
- SHOULD notify its user that the session could not be secured.
- However, if a user agent that supports S/MIME receives a request with
- an unsecured body, it SHOULD NOT respond with a secured body, but if
- it expects S/MIME from the sender (for example, because the sender's
- From header field value corresponds to an identity on its keychain),
- the UAS SHOULD notify its user that the session could not be secured.
-
- A number of conditions that arise in the previous text call for the
- notification of the user when an anomalous certificate-management
- event occurs. Users might well ask what they should do under these
- circumstances. First and foremost, an unexpected change in a
- certificate, or an absence of security when security is expected, are
-
-
-
-Rosenberg, et. al. Standards Track [Page 204]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- causes for caution but not necessarily indications that an attack is
- in progress. Users might abort any connection attempt or refuse a
- connection request they have received; in telephony parlance, they
- could hang up and call back. Users may wish to find an alternate
- means to contact the other party and confirm that their key has
- legitimately changed. Note that users are sometimes compelled to
- change their certificates, for example when they suspect that the
- secrecy of their private key has been compromised. When their
- private key is no longer private, users must legitimately generate a
- new key and re-establish trust with any users that held their old
- key.
-
- Finally, if during the course of a dialog a UA receives a certificate
- in a CMS SignedData message that does not correspond with the
- certificates previously exchanged during a dialog, the UA MUST notify
- its user of the change, preferably in terms that indicate that this
- is a potential security breach.
-
-23.3 Securing MIME bodies
-
- There are two types of secure MIME bodies that are of interest to
- SIP: use of these bodies should follow the S/MIME specification [24]
- with a few variations.
-
- o "multipart/signed" MUST be used only with CMS detached
- signatures.
-
- This allows backwards compatibility with non-S/MIME-
- compliant recipients.
-
- o S/MIME bodies SHOULD have a Content-Disposition header field,
- and the value of the "handling" parameter SHOULD be "required."
-
- o If a UAC has no certificate on its keyring associated with the
- address-of-record to which it wants to send a request, it
- cannot send an encrypted "application/pkcs7-mime" MIME message.
- UACs MAY send an initial request such as an OPTIONS message
- with a CMS detached signature in order to solicit the
- certificate of the remote side (the signature SHOULD be over a
- "message/sip" body of the type described in Section 23.4).
-
- Note that future standardization work on S/MIME may define
- non-certificate based keys.
-
- o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities"
- (see Section 2.5.2 of [24]) attribute to express their
- capabilities and preferences for further communications. Note
- especially that senders MAY use the "preferSignedData"
-
-
-
-Rosenberg, et. al. Standards Track [Page 205]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- capability to encourage receivers to respond with CMS
- SignedData messages (for example, when sending an OPTIONS
- request as described above).
-
- o S/MIME implementations MUST at a minimum support SHA1 as a
- digital signature algorithm, and 3DES as an encryption
- algorithm. All other signature and encryption algorithms MAY
- be supported. Implementations can negotiate support for these
- algorithms with the "SMIMECapabilities" attribute.
-
- o Each S/MIME body in a SIP message SHOULD be signed with only
- one certificate. If a UA receives a message with multiple
- signatures, the outermost signature should be treated as the
- single certificate for this body. Parallel signatures SHOULD
- NOT be used.
-
- The following is an example of an encrypted S/MIME SDP body
- within a SIP message:
-
- INVITE sip:bob@biloxi.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- To: Bob <sip:bob@biloxi.com>
- From: Alice <sip:alice@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710
- CSeq: 314159 INVITE
- Max-Forwards: 70
- Contact: <sip:alice@pc33.atlanta.com>
- Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
- name=smime.p7m
- Content-Disposition: attachment; filename=smime.p7m
- handling=required
-
- *******************************************************
- * Content-Type: application/sdp *
- * *
- * v=0 *
- * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
- * s=- *
- * t=0 0 *
- * c=IN IP4 pc33.atlanta.com *
- * m=audio 3456 RTP/AVP 0 1 3 99 *
- * a=rtpmap:0 PCMU/8000 *
- *******************************************************
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 206]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP
-
- As a means of providing some degree of end-to-end authentication,
- integrity or confidentiality for SIP header fields, S/MIME can
- encapsulate entire SIP messages within MIME bodies of type
- "message/sip" and then apply MIME security to these bodies in the
- same manner as typical SIP bodies. These encapsulated SIP requests
- and responses do not constitute a separate dialog or transaction,
- they are a copy of the "outer" message that is used to verify
- integrity or to supply additional information.
-
- If a UAS receives a request that contains a tunneled "message/sip"
- S/MIME body, it SHOULD include a tunneled "message/sip" body in the
- response with the same smime-type.
-
- Any traditional MIME bodies (such as SDP) SHOULD be attached to the
- "inner" message so that they can also benefit from S/MIME security.
- Note that "message/sip" bodies can be sent as a part of a MIME
- "multipart/mixed" body if any unsecured MIME types should also be
- transmitted in a request.
-
-23.4.1 Integrity and Confidentiality Properties of SIP Headers
-
- When the S/MIME integrity or confidentiality mechanisms are used,
- there may be discrepancies between the values in the "inner" message
- and values in the "outer" message. The rules for handling any such
- differences for all of the header fields described in this document
- are given in this section.
-
- Note that for the purposes of loose timestamping, all SIP messages
- that tunnel "message/sip" SHOULD contain a Date header in both the
- "inner" and "outer" headers.
-
-23.4.1.1 Integrity
-
- Whenever integrity checks are performed, the integrity of a header
- field should be determined by matching the value of the header field
- in the signed body with that in the "outer" messages using the
- comparison rules of SIP as described in 20.
-
- Header fields that can be legitimately modified by proxy servers are:
- Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
- Authorization. If these header fields are not intact end-to-end,
- implementations SHOULD NOT consider this a breach of security.
- Changes to any other header fields defined in this document
- constitute an integrity violation; users MUST be notified of a
- discrepancy.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 207]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-23.4.1.2 Confidentiality
-
- When messages are encrypted, header fields may be included in the
- encrypted body that are not present in the "outer" message.
-
- Some header fields must always have a plaintext version because they
- are required header fields in requests and responses - these include:
-
- To, From, Call-ID, CSeq, Contact. While it is probably not useful to
- provide an encrypted alternative for the Call-ID, CSeq, or Contact,
- providing an alternative to the information in the "outer" To or From
- is permitted. Note that the values in an encrypted body are not used
- for the purposes of identifying transactions or dialogs - they are
- merely informational. If the From header field in an encrypted body
- differs from the value in the "outer" message, the value within the
- encrypted body SHOULD be displayed to the user, but MUST NOT be used
- in the "outer" header fields of any future messages.
-
- Primarily, a user agent will want to encrypt header fields that have
- an end-to-end semantic, including: Subject, Reply-To, Organization,
- Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info,
- Authentication-Info, Expires, In-Reply-To, Require, Supported,
- Unsupported, Retry-After, User-Agent, Server, and Warning. If any of
- these header fields are present in an encrypted body, they should be
- used instead of any "outer" header fields, whether this entails
- displaying the header field values to users or setting internal
- states in the UA. They SHOULD NOT however be used in the "outer"
- headers of any future messages.
-
- If present, the Date header field MUST always be the same in the
- "inner" and "outer" headers.
-
- Since MIME bodies are attached to the "inner" message,
- implementations will usually encrypt MIME-specific header fields,
- including: MIME-Version, Content-Type, Content-Length, Content-
- Language, Content-Encoding and Content-Disposition. The "outer"
- message will have the proper MIME header fields for S/MIME bodies.
- These header fields (and any MIME bodies they preface) should be
- treated as normal MIME header fields and bodies received in a SIP
- message.
-
- It is not particularly useful to encrypt the following header fields:
- Min-Expires, Timestamp, Authorization, Priority, and WWW-
- Authenticate. This category also includes those header fields that
- can be changed by proxy servers (described in the preceding section).
- UAs SHOULD never include these in an "inner" message if they are not
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 208]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- included in the "outer" message. UAs that receive any of these
- header fields in an encrypted body SHOULD ignore the encrypted
- values.
-
- Note that extensions to SIP may define additional header fields; the
- authors of these extensions should describe the integrity and
- confidentiality properties of such header fields. If a SIP UA
- encounters an unknown header field with an integrity violation, it
- MUST ignore the header field.
-
-23.4.2 Tunneling Integrity and Authentication
-
- Tunneling SIP messages within S/MIME bodies can provide integrity for
- SIP header fields if the header fields that the sender wishes to
- secure are replicated in a "message/sip" MIME body signed with a CMS
- detached signature.
-
- Provided that the "message/sip" body contains at least the
- fundamental dialog identifiers (To, From, Call-ID, CSeq), then a
- signed MIME body can provide limited authentication. At the very
- least, if the certificate used to sign the body is unknown to the
- recipient and cannot be verified, the signature can be used to
- ascertain that a later request in a dialog was transmitted by the
- same certificate-holder that initiated the dialog. If the recipient
- of the signed MIME body has some stronger incentive to trust the
- certificate (they were able to validate it, they acquired it from a
- trusted repository, or they have used it frequently) then the
- signature can be taken as a stronger assertion of the identity of the
- subject of the certificate.
-
- In order to eliminate possible confusions about the addition or
- subtraction of entire header fields, senders SHOULD replicate all
- header fields from the request within the signed body. Any message
- bodies that require integrity protection MUST be attached to the
- "inner" message.
-
- If a Date header is present in a message with a signed body, the
- recipient SHOULD compare the header field value with its own internal
- clock, if applicable. If a significant time discrepancy is detected
- (on the order of an hour or more), the user agent SHOULD alert the
- user to the anomaly, and note that it is a potential security breach.
-
- If an integrity violation in a message is detected by its recipient,
- the message MAY be rejected with a 403 (Forbidden) response if it is
- a request, or any existing dialog MAY be terminated. UAs SHOULD
- notify users of this circumstance and request explicit guidance on
- how to proceed.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 209]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The following is an example of the use of a tunneled "message/sip"
- body:
-
- INVITE sip:bob@biloxi.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- To: Bob <sip:bob@biloxi.com>
- From: Alice <sip:alice@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710
- CSeq: 314159 INVITE
- Max-Forwards: 70
- Date: Thu, 21 Feb 2002 13:02:03 GMT
- Contact: <sip:alice@pc33.atlanta.com>
- Content-Type: multipart/signed;
- protocol="application/pkcs7-signature";
- micalg=sha1; boundary=boundary42
- Content-Length: 568
-
- --boundary42
- Content-Type: message/sip
-
- INVITE sip:bob@biloxi.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- To: Bob <bob@biloxi.com>
- From: Alice <alice@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710
- CSeq: 314159 INVITE
- Max-Forwards: 70
- Date: Thu, 21 Feb 2002 13:02:03 GMT
- Contact: <sip:alice@pc33.atlanta.com>
- Content-Type: application/sdp
- Content-Length: 147
-
- v=0
- o=UserA 2890844526 2890844526 IN IP4 here.com
- s=Session SDP
- c=IN IP4 pc33.atlanta.com
- t=0 0
- m=audio 49172 RTP/AVP 0
- a=rtpmap:0 PCMU/8000
-
- --boundary42
- Content-Type: application/pkcs7-signature; name=smime.p7s
- Content-Transfer-Encoding: base64
- Content-Disposition: attachment; filename=smime.p7s;
- handling=required
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 210]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
- 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
- n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
- 7GhIGfHfYT64VQbnj756
-
- --boundary42-
-
-23.4.3 Tunneling Encryption
-
- It may also be desirable to use this mechanism to encrypt a
- "message/sip" MIME body within a CMS EnvelopedData message S/MIME
- body, but in practice, most header fields are of at least some use to
- the network; the general use of encryption with S/MIME is to secure
- message bodies like SDP rather than message headers. Some
- informational header fields, such as the Subject or Organization
- could perhaps warrant end-to-end security. Headers defined by future
- SIP applications might also require obfuscation.
-
- Another possible application of encrypting header fields is selective
- anonymity. A request could be constructed with a From header field
- that contains no personal information (for example,
- sip:anonymous@anonymizer.invalid). However, a second From header
- field containing the genuine address-of-record of the originator
- could be encrypted within a "message/sip" MIME body where it will
- only be visible to the endpoints of a dialog.
-
- Note that if this mechanism is used for anonymity, the From header
- field will no longer be usable by the recipient of a message as an
- index to their certificate keychain for retrieving the proper
- S/MIME key to associated with the sender. The message must first
- be decrypted, and the "inner" From header field MUST be used as an
- index.
-
- In order to provide end-to-end integrity, encrypted "message/sip"
- MIME bodies SHOULD be signed by the sender. This creates a
- "multipart/signed" MIME body that contains an encrypted body and a
- signature, both of type "application/pkcs7-mime".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 211]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- In the following example, of an encrypted and signed message, the
- text boxed in asterisks ("*") is encrypted:
-
- INVITE sip:bob@biloxi.com SIP/2.0
- Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- To: Bob <sip:bob@biloxi.com>
- From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
- Call-ID: a84b4c76e66710
- CSeq: 314159 INVITE
- Max-Forwards: 70
- Date: Thu, 21 Feb 2002 13:02:03 GMT
- Contact: <sip:pc33.atlanta.com>
- Content-Type: multipart/signed;
- protocol="application/pkcs7-signature";
- micalg=sha1; boundary=boundary42
- Content-Length: 568
-
- --boundary42
- Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
- name=smime.p7m
- Content-Transfer-Encoding: base64
- Content-Disposition: attachment; filename=smime.p7m
- handling=required
- Content-Length: 231
-
- ***********************************************************
- * Content-Type: message/sip *
- * *
- * INVITE sip:bob@biloxi.com SIP/2.0 *
- * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
- * To: Bob <bob@biloxi.com> *
- * From: Alice <alice@atlanta.com>;tag=1928301774 *
- * Call-ID: a84b4c76e66710 *
- * CSeq: 314159 INVITE *
- * Max-Forwards: 70 *
- * Date: Thu, 21 Feb 2002 13:02:03 GMT *
- * Contact: <sip:alice@pc33.atlanta.com> *
- * *
- * Content-Type: application/sdp *
- * *
- * v=0 *
- * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
- * s=Session SDP *
- * t=0 0 *
- * c=IN IP4 pc33.atlanta.com *
- * m=audio 3456 RTP/AVP 0 1 3 99 *
- * a=rtpmap:0 PCMU/8000 *
- ***********************************************************
-
-
-
-Rosenberg, et. al. Standards Track [Page 212]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- --boundary42
- Content-Type: application/pkcs7-signature; name=smime.p7s
- Content-Transfer-Encoding: base64
- Content-Disposition: attachment; filename=smime.p7s;
- handling=required
-
- ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
- 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
- n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
- 7GhIGfHfYT64VQbnj756
-
- --boundary42-
-
-24 Examples
-
- In the following examples, we often omit the message body and the
- corresponding Content-Length and Content-Type header fields for
- brevity.
-
-24.1 Registration
-
- Bob registers on start-up. The message flow is shown in Figure 9.
- Note that the authentication usually required for registration is not
- shown for simplicity.
-
- biloxi.com Bob's
- registrar softphone
- | |
- | REGISTER F1 |
- |<---------------|
- | 200 OK F2 |
- |--------------->|
-
- Figure 9: SIP Registration Example
-
- F1 REGISTER Bob -> Registrar
-
- REGISTER sip:registrar.biloxi.com SIP/2.0
- Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
- Max-Forwards: 70
- To: Bob <sip:bob@biloxi.com>
- From: Bob <sip:bob@biloxi.com>;tag=456248
- Call-ID: 843817637684230@998sdasdh09
- CSeq: 1826 REGISTER
- Contact: <sip:bob@192.0.2.4>
- Expires: 7200
- Content-Length: 0
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 213]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The registration expires after two hours. The registrar responds
- with a 200 OK:
-
- F2 200 OK Registrar -> Bob
-
- SIP/2.0 200 OK
- Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
- ;received=192.0.2.4
- To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
- From: Bob <sip:bob@biloxi.com>;tag=456248
- Call-ID: 843817637684230@998sdasdh09
- CSeq: 1826 REGISTER
- Contact: <sip:bob@192.0.2.4>
- Expires: 7200
- Content-Length: 0
-
-24.2 Session Setup
-
- This example contains the full details of the example session setup
- in Section 4. The message flow is shown in Figure 1. Note that
- these flows show the minimum required set of header fields - some
- other header fields such as Allow and Supported would normally be
- present.
-
-F1 INVITE Alice -> atlanta.com proxy
-
-INVITE sip:bob@biloxi.com SIP/2.0
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
-Max-Forwards: 70
-To: Bob <sip:bob@biloxi.com>
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Contact: <sip:alice@pc33.atlanta.com>
-Content-Type: application/sdp
-Content-Length: 142
-
-(Alice's SDP not shown)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 214]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-F2 100 Trying atlanta.com proxy -> Alice
-
-SIP/2.0 100 Trying
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Content-Length: 0
-
-F3 INVITE atlanta.com proxy -> biloxi.com proxy
-
-INVITE sip:bob@biloxi.com SIP/2.0
-Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-Max-Forwards: 69
-To: Bob <sip:bob@biloxi.com>
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Contact: <sip:alice@pc33.atlanta.com>
-Content-Type: application/sdp
-Content-Length: 142
-
-(Alice's SDP not shown)
-
-F4 100 Trying biloxi.com proxy -> atlanta.com proxy
-
-SIP/2.0 100 Trying
-Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
- ;received=192.0.2.2
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Content-Length: 0
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 215]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-F5 INVITE biloxi.com proxy -> Bob
-
-INVITE sip:bob@192.0.2.4 SIP/2.0
-Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
-Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
- ;received=192.0.2.2
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-Max-Forwards: 68
-To: Bob <sip:bob@biloxi.com>
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Contact: <sip:alice@pc33.atlanta.com>
-Content-Type: application/sdp
-Content-Length: 142
-
-(Alice's SDP not shown)
-
-F6 180 Ringing Bob -> biloxi.com proxy
-
-SIP/2.0 180 Ringing
-Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
- ;received=192.0.2.3
-Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
- ;received=192.0.2.2
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-Contact: <sip:bob@192.0.2.4>
-CSeq: 314159 INVITE
-Content-Length: 0
-
-F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
-
-SIP/2.0 180 Ringing
-Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
- ;received=192.0.2.2
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-Contact: <sip:bob@192.0.2.4>
-CSeq: 314159 INVITE
-Content-Length: 0
-
-
-
-Rosenberg, et. al. Standards Track [Page 216]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-F8 180 Ringing atlanta.com proxy -> Alice
-
-SIP/2.0 180 Ringing
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-Contact: <sip:bob@192.0.2.4>
-CSeq: 314159 INVITE
-Content-Length: 0
-
-F9 200 OK Bob -> biloxi.com proxy
-
-SIP/2.0 200 OK
-Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
- ;received=192.0.2.3
-Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
- ;received=192.0.2.2
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Contact: <sip:bob@192.0.2.4>
-Content-Type: application/sdp
-Content-Length: 131
-
-(Bob's SDP not shown)
-
-F10 200 OK biloxi.com proxy -> atlanta.com proxy
-
-SIP/2.0 200 OK
-Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
- ;received=192.0.2.2
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Contact: <sip:bob@192.0.2.4>
-Content-Type: application/sdp
-Content-Length: 131
-
-(Bob's SDP not shown)
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 217]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-F11 200 OK atlanta.com proxy -> Alice
-
-SIP/2.0 200 OK
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
- ;received=192.0.2.1
-To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 INVITE
-Contact: <sip:bob@192.0.2.4>
-Content-Type: application/sdp
-Content-Length: 131
-
-(Bob's SDP not shown)
-
-F12 ACK Alice -> Bob
-
-ACK sip:bob@192.0.2.4 SIP/2.0
-Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
-Max-Forwards: 70
-To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-From: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 314159 ACK
-Content-Length: 0
-
- The media session between Alice and Bob is now established.
-
- Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq
- numbering space, which, in this example, begins with 231. Since Bob
- is making the request, the To and From URIs and tags have been
- swapped.
-
-F13 BYE Bob -> Alice
-
-BYE sip:alice@pc33.atlanta.com SIP/2.0
-Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
-Max-Forwards: 70
-From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-To: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 231 BYE
-Content-Length: 0
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 218]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-F14 200 OK Alice -> Bob
-
-SIP/2.0 200 OK
-Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
-From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
-To: Alice <sip:alice@atlanta.com>;tag=1928301774
-Call-ID: a84b4c76e66710
-CSeq: 231 BYE
-Content-Length: 0
-
- The SIP Call Flows document [40] contains further examples of SIP
- messages.
-
-25 Augmented BNF for the SIP Protocol
-
- All of the mechanisms specified in this document are described in
- both prose and an augmented Backus-Naur Form (BNF) defined in RFC
- 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that
- are used by this specification, and not repeated here. Implementers
- need to be familiar with the notation and content of RFC 2234 in
- order to understand this specification. Certain basic rules are in
- uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle
- brackets are used within definitions to clarify the use of rule
- names.
-
- The use of square brackets is redundant syntactically. It is used as
- a semantic hint that the specific parameter is optional to use.
-
-25.1 Basic Rules
-
- The following rules are used throughout this specification to
- describe basic parsing constructs. The US-ASCII coded character set
- is defined by ANSI X3.4-1986.
-
- alphanum = ALPHA / DIGIT
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 219]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Several rules are incorporated from RFC 2396 [5] but are updated to
- make them compliant with RFC 2234 [10]. These include:
-
- reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
- / "$" / ","
- unreserved = alphanum / mark
- mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
- / "(" / ")"
- escaped = "%" HEXDIG HEXDIG
-
- SIP header field values can be folded onto multiple lines if the
- continuation line begins with a space or horizontal tab. All linear
- white space, including folding, has the same semantics as SP. A
- recipient MAY replace any linear white space with a single SP before
- interpreting the field value or forwarding the message downstream.
- This is intended to behave exactly as HTTP/1.1 as described in RFC
- 2616 [8]. The SWS construct is used when linear white space is
- optional, generally between tokens and separators.
-
- LWS = [*WSP CRLF] 1*WSP ; linear whitespace
- SWS = [LWS] ; sep whitespace
-
- To separate the header name from the rest of value, a colon is used,
- which, by the above rule, allows whitespace before, but no line
- break, and whitespace after, including a linebreak. The HCOLON
- defines this construct.
-
- HCOLON = *( SP / HTAB ) ":" SWS
-
- The TEXT-UTF8 rule is only used for descriptive field contents and
- values that are not intended to be interpreted by the message parser.
- Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC
- 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field
- contents that are n t quoted strings, where leading and trailing LWS
- is not meaningful. In this regard, SIP differs from HTTP, which uses
- the ISO 8859-1 character set.
-
- TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
- TEXT-UTF8char = %x21-7E / UTF8-NONASCII
- UTF8-NONASCII = %xC0-DF 1UTF8-CONT
- / %xE0-EF 2UTF8-CONT
- / %xF0-F7 3UTF8-CONT
- / %xF8-Fb 4UTF8-CONT
- / %xFC-FD 5UTF8-CONT
- UTF8-CONT = %x80-BF
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 220]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of
- a header field continuation. It is expected that the folding LWS
- will be replaced with a single SP before interpretation of the TEXT-
- UTF8-TRIM value.
-
- Hexadecimal numeric characters are used in several protocol elements.
- Some elements (authentication) force hex alphas to be lower case.
-
- LHEX = DIGIT / %x61-66 ;lowercase a-f
-
- Many SIP header field values consist of words separated by LWS or
- special characters. Unless otherwise stated, tokens are case-
- insensitive. These special characters MUST be in a quoted string to
- be used within a parameter value. The word construct is used in
- Call-ID to allow most separators to be used.
-
- token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
- / "_" / "+" / "`" / "'" / "~" )
- separators = "(" / ")" / "<" / ">" / "@" /
- "," / ";" / ":" / "\" / DQUOTE /
- "/" / "[" / "]" / "?" / "=" /
- "{" / "}" / SP / HTAB
- word = 1*(alphanum / "-" / "." / "!" / "%" / "*" /
- "_" / "+" / "`" / "'" / "~" /
- "(" / ")" / "<" / ">" /
- ":" / "\" / DQUOTE /
- "/" / "[" / "]" / "?" /
- "{" / "}" )
-
- When tokens are used or separators are used between elements,
- whitespace is often allowed before or after these characters:
-
- STAR = SWS "*" SWS ; asterisk
- SLASH = SWS "/" SWS ; slash
- EQUAL = SWS "=" SWS ; equal
- LPAREN = SWS "(" SWS ; left parenthesis
- RPAREN = SWS ")" SWS ; right parenthesis
- RAQUOT = ">" SWS ; right angle quote
- LAQUOT = SWS "<"; left angle quote
- COMMA = SWS "," SWS ; comma
- SEMI = SWS ";" SWS ; semicolon
- COLON = SWS ":" SWS ; colon
- LDQUOT = SWS DQUOTE; open double quotation mark
- RDQUOT = DQUOTE SWS ; close double quotation mark
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 221]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Comments can be included in some SIP header fields by surrounding the
- comment text with parentheses. Comments are only allowed in fields
- containing "comment" as part of their field value definition. In all
- other fields, parentheses are considered part of the field value.
-
- comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
- ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII
- / LWS
-
- ctext includes all chars except left and right parens and backslash.
- A string of text is parsed as a single word if it is quoted using
- double-quote marks. In quoted strings, quotation marks (") and
- backslashes (\) need to be escaped.
-
- quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
- qdtext = LWS / %x21 / %x23-5B / %x5D-7E
- / UTF8-NONASCII
-
- The backslash character ("\") MAY be used as a single-character
- quoting mechanism only within quoted-string and comment constructs.
- Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this
- mechanism to avoid conflict with line folding and header separation.
-
-quoted-pair = "\" (%x00-09 / %x0B-0C
- / %x0E-7F)
-
-SIP-URI = "sip:" [ userinfo ] hostport
- uri-parameters [ headers ]
-SIPS-URI = "sips:" [ userinfo ] hostport
- uri-parameters [ headers ]
-userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
-user = 1*( unreserved / escaped / user-unreserved )
-user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
-password = *( unreserved / escaped /
- "&" / "=" / "+" / "$" / "," )
-hostport = host [ ":" port ]
-host = hostname / IPv4address / IPv6reference
-hostname = *( domainlabel "." ) toplabel [ "." ]
-domainlabel = alphanum
- / alphanum *( alphanum / "-" ) alphanum
-toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 222]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
-IPv6reference = "[" IPv6address "]"
-IPv6address = hexpart [ ":" IPv4address ]
-hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
-hexseq = hex4 *( ":" hex4)
-hex4 = 1*4HEXDIG
-port = 1*DIGIT
-
- The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note,
- however, that any characters allowed there that are not allowed in
- the user part of the SIP URI MUST be escaped.
-
-uri-parameters = *( ";" uri-parameter)
-uri-parameter = transport-param / user-param / method-param
- / ttl-param / maddr-param / lr-param / other-param
-transport-param = "transport="
- ( "udp" / "tcp" / "sctp" / "tls"
- / other-transport)
-other-transport = token
-user-param = "user=" ( "phone" / "ip" / other-user)
-other-user = token
-method-param = "method=" Method
-ttl-param = "ttl=" ttl
-maddr-param = "maddr=" host
-lr-param = "lr"
-other-param = pname [ "=" pvalue ]
-pname = 1*paramchar
-pvalue = 1*paramchar
-paramchar = param-unreserved / unreserved / escaped
-param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
-
-headers = "?" header *( "&" header )
-header = hname "=" hvalue
-hname = 1*( hnv-unreserved / unreserved / escaped )
-hvalue = *( hnv-unreserved / unreserved / escaped )
-hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$"
-
-SIP-message = Request / Response
-Request = Request-Line
- *( message-header )
- CRLF
- [ message-body ]
-Request-Line = Method SP Request-URI SP SIP-Version CRLF
-Request-URI = SIP-URI / SIPS-URI / absoluteURI
-absoluteURI = scheme ":" ( hier-part / opaque-part )
-hier-part = ( net-path / abs-path ) [ "?" query ]
-net-path = "//" authority [ abs-path ]
-abs-path = "/" path-segments
-
-
-
-Rosenberg, et. al. Standards Track [Page 223]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-opaque-part = uric-no-slash *uric
-uric = reserved / unreserved / escaped
-uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@"
- / "&" / "=" / "+" / "$" / ","
-path-segments = segment *( "/" segment )
-segment = *pchar *( ";" param )
-param = *pchar
-pchar = unreserved / escaped /
- ":" / "@" / "&" / "=" / "+" / "$" / ","
-scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
-authority = srvr / reg-name
-srvr = [ [ userinfo "@" ] hostport ]
-reg-name = 1*( unreserved / escaped / "$" / ","
- / ";" / ":" / "@" / "&" / "=" / "+" )
-query = *uric
-SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT
-
-message-header = (Accept
- / Accept-Encoding
- / Accept-Language
- / Alert-Info
- / Allow
- / Authentication-Info
- / Authorization
- / Call-ID
- / Call-Info
- / Contact
- / Content-Disposition
- / Content-Encoding
- / Content-Language
- / Content-Length
- / Content-Type
- / CSeq
- / Date
- / Error-Info
- / Expires
- / From
- / In-Reply-To
- / Max-Forwards
- / MIME-Version
- / Min-Expires
- / Organization
- / Priority
- / Proxy-Authenticate
- / Proxy-Authorization
- / Proxy-Require
- / Record-Route
- / Reply-To
-
-
-
-Rosenberg, et. al. Standards Track [Page 224]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- / Require
- / Retry-After
- / Route
- / Server
- / Subject
- / Supported
- / Timestamp
- / To
- / Unsupported
- / User-Agent
- / Via
- / Warning
- / WWW-Authenticate
- / extension-header) CRLF
-
-INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps
-ACKm = %x41.43.4B ; ACK in caps
-OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
-BYEm = %x42.59.45 ; BYE in caps
-CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps
-REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps
-Method = INVITEm / ACKm / OPTIONSm / BYEm
- / CANCELm / REGISTERm
- / extension-method
-extension-method = token
-Response = Status-Line
- *( message-header )
- CRLF
- [ message-body ]
-
-Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
-Status-Code = Informational
- / Redirection
- / Success
- / Client-Error
- / Server-Error
- / Global-Failure
- / extension-code
-extension-code = 3DIGIT
-Reason-Phrase = *(reserved / unreserved / escaped
- / UTF8-NONASCII / UTF8-CONT / SP / HTAB)
-
-Informational = "100" ; Trying
- / "180" ; Ringing
- / "181" ; Call Is Being Forwarded
- / "182" ; Queued
- / "183" ; Session Progress
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 225]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Success = "200" ; OK
-
-Redirection = "300" ; Multiple Choices
- / "301" ; Moved Permanently
- / "302" ; Moved Temporarily
- / "305" ; Use Proxy
- / "380" ; Alternative Service
-
-Client-Error = "400" ; Bad Request
- / "401" ; Unauthorized
- / "402" ; Payment Required
- / "403" ; Forbidden
- / "404" ; Not Found
- / "405" ; Method Not Allowed
- / "406" ; Not Acceptable
- / "407" ; Proxy Authentication Required
- / "408" ; Request Timeout
- / "410" ; Gone
- / "413" ; Request Entity Too Large
- / "414" ; Request-URI Too Large
- / "415" ; Unsupported Media Type
- / "416" ; Unsupported URI Scheme
- / "420" ; Bad Extension
- / "421" ; Extension Required
- / "423" ; Interval Too Brief
- / "480" ; Temporarily not available
- / "481" ; Call Leg/Transaction Does Not Exist
- / "482" ; Loop Detected
- / "483" ; Too Many Hops
- / "484" ; Address Incomplete
- / "485" ; Ambiguous
- / "486" ; Busy Here
- / "487" ; Request Terminated
- / "488" ; Not Acceptable Here
- / "491" ; Request Pending
- / "493" ; Undecipherable
-
-Server-Error = "500" ; Internal Server Error
- / "501" ; Not Implemented
- / "502" ; Bad Gateway
- / "503" ; Service Unavailable
- / "504" ; Server Time-out
- / "505" ; SIP Version not supported
- / "513" ; Message Too Large
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 226]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Global-Failure = "600" ; Busy Everywhere
- / "603" ; Decline
- / "604" ; Does not exist anywhere
- / "606" ; Not Acceptable
-
-Accept = "Accept" HCOLON
- [ accept-range *(COMMA accept-range) ]
-accept-range = media-range *(SEMI accept-param)
-media-range = ( "*/*"
- / ( m-type SLASH "*" )
- / ( m-type SLASH m-subtype )
- ) *( SEMI m-parameter )
-accept-param = ("q" EQUAL qvalue) / generic-param
-qvalue = ( "0" [ "." 0*3DIGIT ] )
- / ( "1" [ "." 0*3("0") ] )
-generic-param = token [ EQUAL gen-value ]
-gen-value = token / host / quoted-string
-
-Accept-Encoding = "Accept-Encoding" HCOLON
- [ encoding *(COMMA encoding) ]
-encoding = codings *(SEMI accept-param)
-codings = content-coding / "*"
-content-coding = token
-
-Accept-Language = "Accept-Language" HCOLON
- [ language *(COMMA language) ]
-language = language-range *(SEMI accept-param)
-language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
-
-Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)
-alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
-
-Allow = "Allow" HCOLON [Method *(COMMA Method)]
-
-Authorization = "Authorization" HCOLON credentials
-credentials = ("Digest" LWS digest-response)
- / other-response
-digest-response = dig-resp *(COMMA dig-resp)
-dig-resp = username / realm / nonce / digest-uri
- / dresponse / algorithm / cnonce
- / opaque / message-qop
- / nonce-count / auth-param
-username = "username" EQUAL username-value
-username-value = quoted-string
-digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
-digest-uri-value = rquest-uri ; Equal to request-uri as specified
- by HTTP/1.1
-message-qop = "qop" EQUAL qop-value
-
-
-
-Rosenberg, et. al. Standards Track [Page 227]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-cnonce = "cnonce" EQUAL cnonce-value
-cnonce-value = nonce-value
-nonce-count = "nc" EQUAL nc-value
-nc-value = 8LHEX
-dresponse = "response" EQUAL request-digest
-request-digest = LDQUOT 32LHEX RDQUOT
-auth-param = auth-param-name EQUAL
- ( token / quoted-string )
-auth-param-name = token
-other-response = auth-scheme LWS auth-param
- *(COMMA auth-param)
-auth-scheme = token
-
-Authentication-Info = "Authentication-Info" HCOLON ainfo
- *(COMMA ainfo)
-ainfo = nextnonce / message-qop
- / response-auth / cnonce
- / nonce-count
-nextnonce = "nextnonce" EQUAL nonce-value
-response-auth = "rspauth" EQUAL response-digest
-response-digest = LDQUOT *LHEX RDQUOT
-
-Call-ID = ( "Call-ID" / "i" ) HCOLON callid
-callid = word [ "@" word ]
-
-Call-Info = "Call-Info" HCOLON info *(COMMA info)
-info = LAQUOT absoluteURI RAQUOT *( SEMI info-param)
-info-param = ( "purpose" EQUAL ( "icon" / "info"
- / "card" / token ) ) / generic-param
-
-Contact = ("Contact" / "m" ) HCOLON
- ( STAR / (contact-param *(COMMA contact-param)))
-contact-param = (name-addr / addr-spec) *(SEMI contact-params)
-name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
-addr-spec = SIP-URI / SIPS-URI / absoluteURI
-display-name = *(token LWS)/ quoted-string
-
-contact-params = c-p-q / c-p-expires
- / contact-extension
-c-p-q = "q" EQUAL qvalue
-c-p-expires = "expires" EQUAL delta-seconds
-contact-extension = generic-param
-delta-seconds = 1*DIGIT
-
-Content-Disposition = "Content-Disposition" HCOLON
- disp-type *( SEMI disp-param )
-disp-type = "render" / "session" / "icon" / "alert"
- / disp-extension-token
-
-
-
-Rosenberg, et. al. Standards Track [Page 228]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-disp-param = handling-param / generic-param
-handling-param = "handling" EQUAL
- ( "optional" / "required"
- / other-handling )
-other-handling = token
-disp-extension-token = token
-
-Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON
- content-coding *(COMMA content-coding)
-
-Content-Language = "Content-Language" HCOLON
- language-tag *(COMMA language-tag)
-language-tag = primary-tag *( "-" subtag )
-primary-tag = 1*8ALPHA
-subtag = 1*8ALPHA
-
-Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT
-Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
-media-type = m-type SLASH m-subtype *(SEMI m-parameter)
-m-type = discrete-type / composite-type
-discrete-type = "text" / "image" / "audio" / "video"
- / "application" / extension-token
-composite-type = "message" / "multipart" / extension-token
-extension-token = ietf-token / x-token
-ietf-token = token
-x-token = "x-" token
-m-subtype = extension-token / iana-token
-iana-token = token
-m-parameter = m-attribute EQUAL m-value
-m-attribute = token
-m-value = token / quoted-string
-
-CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
-
-Date = "Date" HCOLON SIP-date
-SIP-date = rfc1123-date
-rfc1123-date = wkday "," SP date1 SP time SP "GMT"
-date1 = 2DIGIT SP month SP 4DIGIT
- ; day month year (e.g., 02 Jun 1982)
-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
- ; 00:00:00 - 23:59:59
-wkday = "Mon" / "Tue" / "Wed"
- / "Thu" / "Fri" / "Sat" / "Sun"
-month = "Jan" / "Feb" / "Mar" / "Apr"
- / "May" / "Jun" / "Jul" / "Aug"
- / "Sep" / "Oct" / "Nov" / "Dec"
-
-Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri)
-
-
-
-Rosenberg, et. al. Standards Track [Page 229]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
-
-Expires = "Expires" HCOLON delta-seconds
-From = ( "From" / "f" ) HCOLON from-spec
-from-spec = ( name-addr / addr-spec )
- *( SEMI from-param )
-from-param = tag-param / generic-param
-tag-param = "tag" EQUAL token
-
-In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid)
-
-Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
-
-MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
-
-Min-Expires = "Min-Expires" HCOLON delta-seconds
-
-Organization = "Organization" HCOLON [TEXT-UTF8-TRIM]
-
-Priority = "Priority" HCOLON priority-value
-priority-value = "emergency" / "urgent" / "normal"
- / "non-urgent" / other-priority
-other-priority = token
-
-Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
-challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
- / other-challenge
-other-challenge = auth-scheme LWS auth-param
- *(COMMA auth-param)
-digest-cln = realm / domain / nonce
- / opaque / stale / algorithm
- / qop-options / auth-param
-realm = "realm" EQUAL realm-value
-realm-value = quoted-string
-domain = "domain" EQUAL LDQUOT URI
- *( 1*SP URI ) RDQUOT
-URI = absoluteURI / abs-path
-nonce = "nonce" EQUAL nonce-value
-nonce-value = quoted-string
-opaque = "opaque" EQUAL quoted-string
-stale = "stale" EQUAL ( "true" / "false" )
-algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess"
- / token )
-qop-options = "qop" EQUAL LDQUOT qop-value
- *("," qop-value) RDQUOT
-qop-value = "auth" / "auth-int" / token
-
-Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
-
-
-
-Rosenberg, et. al. Standards Track [Page 230]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Proxy-Require = "Proxy-Require" HCOLON option-tag
- *(COMMA option-tag)
-option-tag = token
-
-Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
-rec-route = name-addr *( SEMI rr-param )
-rr-param = generic-param
-
-Reply-To = "Reply-To" HCOLON rplyto-spec
-rplyto-spec = ( name-addr / addr-spec )
- *( SEMI rplyto-param )
-rplyto-param = generic-param
-Require = "Require" HCOLON option-tag *(COMMA option-tag)
-
-Retry-After = "Retry-After" HCOLON delta-seconds
- [ comment ] *( SEMI retry-param )
-
-retry-param = ("duration" EQUAL delta-seconds)
- / generic-param
-
-Route = "Route" HCOLON route-param *(COMMA route-param)
-route-param = name-addr *( SEMI rr-param )
-
-Server = "Server" HCOLON server-val *(LWS server-val)
-server-val = product / comment
-product = token [SLASH product-version]
-product-version = token
-
-Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
-
-Supported = ( "Supported" / "k" ) HCOLON
- [option-tag *(COMMA option-tag)]
-
-Timestamp = "Timestamp" HCOLON 1*(DIGIT)
- [ "." *(DIGIT) ] [ LWS delay ]
-delay = *(DIGIT) [ "." *(DIGIT) ]
-
-To = ( "To" / "t" ) HCOLON ( name-addr
- / addr-spec ) *( SEMI to-param )
-to-param = tag-param / generic-param
-
-Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag)
-User-Agent = "User-Agent" HCOLON server-val *(LWS server-val)
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 231]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
-via-parm = sent-protocol LWS sent-by *( SEMI via-params )
-via-params = via-ttl / via-maddr
- / via-received / via-branch
- / via-extension
-via-ttl = "ttl" EQUAL ttl
-via-maddr = "maddr" EQUAL host
-via-received = "received" EQUAL (IPv4address / IPv6address)
-via-branch = "branch" EQUAL token
-via-extension = generic-param
-sent-protocol = protocol-name SLASH protocol-version
- SLASH transport
-protocol-name = "SIP" / token
-protocol-version = token
-transport = "UDP" / "TCP" / "TLS" / "SCTP"
- / other-transport
-sent-by = host [ COLON port ]
-ttl = 1*3DIGIT ; 0 to 255
-
-Warning = "Warning" HCOLON warning-value *(COMMA warning-value)
-warning-value = warn-code SP warn-agent SP warn-text
-warn-code = 3DIGIT
-warn-agent = hostport / pseudonym
- ; the name or pseudonym of the server adding
- ; the Warning header, for use in debugging
-warn-text = quoted-string
-pseudonym = token
-
-WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
-
-extension-header = header-name HCOLON header-value
-header-name = token
-header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
-message-body = *OCTET
-
-26 Security Considerations: Threat Model and Security Usage
- Recommendations
-
- SIP is not an easy protocol to secure. Its use of intermediaries,
- its multi-faceted trust relationships, its expected usage between
- elements with no trust at all, and its user-to-user operation make
- security far from trivial. Security solutions are needed that are
- deployable today, without extensive coordination, in a wide variety
- of environments and usages. In order to meet these diverse needs,
- several distinct mechanisms applicable to different aspects and
- usages of SIP will be required.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 232]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Note that the security of SIP signaling itself has no bearing on the
- security of protocols used in concert with SIP such as RTP, or with
- the security implications of any specific bodies SIP might carry
- (although MIME security plays a substantial role in securing SIP).
- Any media associated with a session can be encrypted end-to-end
- independently of any associated SIP signaling. Media encryption is
- outside the scope of this document.
-
- The considerations that follow first examine a set of classic threat
- models that broadly identify the security needs of SIP. The set of
- security services required to address these threats is then detailed,
- followed by an explanation of several security mechanisms that can be
- used to provide these services. Next, the requirements for
- implementers of SIP are enumerated, along with exemplary deployments
- in which these security mechanisms could be used to improve the
- security of SIP. Some notes on privacy conclude this section.
-
-26.1 Attacks and Threat Models
-
- This section details some threats that should be common to most
- deployments of SIP. These threats have been chosen specifically to
- illustrate each of the security services that SIP requires.
-
- The following examples by no means provide an exhaustive list of the
- threats against SIP; rather, these are "classic" threats that
- demonstrate the need for particular security services that can
- potentially prevent whole categories of threats.
-
- These attacks assume an environment in which attackers can
- potentially read any packet on the network - it is anticipated that
- SIP will frequently be used on the public Internet. Attackers on the
- network may be able to modify packets (perhaps at some compromised
- intermediary). Attackers may wish to steal services, eavesdrop on
- communications, or disrupt sessions.
-
-26.1.1 Registration Hijacking
-
- The SIP registration mechanism allows a user agent to identify itself
- to a registrar as a device at which a user (designated by an address
- of record) is located. A registrar assesses the identity asserted in
- the From header field of a REGISTER message to determine whether this
- request can modify the contact addresses associated with the
- address-of-record in the To header field. While these two fields are
- frequently the same, there are many valid deployments in which a
- third-party may register contacts on a user's behalf.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 233]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The From header field of a SIP request, however, can be modified
- arbitrarily by the owner of a UA, and this opens the door to
- malicious registrations. An attacker that successfully impersonates
- a party authorized to change contacts associated with an address-of-
- record could, for example, de-register all existing contacts for a
- URI and then register their own device as the appropriate contact
- address, thereby directing all requests for the affected user to the
- attacker's device.
-
- This threat belongs to a family of threats that rely on the absence
- of cryptographic assurance of a request's originator. Any SIP UAS
- that represents a valuable service (a gateway that interworks SIP
- requests with traditional telephone calls, for example) might want to
- control access to its resources by authenticating requests that it
- receives. Even end-user UAs, for example SIP phones, have an
- interest in ascertaining the identities of originators of requests.
-
- This threat demonstrates the need for security services that enable
- SIP entities to authenticate the originators of requests.
-
-26.1.2 Impersonating a Server
-
- The domain to which a request is destined is generally specified in
- the Request-URI. UAs commonly contact a server in this domain
- directly in order to deliver a request. However, there is always a
- possibility that an attacker could impersonate the remote server, and
- that the UA's request could be intercepted by some other party.
-
- For example, consider a case in which a redirect server at one
- domain, chicago.com, impersonates a redirect server at another
- domain, biloxi.com. A user agent sends a request to biloxi.com, but
- the redirect server at chicago.com answers with a forged response
- that has appropriate SIP header fields for a response from
- biloxi.com. The forged contact addresses in the redirection response
- could direct the originating UA to inappropriate or insecure
- resources, or simply prevent requests for biloxi.com from succeeding.
-
- This family of threats has a vast membership, many of which are
- critical. As a converse to the registration hijacking threat,
- consider the case in which a registration sent to biloxi.com is
- intercepted by chicago.com, which replies to the intercepted
- registration with a forged 301 (Moved Permanently) response. This
- response might seem to come from biloxi.com yet designate chicago.com
- as the appropriate registrar. All future REGISTER requests from the
- originating UA would then go to chicago.com.
-
- Prevention of this threat requires a means by which UAs can
- authenticate the servers to whom they send requests.
-
-
-
-Rosenberg, et. al. Standards Track [Page 234]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-26.1.3 Tampering with Message Bodies
-
- As a matter of course, SIP UAs route requests through trusted proxy
- servers. Regardless of how that trust is established (authentication
- of proxies is discussed elsewhere in this section), a UA may trust a
- proxy server to route a request, but not to inspect or possibly
- modify the bodies contained in that request.
-
- Consider a UA that is using SIP message bodies to communicate session
- encryption keys for a media session. Although it trusts the proxy
- server of the domain it is contacting to deliver signaling properly,
- it may not want the administrators of that domain to be capable of
- decrypting any subsequent media session. Worse yet, if the proxy
- server were actively malicious, it could modify the session key,
- either acting as a man-in-the-middle, or perhaps changing the
- security characteristics requested by the originating UA.
-
- This family of threats applies not only to session keys, but to most
- conceivable forms of content carried end-to-end in SIP. These might
- include MIME bodies that should be rendered to the user, SDP, or
- encapsulated telephony signals, among others. Attackers might
- attempt to modify SDP bodies, for example, in order to point RTP
- media streams to a wiretapping device in order to eavesdrop on
- subsequent voice communications.
-
- Also note that some header fields in SIP are meaningful end-to-end,
- for example, Subject. UAs might be protective of these header fields
- as well as bodies (a malicious intermediary changing the Subject
- header field might make an important request appear to be spam, for
- example). However, since many header fields are legitimately
- inspected or altered by proxy servers as a request is routed, not all
- header fields should be secured end-to-end.
-
- For these reasons, the UA might want to secure SIP message bodies,
- and in some limited cases header fields, end-to-end. The security
- services required for bodies include confidentiality, integrity, and
- authentication. These end-to-end services should be independent of
- the means used to secure interactions with intermediaries such as
- proxy servers.
-
-26.1.4 Tearing Down Sessions
-
- Once a dialog has been established by initial messaging, subsequent
- requests can be sent that modify the state of the dialog and/or
- session. It is critical that principals in a session can be certain
- that such requests are not forged by attackers.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 235]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Consider a case in which a third-party attacker captures some initial
- messages in a dialog shared by two parties in order to learn the
- parameters of the session (To tag, From tag, and so forth) and then
- inserts a BYE request into the session. The attacker could opt to
- forge the request such that it seemed to come from either
- participant. Once the BYE is received by its target, the session
- will be torn down prematurely.
-
- Similar mid-session threats include the transmission of forged re-
- INVITEs that alter the session (possibly to reduce session security
- or redirect media streams as part of a wiretapping attack).
-
- The most effective countermeasure to this threat is the
- authentication of the sender of the BYE. In this instance, the
- recipient needs only know that the BYE came from the same party with
- whom the corresponding dialog was established (as opposed to
- ascertaining the absolute identity of the sender). Also, if the
- attacker is unable to learn the parameters of the session due to
- confidentiality, it would not be possible to forge the BYE. However,
- some intermediaries (like proxy servers) will need to inspect those
- parameters as the session is established.
-
-26.1.5 Denial of Service and Amplification
-
- Denial-of-service attacks focus on rendering a particular network
- element unavailable, usually by directing an excessive amount of
- network traffic at its interfaces. A distributed denial-of-service
- attack allows one network user to cause multiple network hosts to
- flood a target host with a large amount of network traffic.
-
- In many architectures, SIP proxy servers face the public Internet in
- order to accept requests from worldwide IP endpoints. SIP creates a
- number of potential opportunities for distributed denial-of-service
- attacks that must be recognized and addressed by the implementers and
- operators of SIP systems.
-
- Attackers can create bogus requests that contain a falsified source
- IP address and a corresponding Via header field that identify a
- targeted host as the originator of the request and then send this
- request to a large number of SIP network elements, thereby using
- hapless SIP UAs or proxies to generate denial-of-service traffic
- aimed at the target.
-
- Similarly, attackers might use falsified Route header field values in
- a request that identify the target host and then send such messages
- to forking proxies that will amplify messaging sent to the target.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 236]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Record-Route could be used to similar effect when the attacker is
- certain that the SIP dialog initiated by the request will result in
- numerous transactions originating in the backwards direction.
-
- A number of denial-of-service attacks open up if REGISTER requests
- are not properly authenticated and authorized by registrars.
- Attackers could de-register some or all users in an administrative
- domain, thereby preventing these users from being invited to new
- sessions. An attacker could also register a large number of contacts
- designating the same host for a given address-of-record in order to
- use the registrar and any associated proxy servers as amplifiers in a
- denial-of-service attack. Attackers might also attempt to deplete
- available memory and disk resources of a registrar by registering
- huge numbers of bindings.
-
- The use of multicast to transmit SIP requests can greatly increase
- the potential for denial-of-service attacks.
-
- These problems demonstrate a general need to define architectures
- that minimize the risks of denial-of-service, and the need to be
- mindful in recommendations for security mechanisms of this class of
- attacks.
-
-26.2 Security Mechanisms
-
- From the threats described above, we gather that the fundamental
- security services required for the SIP protocol are: preserving the
- confidentiality and integrity of messaging, preventing replay attacks
- or message spoofing, providing for the authentication and privacy of
- the participants in a session, and preventing denial-of-service
- attacks. Bodies within SIP messages separately require the security
- services of confidentiality, integrity, and authentication.
-
- Rather than defining new security mechanisms specific to SIP, SIP
- reuses wherever possible existing security models derived from the
- HTTP and SMTP space.
-
- Full encryption of messages provides the best means to preserve the
- confidentiality of signaling - it can also guarantee that messages
- are not modified by any malicious intermediaries. However, SIP
- requests and responses cannot be naively encrypted end-to-end in
- their entirety because message fields such as the Request-URI, Route,
- and Via need to be visible to proxies in most network architectures
- so that SIP requests are routed correctly. Note that proxy servers
- need to modify some features of messages as well (such as adding Via
- header field values) in order for SIP to function. Proxy servers
- must therefore be trusted, to some degree, by SIP UAs. To this
- purpose, low-layer security mechanisms for SIP are recommended, which
-
-
-
-Rosenberg, et. al. Standards Track [Page 237]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- encrypt the entire SIP requests or responses on the wire on a hop-
- by-hop basis, and that allow endpoints to verify the identity of
- proxy servers to whom they send requests.
-
- SIP entities also have a need to identify one another in a secure
- fashion. When a SIP endpoint asserts the identity of its user to a
- peer UA or to a proxy server, that identity should in some way be
- verifiable. A cryptographic authentication mechanism is provided in
- SIP to address this requirement.
-
- An independent security mechanism for SIP message bodies supplies an
- alternative means of end-to-end mutual authentication, as well as
- providing a limit on the degree to which user agents must trust
- intermediaries.
-
-26.2.1 Transport and Network Layer Security
-
- Transport or network layer security encrypts signaling traffic,
- guaranteeing message confidentiality and integrity.
-
- Oftentimes, certificates are used in the establishment of lower-layer
- security, and these certificates can also be used to provide a means
- of authentication in many architectures.
-
- Two popular alternatives for providing security at the transport and
- network layer are, respectively, TLS [25] and IPSec [26].
-
- IPSec is a set of network-layer protocol tools that collectively can
- be used as a secure replacement for traditional IP (Internet
- Protocol). IPSec is most commonly used in architectures in which a
- set of hosts or administrative domains have an existing trust
- relationship with one another. IPSec is usually implemented at the
- operating system level in a host, or on a security gateway that
- provides confidentiality and integrity for all traffic it receives
- from a particular interface (as in a VPN architecture). IPSec can
- also be used on a hop-by-hop basis.
-
- In many architectures IPSec does not require integration with SIP
- applications; IPSec is perhaps best suited to deployments in which
- adding security directly to SIP hosts would be arduous. UAs that
- have a pre-shared keying relationship with their first-hop proxy
- server are also good candidates to use IPSec. Any deployment of
- IPSec for SIP would require an IPSec profile describing the protocol
- tools that would be required to secure SIP. No such profile is given
- in this document.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 238]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- TLS provides transport-layer security over connection-oriented
- protocols (for the purposes of this document, TCP); "tls" (signifying
- TLS over TCP) can be specified as the desired transport protocol
- within a Via header field value or a SIP-URI. TLS is most suited to
- architectures in which hop-by-hop security is required between hosts
- with no pre-existing trust association. For example, Alice trusts
- her local proxy server, which after a certificate exchange decides to
- trust Bob's local proxy server, which Bob trusts, hence Bob and Alice
- can communicate securely.
-
- TLS must be tightly coupled with a SIP application. Note that
- transport mechanisms are specified on a hop-by-hop basis in SIP, thus
- a UA that sends requests over TLS to a proxy server has no assurance
- that TLS will be used end-to-end.
-
- The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at
- a minimum by implementers when TLS is used in a SIP application. For
- purposes of backwards compatibility, proxy servers, redirect servers,
- and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
- Implementers MAY also support any other ciphersuite.
-
-26.2.2 SIPS URI Scheme
-
- The SIPS URI scheme adheres to the syntax of the SIP URI (described
- in 19), although the scheme string is "sips" rather than "sip". The
- semantics of SIPS are very different from the SIP URI, however. SIPS
- allows resources to specify that they should be reached securely.
-
- A SIPS URI can be used as an address-of-record for a particular user
- - the URI by which the user is canonically known (on their business
- cards, in the From header field of their requests, in the To header
- field of REGISTER requests). When used as the Request-URI of a
- request, the SIPS scheme signifies that each hop over which the
- request is forwarded, until the request reaches the SIP entity
- responsible for the domain portion of the Request-URI, must be
- secured with TLS; once it reaches the domain in question it is
- handled in accordance with local security and routing policy, quite
- possibly using TLS for any last hop to a UAS. When used by the
- originator of a request (as would be the case if they employed a SIPS
- URI as the address-of-record of the target), SIPS dictates that the
- entire request path to the target domain be so secured.
-
- The SIPS scheme is applicable to many of the other ways in which SIP
- URIs are used in SIP today in addition to the Request-URI, including
- in addresses-of-record, contact addresses (the contents of Contact
- headers, including those of REGISTER methods), and Route headers. In
- each instance, the SIPS URI scheme allows these existing fields to
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 239]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- designate secure resources. The manner in which a SIPS URI is
- dereferenced in any of these contexts has its own security properties
- which are detailed in [4].
-
- The use of SIPS in particular entails that mutual TLS authentication
- SHOULD be employed, as SHOULD the ciphersuite
- TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the
- authentication process SHOULD be validated with root certificates
- held by the client; failure to validate a certificate SHOULD result
- in the failure of the request.
-
- Note that in the SIPS URI scheme, transport is independent of TLS,
- and thus "sips:alice@atlanta.com;transport=tcp" and
- "sips:alice@atlanta.com;transport=sctp" are both valid (although
- note that UDP is not a valid transport for SIPS). The use of
- "transport=tls" has consequently been deprecated, partly because
- it was specific to a single hop of the request. This is a change
- since RFC 2543.
-
- Users that distribute a SIPS URI as an address-of-record may elect to
- operate devices that refuse requests over insecure transports.
-
-26.2.3 HTTP Authentication
-
- SIP provides a challenge capability, based on HTTP authentication,
- that relies on the 401 and 407 response codes as well as header
- fields for carrying challenges and credentials. Without significant
- modification, the reuse of the HTTP Digest authentication scheme in
- SIP allows for replay protection and one-way authentication.
-
- The usage of Digest authentication in SIP is detailed in Section 22.
-
-26.2.4 S/MIME
-
- As is discussed above, encrypting entire SIP messages end-to-end for
- the purpose of confidentiality is not appropriate because network
- intermediaries (like proxy servers) need to view certain header
- fields in order to route messages correctly, and if these
- intermediaries are excluded from security associations, then SIP
- messages will essentially be non-routable.
-
- However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP,
- securing these bodies end-to-end without affecting message headers.
- S/MIME can provide end-to-end confidentiality and integrity for
- message bodies, as well as mutual authentication. It is also
- possible to use S/MIME to provide a form of integrity and
- confidentiality for SIP header fields through SIP message tunneling.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 240]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The usage of S/MIME in SIP is detailed in Section 23.
-
-26.3 Implementing Security Mechanisms
-
-26.3.1 Requirements for Implementers of SIP
-
- Proxy servers, redirect servers, and registrars MUST implement TLS,
- and MUST support both mutual and one-way authentication. It is
- strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also
- be capable of acting as a TLS server. Proxy servers, redirect
- servers, and registrars SHOULD possess a site certificate whose
- subject corresponds to their canonical hostname. UAs MAY have
- certificates of their own for mutual authentication with TLS, but no
- provisions are set forth in this document for their use. All SIP
- elements that support TLS MUST have a mechanism for validating
- certificates received during TLS negotiation; this entails possession
- of one or more root certificates issued by certificate authorities
- (preferably well-known distributors of site certificates comparable
- to those that issue root certificates for web browsers).
-
- All SIP elements that support TLS MUST also support the SIPS URI
- scheme.
-
- Proxy servers, redirect servers, registrars, and UAs MAY also
- implement IPSec or other lower-layer security protocols.
-
- When a UA attempts to contact a proxy server, redirect server, or
- registrar, the UAC SHOULD initiate a TLS connection over which it
- will send SIP messages. In some architectures, UASs MAY receive
- requests over such TLS connections as well.
-
- Proxy servers, redirect servers, registrars, and UAs MUST implement
- Digest Authorization, encompassing all of the aspects required in 22.
- Proxy servers, redirect servers, and registrars SHOULD be configured
- with at least one Digest realm, and at least one "realm" string
- supported by a given server SHOULD correspond to the server's
- hostname or domainname.
-
- UAs MAY support the signing and encrypting of MIME bodies, and
- transference of credentials with S/MIME as described in Section 23.
- If a UA holds one or more root certificates of certificate
- authorities in order to validate certificates for TLS or IPSec, it
- SHOULD be capable of reusing these to verify S/MIME certificates, as
- appropriate. A UA MAY hold root certificates specifically for
- validating S/MIME certificates.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 241]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Note that is it anticipated that future security extensions may
- upgrade the normative strength associated with S/MIME as S/MIME
- implementations appear and the problem space becomes better
- understood.
-
-26.3.2 Security Solutions
-
- The operation of these security mechanisms in concert can follow the
- existing web and email security models to some degree. At a high
- level, UAs authenticate themselves to servers (proxy servers,
- redirect servers, and registrars) with a Digest username and
- password; servers authenticate themselves to UAs one hop away, or to
- another server one hop away (and vice versa), with a site certificate
- delivered by TLS.
-
- On a peer-to-peer level, UAs trust the network to authenticate one
- another ordinarily; however, S/MIME can also be used to provide
- direct authentication when the network does not, or if the network
- itself is not trusted.
-
- The following is an illustrative example in which these security
- mechanisms are used by various UAs and servers to prevent the sorts
- of threats described in Section 26.1. While implementers and network
- administrators MAY follow the normative guidelines given in the
- remainder of this section, these are provided only as example
- implementations.
-
-26.3.2.1 Registration
-
- When a UA comes online and registers with its local administrative
- domain, it SHOULD establish a TLS connection with its registrar
- (Section 10 describes how the UA reaches its registrar). The
- registrar SHOULD offer a certificate to the UA, and the site
- identified by the certificate MUST correspond with the domain in
- which the UA intends to register; for example, if the UA intends to
- register the address-of-record 'alice@atlanta.com', the site
- certificate must identify a host within the atlanta.com domain (such
- as sip.atlanta.com). When it receives the TLS Certificate message,
- the UA SHOULD verify the certificate and inspect the site identified
- by the certificate. If the certificate is invalid, revoked, or if it
- does not identify the appropriate party, the UA MUST NOT send the
- REGISTER message and otherwise proceed with the registration.
-
- When a valid certificate has been provided by the registrar, the
- UA knows that the registrar is not an attacker who might redirect
- the UA, steal passwords, or attempt any similar attacks.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 242]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The UA then creates a REGISTER request that SHOULD be addressed to a
- Request-URI corresponding to the site certificate received from the
- registrar. When the UA sends the REGISTER request over the existing
- TLS connection, the registrar SHOULD challenge the request with a 401
- (Proxy Authentication Required) response. The "realm" parameter
- within the Proxy-Authenticate header field of the response SHOULD
- correspond to the domain previously given by the site certificate.
- When the UAC receives the challenge, it SHOULD either prompt the user
- for credentials or take an appropriate credential from a keyring
- corresponding to the "realm" parameter in the challenge. The
- username of this credential SHOULD correspond with the "userinfo"
- portion of the URI in the To header field of the REGISTER request.
- Once the Digest credentials have been inserted into an appropriate
- Proxy-Authorization header field, the REGISTER should be resubmitted
- to the registrar.
-
- Since the registrar requires the user agent to authenticate
- itself, it would be difficult for an attacker to forge REGISTER
- requests for the user's address-of-record. Also note that since
- the REGISTER is sent over a confidential TLS connection, attackers
- will not be able to intercept the REGISTER to record credentials
- for any possible replay attack.
-
- Once the registration has been accepted by the registrar, the UA
- SHOULD leave this TLS connection open provided that the registrar
- also acts as the proxy server to which requests are sent for users in
- this administrative domain. The existing TLS connection will be
- reused to deliver incoming requests to the UA that has just completed
- registration.
-
- Because the UA has already authenticated the server on the other
- side of the TLS connection, all requests that come over this
- connection are known to have passed through the proxy server -
- attackers cannot create spoofed requests that appear to have been
- sent through that proxy server.
-
-26.3.2.2 Interdomain Requests
-
- Now let's say that Alice's UA would like to initiate a session with a
- user in a remote administrative domain, namely "bob@biloxi.com". We
- will also say that the local administrative domain (atlanta.com) has
- a local outbound proxy.
-
- The proxy server that handles inbound requests for an administrative
- domain MAY also act as a local outbound proxy; for simplicity's sake
- we'll assume this to be the case for atlanta.com (otherwise the user
- agent would initiate a new TLS connection to a separate server at
- this point). Assuming that the client has completed the registration
-
-
-
-Rosenberg, et. al. Standards Track [Page 243]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- process described in the preceding section, it SHOULD reuse the TLS
- connection to the local proxy server when it sends an INVITE request
- to another user. The UA SHOULD reuse cached credentials in the
- INVITE to avoid prompting the user unnecessarily.
-
- When the local outbound proxy server has validated the credentials
- presented by the UA in the INVITE, it SHOULD inspect the Request-URI
- to determine how the message should be routed (see [4]). If the
- "domainname" portion of the Request-URI had corresponded to the local
- domain (atlanta.com) rather than biloxi.com, then the proxy server
- would have consulted its location service to determine how best to
- reach the requested user.
-
- Had "alice@atlanta.com" been attempting to contact, say,
- "alex@atlanta.com", the local proxy would have proxied to the
- request to the TLS connection Alex had established with the
- registrar when he registered. Since Alex would receive this
- request over his authenticated channel, he would be assured that
- Alice's request had been authorized by the proxy server of the
- local administrative domain.
-
- However, in this instance the Request-URI designates a remote domain.
- The local outbound proxy server at atlanta.com SHOULD therefore
- establish a TLS connection with the remote proxy server at
- biloxi.com. Since both of the participants in this TLS connection
- are servers that possess site certificates, mutual TLS authentication
- SHOULD occur. Each side of the connection SHOULD verify and inspect
- the certificate of the other, noting the domain name that appears in
- the certificate for comparison with the header fields of SIP
- messages. The atlanta.com proxy server, for example, SHOULD verify
- at this stage that the certificate received from the remote side
- corresponds with the biloxi.com domain. Once it has done so, and TLS
- negotiation has completed, resulting in a secure channel between the
- two proxies, the atlanta.com proxy can forward the INVITE request to
- biloxi.com.
-
- The proxy server at biloxi.com SHOULD inspect the certificate of the
- proxy server at atlanta.com in turn and compare the domain asserted
- by the certificate with the "domainname" portion of the From header
- field in the INVITE request. The biloxi proxy MAY have a strict
- security policy that requires it to reject requests that do not match
- the administrative domain from which they have been proxied.
-
- Such security policies could be instituted to prevent the SIP
- equivalent of SMTP 'open relays' that are frequently exploited to
- generate spam.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 244]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- This policy, however, only guarantees that the request came from the
- domain it ascribes to itself; it does not allow biloxi.com to
- ascertain how atlanta.com authenticated Alice. Only if biloxi.com
- has some other way of knowing atlanta.com's authentication policies
- could it possibly ascertain how Alice proved her identity.
- biloxi.com might then institute an even stricter policy that forbids
- requests that come from domains that are not known administratively
- to share a common authentication policy with biloxi.com.
-
- Once the INVITE has been approved by the biloxi proxy, the proxy
- server SHOULD identify the existing TLS channel, if any, associated
- with the user targeted by this request (in this case
- "bob@biloxi.com"). The INVITE should be proxied through this channel
- to Bob. Since the request is received over a TLS connection that had
- previously been authenticated as the biloxi proxy, Bob knows that the
- From header field was not tampered with and that atlanta.com has
- validated Alice, although not necessarily whether or not to trust
- Alice's identity.
-
- Before they forward the request, both proxy servers SHOULD add a
- Record-Route header field to the request so that all future requests
- in this dialog will pass through the proxy servers. The proxy
- servers can thereby continue to provide security services for the
- lifetime of this dialog. If the proxy servers do not add themselves
- to the Record-Route, future messages will pass directly end-to-end
- between Alice and Bob without any security services (unless the two
- parties agree on some independent end-to-end security such as
- S/MIME). In this respect the SIP trapezoid model can provide a nice
- structure where conventions of agreement between the site proxies can
- provide a reasonably secure channel between Alice and Bob.
-
- An attacker preying on this architecture would, for example, be
- unable to forge a BYE request and insert it into the signaling
- stream between Bob and Alice because the attacker has no way of
- ascertaining the parameters of the session and also because the
- integrity mechanism transitively protects the traffic between
- Alice and Bob.
-
-26.3.2.3 Peer-to-Peer Requests
-
- Alternatively, consider a UA asserting the identity
- "carol@chicago.com" that has no local outbound proxy. When Carol
- wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate
- a TLS connection with the biloxi proxy directly (using the mechanism
- described in [4] to determine how to best to reach the given
- Request-URI). When her UA receives a certificate from the biloxi
- proxy, it SHOULD be verified normally before she passes her INVITE
- across the TLS connection. However, Carol has no means of proving
-
-
-
-Rosenberg, et. al. Standards Track [Page 245]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- her identity to the biloxi proxy, but she does have a CMS-detached
- signature over a "message/sip" body in the INVITE. It is unlikely in
- this instance that Carol would have any credentials in the biloxi.com
- realm, since she has no formal association with biloxi.com. The
- biloxi proxy MAY also have a strict policy that precludes it from
- even bothering to challenge requests that do not have biloxi.com in
- the "domainname" portion of the From header field - it treats these
- users as unauthenticated.
-
- The biloxi proxy has a policy for Bob that all non-authenticated
- requests should be redirected to the appropriate contact address
- registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>.
- Carol receives the redirection response over the TLS connection she
- established with the biloxi proxy, so she trusts the veracity of the
- contact address.
-
- Carol SHOULD then establish a TCP connection with the designated
- address and send a new INVITE with a Request-URI containing the
- received contact address (recomputing the signature in the body as
- the request is readied). Bob receives this INVITE on an insecure
- interface, but his UA inspects and, in this instance, recognizes the
- From header field of the request and subsequently matches a locally
- cached certificate with the one presented in the signature of the
- body of the INVITE. He replies in similar fashion, authenticating
- himself to Carol, and a secure dialog begins.
-
- Sometimes firewalls or NATs in an administrative domain could
- preclude the establishment of a direct TCP connection to a UA. In
- these cases, proxy servers could also potentially relay requests
- to UAs in a way that has no trust implications (for example,
- forgoing an existing TLS connection and forwarding the request
- over cleartext TCP) as local policy dictates.
-
-26.3.2.4 DoS Protection
-
- In order to minimize the risk of a denial-of-service attack against
- architectures using these security solutions, implementers should
- take note of the following guidelines.
-
- When the host on which a SIP proxy server is operating is routable
- from the public Internet, it SHOULD be deployed in an administrative
- domain with defensive operational policies (blocking source-routed
- traffic, preferably filtering ping traffic). Both TLS and IPSec can
- also make use of bastion hosts at the edges of administrative domains
- that participate in the security associations to aggregate secure
- tunnels and sockets. These bastion hosts can also take the brunt of
- denial-of-service attacks, ensuring that SIP hosts within the
- administrative domain are not encumbered with superfluous messaging.
-
-
-
-Rosenberg, et. al. Standards Track [Page 246]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- No matter what security solutions are deployed, floods of messages
- directed at proxy servers can lock up proxy server resources and
- prevent desirable traffic from reaching its destination. There is a
- computational expense associated with processing a SIP transaction at
- a proxy server, and that expense is greater for stateful proxy
- servers than it is for stateless proxy servers. Therefore, stateful
- proxies are more susceptible to flooding than stateless proxy
- servers.
-
- UAs and proxy servers SHOULD challenge questionable requests with
- only a single 401 (Unauthorized) or 407 (Proxy Authentication
- Required), forgoing the normal response retransmission algorithm, and
- thus behaving statelessly towards unauthenticated requests.
-
- Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication
- Required) status response amplifies the problem of an attacker
- using a falsified header field value (such as Via) to direct
- traffic to a third party.
-
- In summary, the mutual authentication of proxy servers through
- mechanisms such as TLS significantly reduces the potential for rogue
- intermediaries to introduce falsified requests or responses that can
- deny service. This commensurately makes it harder for attackers to
- make innocent SIP nodes into agents of amplification.
-
-26.4 Limitations
-
- Although these security mechanisms, when applied in a judicious
- manner, can thwart many threats, there are limitations in the scope
- of the mechanisms that must be understood by implementers and network
- operators.
-
-26.4.1 HTTP Digest
-
- One of the primary limitations of using HTTP Digest in SIP is that
- the integrity mechanisms in Digest do not work very well for SIP.
- Specifically, they offer protection of the Request-URI and the method
- of a message, but not for any of the header fields that UAs would
- most likely wish to secure.
-
- The existing replay protection mechanisms described in RFC 2617 also
- have some limitations for SIP. The next-nonce mechanism, for
- example, does not support pipelined requests. The nonce-count
- mechanism should be used for replay protection.
-
- Another limitation of HTTP Digest is the scope of realms. Digest is
- valuable when a user wants to authenticate themselves to a resource
- with which they have a pre-existing association, like a service
-
-
-
-Rosenberg, et. al. Standards Track [Page 247]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- provider of which the user is a customer (which is quite a common
- scenario and thus Digest provides an extremely useful function). By
- way of contrast, the scope of TLS is interdomain or multirealm, since
- certificates are often globally verifiable, so that the UA can
- authenticate the server with no pre-existing association.
-
-26.4.2 S/MIME
-
- The largest outstanding defect with the S/MIME mechanism is the lack
- of a prevalent public key infrastructure for end users. If self-
- signed certificates (or certificates that cannot be verified by one
- of the participants in a dialog) are used, the SIP-based key exchange
- mechanism described in Section 23.2 is susceptible to a man-in-the-
- middle attack with which an attacker can potentially inspect and
- modify S/MIME bodies. The attacker needs to intercept the first
- exchange of keys between the two parties in a dialog, remove the
- existing CMS-detached signatures from the request and response, and
- insert a different CMS-detached signature containing a certificate
- supplied by the attacker (but which seems to be a certificate for the
- proper address-of-record). Each party will think they have exchanged
- keys with the other, when in fact each has the public key of the
- attacker.
-
- It is important to note that the attacker can only leverage this
- vulnerability on the first exchange of keys between two parties - on
- subsequent occasions, the alteration of the key would be noticeable
- to the UAs. It would also be difficult for the attacker to remain in
- the path of all future dialogs between the two parties over time (as
- potentially days, weeks, or years pass).
-
- SSH is susceptible to the same man-in-the-middle attack on the first
- exchange of keys; however, it is widely acknowledged that while SSH
- is not perfect, it does improve the security of connections. The use
- of key fingerprints could provide some assistance to SIP, just as it
- does for SSH. For example, if two parties use SIP to establish a
- voice communications session, each could read off the fingerprint of
- the key they received from the other, which could be compared against
- the original. It would certainly be more difficult for the man-in-
- the-middle to emulate the voices of the participants than their
- signaling (a practice that was used with the Clipper chip-based
- secure telephone).
-
- The S/MIME mechanism allows UAs to send encrypted requests without
- preamble if they possess a certificate for the destination address-
- of-record on their keyring. However, it is possible that any
- particular device registered for an address-of-record will not hold
- the certificate that has been previously employed by the device's
- current user, and that it will therefore be unable to process an
-
-
-
-Rosenberg, et. al. Standards Track [Page 248]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- encrypted request properly, which could lead to some avoidable error
- signaling. This is especially likely when an encrypted request is
- forked.
-
- The keys associated with S/MIME are most useful when associated with
- a particular user (an address-of-record) rather than a device (a UA).
- When users move between devices, it may be difficult to transport
- private keys securely between UAs; how such keys might be acquired by
- a device is outside the scope of this document.
-
- Another, more prosaic difficulty with the S/MIME mechanism is that it
- can result in very large messages, especially when the SIP tunneling
- mechanism described in Section 23.4 is used. For that reason, it is
- RECOMMENDED that TCP should be used as a transport protocol when
- S/MIME tunneling is employed.
-
-26.4.3 TLS
-
- The most commonly voiced concern about TLS is that it cannot run over
- UDP; TLS requires a connection-oriented underlying transport
- protocol, which for the purposes of this document means TCP.
-
- It may also be arduous for a local outbound proxy server and/or
- registrar to maintain many simultaneous long-lived TLS connections
- with numerous UAs. This introduces some valid scalability concerns,
- especially for intensive ciphersuites. Maintaining redundancy of
- long-lived TLS connections, especially when a UA is solely
- responsible for their establishment, could also be cumbersome.
-
- TLS only allows SIP entities to authenticate servers to which they
- are adjacent; TLS offers strictly hop-by-hop security. Neither TLS,
- nor any other mechanism specified in this document, allows clients to
- authenticate proxy servers to whom they cannot form a direct TCP
- connection.
-
-26.4.4 SIPS URIs
-
- Actually using TLS on every segment of a request path entails that
- the terminating UAS must be reachable over TLS (perhaps registering
- with a SIPS URI as a contact address). This is the preferred use of
- SIPS. Many valid architectures, however, use TLS to secure part of
- the request path, but rely on some other mechanism for the final hop
- to a UAS, for example. Thus SIPS cannot guarantee that TLS usage
- will be truly end-to-end. Note that since many UAs will not accept
- incoming TLS connections, even those UAs that do support TLS may be
- required to maintain persistent TLS connections as described in the
- TLS limitations section above in order to receive requests over TLS
- as a UAS.
-
-
-
-Rosenberg, et. al. Standards Track [Page 249]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Location services are not required to provide a SIPS binding for a
- SIPS Request-URI. Although location services are commonly populated
- by user registrations (as described in Section 10.2.1), various other
- protocols and interfaces could conceivably supply contact addresses
- for an AOR, and these tools are free to map SIPS URIs to SIP URIs as
- appropriate. When queried for bindings, a location service returns
- its contact addresses without regard for whether it received a
- request with a SIPS Request-URI. If a redirect server is accessing
- the location service, it is up to the entity that processes the
- Contact header field of a redirection to determine the propriety of
- the contact addresses.
-
- Ensuring that TLS will be used for all of the request segments up to
- the target domain is somewhat complex. It is possible that
- cryptographically authenticated proxy servers along the way that are
- non-compliant or compromised may choose to disregard the forwarding
- rules associated with SIPS (and the general forwarding rules in
- Section 16.6). Such malicious intermediaries could, for example,
- retarget a request from a SIPS URI to a SIP URI in an attempt to
- downgrade security.
-
- Alternatively, an intermediary might legitimately retarget a request
- from a SIP to a SIPS URI. Recipients of a request whose Request-URI
- uses the SIPS URI scheme thus cannot assume on the basis of the
- Request-URI alone that SIPS was used for the entire request path
- (from the client onwards).
-
- To address these concerns, it is RECOMMENDED that recipients of a
- request whose Request-URI contains a SIP or SIPS URI inspect the To
- header field value to see if it contains a SIPS URI (though note that
- it does not constitute a breach of security if this URI has the same
- scheme but is not equivalent to the URI in the To header field).
- Although clients may choose to populate the Request-URI and To header
- field of a request differently, when SIPS is used this disparity
- could be interpreted as a possible security violation, and the
- request could consequently be rejected by its recipient. Recipients
- MAY also inspect the Via header chain in order to double-check
- whether or not TLS was used for the entire request path until the
- local administrative domain was reached. S/MIME may also be used by
- the originating UAC to help ensure that the original form of the To
- header field is carried end-to-end.
-
- If the UAS has reason to believe that the scheme of the Request-URI
- has been improperly modified in transit, the UA SHOULD notify its
- user of a potential security breach.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 250]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- As a further measure to prevent downgrade attacks, entities that
- accept only SIPS requests MAY also refuse connections on insecure
- ports.
-
- End users will undoubtedly discern the difference between SIPS and
- SIP URIs, and they may manually edit them in response to stimuli.
- This can either benefit or degrade security. For example, if an
- attacker corrupts a DNS cache, inserting a fake record set that
- effectively removes all SIPS records for a proxy server, then any
- SIPS requests that traverse this proxy server may fail. When a user,
- however, sees that repeated calls to a SIPS AOR are failing, they
- could on some devices manually convert the scheme from SIPS to SIP
- and retry. Of course, there are some safeguards against this (if the
- destination UA is truly paranoid it could refuse all non-SIPS
- requests), but it is a limitation worth noting. On the bright side,
- users might also divine that 'SIPS' would be valid even when they are
- presented only with a SIP URI.
-
-26.5 Privacy
-
- SIP messages frequently contain sensitive information about their
- senders - not just what they have to say, but with whom they
- communicate, when they communicate and for how long, and from where
- they participate in sessions. Many applications and their users
- require that this sort of private information be hidden from any
- parties that do not need to know it.
-
- Note that there are also less direct ways in which private
- information can be divulged. If a user or service chooses to be
- reachable at an address that is guessable from the person's name and
- organizational affiliation (which describes most addresses-of-
- record), the traditional method of ensuring privacy by having an
- unlisted "phone number" is compromised. A user location service can
- infringe on the privacy of the recipient of a session invitation by
- divulging their specific whereabouts to the caller; an implementation
- consequently SHOULD be able to restrict, on a per-user basis, what
- kind of location and availability information is given out to certain
- classes of callers. This is a whole class of problem that is
- expected to be studied further in ongoing SIP work.
-
- In some cases, users may want to conceal personal information in
- header fields that convey identity. This can apply not only to the
- From and related headers representing the originator of the request,
- but also the To - it may not be appropriate to convey to the final
- destination a speed-dialing nickname, or an unexpanded identifier for
- a group of targets, either of which would be removed from the
- Request-URI as the request is routed, but not changed in the To
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 251]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- header field if the two were initially identical. Thus it MAY be
- desirable for privacy reasons to create a To header field that
- differs from the Request-URI.
-
-27 IANA Considerations
-
- All method names, header field names, status codes, and option tags
- used in SIP applications are registered with IANA through
- instructions in an IANA Considerations section in an RFC.
-
- The specification instructs the IANA to create four new sub-
- registries under http://www.iana.org/assignments/sip-parameters:
- Option Tags, Warning Codes (warn-codes), Methods and Response Codes,
- added to the sub-registry of Header Fields that is already present
- there.
-
-27.1 Option Tags
-
- This specification establishes the Option Tags sub-registry under
- http://www.iana.org/assignments/sip-parameters.
-
- Option tags are used in header fields such as Require, Supported,
- Proxy-Require, and Unsupported in support of SIP compatibility
- mechanisms for extensions (Section 19.2). The option tag itself is a
- string that is associated with a particular SIP option (that is, an
- extension). It identifies the option to SIP endpoints.
-
- Option tags are registered by the IANA when they are published in
- standards track RFCs. The IANA Considerations section of the RFC
- must include the following information, which appears in the IANA
- registry along with the RFC number of the publication.
-
- o Name of the option tag. The name MAY be of any length, but
- SHOULD be no more than twenty characters long. The name MUST
- consist of alphanum (Section 25) characters only.
-
- o Descriptive text that describes the extension.
-
-27.2 Warn-Codes
-
- This specification establishes the Warn-codes sub-registry under
- http://www.iana.org/assignments/sip-parameters and initiates its
- population with the warn-codes listed in Section 20.43. Additional
- warn-codes are registered by RFC publication.
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 252]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- The descriptive text for the table of warn-codes is:
-
- Warning codes provide information supplemental to the status code in
- SIP response messages when the failure of the transaction results
- from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.
-
- The "warn-code" consists of three digits. A first digit of "3"
- indicates warnings specific to SIP. Until a future specification
- describes uses of warn-codes other than 3xx, only 3xx warn-codes may
- be registered.
-
- Warnings 300 through 329 are reserved for indicating problems with
- keywords in the session description, 330 through 339 are warnings
- related to basic network services requested in the session
- description, 370 through 379 are warnings related to quantitative QoS
- parameters requested in the session description, and 390 through 399
- are miscellaneous warnings that do not fall into one of the above
- categories.
-
-27.3 Header Field Names
-
- This obsoletes the IANA instructions about the header sub-registry
- under http://www.iana.org/assignments/sip-parameters.
-
- The following information needs to be provided in an RFC publication
- in order to register a new header field name:
-
- o The RFC number in which the header is registered;
-
- o the name of the header field being registered;
-
- o a compact form version for that header field, if one is
- defined;
-
- Some common and widely used header fields MAY be assigned one-letter
- compact forms (Section 7.3.3). Compact forms can only be assigned
- after SIP working group review, followed by RFC publication.
-
-27.4 Method and Response Codes
-
- This specification establishes the Method and Response-Code sub-
- registries under http://www.iana.org/assignments/sip-parameters and
- initiates their population as follows. The initial Methods table is:
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 253]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- INVITE [RFC3261]
- ACK [RFC3261]
- BYE [RFC3261]
- CANCEL [RFC3261]
- REGISTER [RFC3261]
- OPTIONS [RFC3261]
- INFO [RFC2976]
-
- The response code table is initially populated from Section 21, the
- portions labeled Informational, Success, Redirection, Client-Error,
- Server-Error, and Global-Failure. The table has the following
- format:
-
- Type (e.g., Informational)
- Number Default Reason Phrase [RFC3261]
-
- The following information needs to be provided in an RFC publication
- in order to register a new response code or method:
-
- o The RFC number in which the method or response code is
- registered;
-
- o the number of the response code or name of the method being
- registered;
-
- o the default reason phrase for that response code, if
- applicable;
-
-27.5 The "message/sip" MIME type.
-
- This document registers the "message/sip" MIME media type in order to
- allow SIP messages to be tunneled as bodies within SIP, primarily for
- end-to-end security purposes. This media type is defined by the
- following information:
-
- Media type name: message
- Media subtype name: sip
- Required parameters: none
-
- Optional parameters: version
- version: The SIP-Version number of the enclosed message (e.g.,
- "2.0"). If not present, the version defaults to "2.0".
- Encoding scheme: SIP messages consist of an 8-bit header
- optionally followed by a binary MIME data object. As such, SIP
- messages must be treated as binary. Under normal circumstances
- SIP messages are transported over binary-capable transports, no
- special encodings are needed.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 254]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Security considerations: see below
- Motivation and examples of this usage as a security mechanism
- in concert with S/MIME are given in 23.4.
-
-27.6 New Content-Disposition Parameter Registrations
-
- This document also registers four new Content-Disposition header
- "disposition-types": alert, icon, session and render. The authors
- request that these values be recorded in the IANA registry for
- Content-Dispositions.
-
- Descriptions of these "disposition-types", including motivation and
- examples, are given in Section 20.11.
-
- Short descriptions suitable for the IANA registry are:
-
- alert the body is a custom ring tone to alert the user
- icon the body is displayed as an icon to the user
- render the body should be displayed to the user
- session the body describes a communications session, for
- example, as RFC 2327 SDP body
-
-28 Changes From RFC 2543
-
- This RFC revises RFC 2543. It is mostly backwards compatible with
- RFC 2543. The changes described here fix many errors discovered in
- RFC 2543 and provide information on scenarios not detailed in RFC
- 2543. The protocol has been presented in a more cleanly layered
- model here.
-
- We break the differences into functional behavior that is a
- substantial change from RFC 2543, which has impact on
- interoperability or correct operation in some cases, and functional
- behavior that is different from RFC 2543 but not a potential source
- of interoperability problems. There have been countless
- clarifications as well, which are not documented here.
-
-28.1 Major Functional Changes
-
- o When a UAC wishes to terminate a call before it has been answered,
- it sends CANCEL. If the original INVITE still returns a 2xx, the
- UAC then sends BYE. BYE can only be sent on an existing call leg
- (now called a dialog in this RFC), whereas it could be sent at any
- time in RFC 2543.
-
- o The SIP BNF was converted to be RFC 2234 compliant.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 255]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o SIP URL BNF was made more general, allowing a greater set of
- characters in the user part. Furthermore, comparison rules were
- simplified to be primarily case-insensitive, and detailed handling
- of comparison in the presence of parameters was described. The
- most substantial change is that a URI with a parameter with the
- default value does not match a URI without that parameter.
-
- o Removed Via hiding. It had serious trust issues, since it relied
- on the next hop to perform the obfuscation process. Instead, Via
- hiding can be done as a local implementation choice in stateful
- proxies, and thus is no longer documented.
-
- o In RFC 2543, CANCEL and INVITE transactions were intermingled.
- They are separated now. When a user sends an INVITE and then a
- CANCEL, the INVITE transaction still terminates normally. A UAS
- needs to respond to the original INVITE request with a 487
- response.
-
- o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543
- allowed the UAS not to send a response to INVITE when a BYE was
- received. That is disallowed here. The original INVITE needs a
- response.
-
- o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs
- need to support both UDP and TCP.
-
- o In RFC 2543, a forking proxy only passed up one challenge from
- downstream elements in the event of multiple challenges. In this
- RFC, proxies are supposed to collect all challenges and place them
- into the forwarded response.
-
- o In Digest credentials, the URI needs to be quoted; this is unclear
- from RFC 2617 and RFC 2069 which are both inconsistent on it.
-
- o SDP processing has been split off into a separate specification
- [13], and more fully specified as a formal offer/answer exchange
- process that is effectively tunneled through SIP. SDP is allowed
- in INVITE/200 or 200/ACK for baseline SIP implementations; RFC
- 2543 alluded to the ability to use it in INVITE, 200, and ACK in a
- single transaction, but this was not well specified. More complex
- SDP usages are allowed in extensions.
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 256]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o Added full support for IPv6 in URIs and in the Via header field.
- Support for IPv6 in Via has required that its header field
- parameters allow the square bracket and colon characters. These
- characters were previously not permitted. In theory, this could
- cause interop problems with older implementations. However, we
- have observed that most implementations accept any non-control
- ASCII character in these parameters.
-
- o DNS SRV procedure is now documented in a separate specification
- [4]. This procedure uses both SRV and NAPTR resource records and
- no longer combines data from across SRV records as described in
- RFC 2543.
-
- o Loop detection has been made optional, supplanted by a mandatory
- usage of Max-Forwards. The loop detection procedure in RFC 2543
- had a serious bug which would report "spirals" as an error
- condition when it was not. The optional loop detection procedure
- is more fully and correctly specified here.
-
- o Usage of tags is now mandatory (they were optional in RFC 2543),
- as they are now the fundamental building blocks of dialog
- identification.
-
- o Added the Supported header field, allowing for clients to indicate
- what extensions are supported to a server, which can apply those
- extensions to the response, and indicate their usage with a
- Require in the response.
-
- o Extension parameters were missing from the BNF for several header
- fields, and they have been added.
-
- o Handling of Route and Record-Route construction was very
- underspecified in RFC 2543, and also not the right approach. It
- has been substantially reworked in this specification (and made
- vastly simpler), and this is arguably the largest change.
- Backwards compatibility is still provided for deployments that do
- not use "pre-loaded routes", where the initial request has a set
- of Route header field values obtained in some way outside of
- Record-Route. In those situations, the new mechanism is not
- interoperable.
-
- o In RFC 2543, lines in a message could be terminated with CR, LF,
- or CRLF. This specification only allows CRLF.
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 257]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o Usage of Route in CANCEL and ACK was not well defined in RFC 2543.
- It is now well specified; if a request had a Route header field,
- its CANCEL or ACK for a non-2xx response to the request need to
- carry the same Route header field values. ACKs for 2xx responses
- use the Route values learned from the Record-Route of the 2xx
- responses.
-
- o RFC 2543 allowed multiple requests in a single UDP packet. This
- usage has been removed.
-
- o Usage of absolute time in the Expires header field and parameter
- has been removed. It caused interoperability problems in elements
- that were not time synchronized, a common occurrence. Relative
- times are used instead.
-
- o The branch parameter of the Via header field value is now
- mandatory for all elements to use. It now plays the role of a
- unique transaction identifier. This avoids the complex and bug-
- laden transaction identification rules from RFC 2543. A magic
- cookie is used in the parameter value to determine if the previous
- hop has made the parameter globally unique, and comparison falls
- back to the old rules when it is not present. Thus,
- interoperability is assured.
-
- o In RFC 2543, closure of a TCP connection was made equivalent to a
- CANCEL. This was nearly impossible to implement (and wrong) for
- TCP connections between proxies. This has been eliminated, so
- that there is no coupling between TCP connection state and SIP
- processing.
-
- o RFC 2543 was silent on whether a UA could initiate a new
- transaction to a peer while another was in progress. That is now
- specified here. It is allowed for non-INVITE requests, disallowed
- for INVITE.
-
- o PGP was removed. It was not sufficiently specified, and not
- compatible with the more complete PGP MIME. It was replaced with
- S/MIME.
-
- o Added the "sips" URI scheme for end-to-end TLS. This scheme is
- not backwards compatible with RFC 2543. Existing elements that
- receive a request with a SIPS URI scheme in the Request-URI will
- likely reject the request. This is actually a feature; it ensures
- that a call to a SIPS URI is only delivered if all path hops can
- be secured.
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 258]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o Additional security features were added with TLS, and these are
- described in a much larger and complete security considerations
- section.
-
- o In RFC 2543, a proxy was not required to forward provisional
- responses from 101 to 199 upstream. This was changed to MUST.
- This is important, since many subsequent features depend on
- delivery of all provisional responses from 101 to 199.
-
- o Little was said about the 503 response code in RFC 2543. It has
- since found substantial use in indicating failure or overload
- conditions in proxies. This requires somewhat special treatment.
- Specifically, receipt of a 503 should trigger an attempt to
- contact the next element in the result of a DNS SRV lookup. Also,
- 503 response is only forwarded upstream by a proxy under certain
- conditions.
-
- o RFC 2543 defined, but did no sufficiently specify, a mechanism for
- UA authentication of a server. That has been removed. Instead,
- the mutual authentication procedures of RFC 2617 are allowed.
-
- o A UA cannot send a BYE for a call until it has received an ACK for
- the initial INVITE. This was allowed in RFC 2543 but leads to a
- potential race condition.
-
- o A UA or proxy cannot send CANCEL for a transaction until it gets a
- provisional response for the request. This was allowed in RFC
- 2543 but leads to potential race conditions.
-
- o The action parameter in registrations has been deprecated. It was
- insufficient for any useful services, and caused conflicts when
- application processing was applied in proxies.
-
- o RFC 2543 had a number of special cases for multicast. For
- example, certain responses were suppressed, timers were adjusted,
- and so on. Multicast now plays a more limited role, and the
- protocol operation is unaffected by usage of multicast as opposed
- to unicast. The limitations as a result of that are documented.
-
- o Basic authentication has been removed entirely and its usage
- forbidden.
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 259]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- o Proxies no longer forward a 6xx immediately on receiving it.
- Instead, they CANCEL pending branches immediately. This avoids a
- potential race condition that would result in a UAC getting a 6xx
- followed by a 2xx. In all cases except this race condition, the
- result will be the same - the 6xx is forwarded upstream.
-
- o RFC 2543 did not address the problem of request merging. This
- occurs when a request forks at a proxy and later rejoins at an
- element. Handling of merging is done only at a UA, and procedures
- are defined for rejecting all but the first request.
-
-28.2 Minor Functional Changes
-
- o Added the Alert-Info, Error-Info, and Call-Info header fields for
- optional content presentation to users.
-
- o Added the Content-Language, Content-Disposition and MIME-Version
- header fields.
-
- o Added a "glare handling" mechanism to deal with the case where
- both parties send each other a re-INVITE simultaneously. It uses
- the new 491 (Request Pending) error code.
-
- o Added the In-Reply-To and Reply-To header fields for supporting
- the return of missed calls or messages at a later time.
-
- o Added TLS and SCTP as valid SIP transports.
-
- o There were a variety of mechanisms described for handling failures
- at any time during a call; those are now generally unified. BYE
- is sent to terminate.
-
- o RFC 2543 mandated retransmission of INVITE responses over TCP, but
- noted it was really only needed for 2xx. That was an artifact of
- insufficient protocol layering. With a more coherent transaction
- layer defined here, that is no longer needed. Only 2xx responses
- to INVITEs are retransmitted over TCP.
-
- o Client and server transaction machines are now driven based on
- timeouts rather than retransmit counts. This allows the state
- machines to be properly specified for TCP and UDP.
-
- o The Date header field is used in REGISTER responses to provide a
- simple means for auto-configuration of dates in user agents.
-
- o Allowed a registrar to reject registrations with expirations that
- are too short in duration. Defined the 423 response code and the
- Min-Expires for this purpose.
-
-
-
-Rosenberg, et. al. Standards Track [Page 260]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-29 Normative References
-
- [1] Handley, M. and V. Jacobson, "SDP: Session Description
- Protocol", RFC 2327, April 1998.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
- [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers",
- RFC 3263, June 2002.
-
- [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
- [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
- Transport Layer Security (TLS)", RFC 3268, June 2002.
-
- [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
- 2279, January 1998.
-
- [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
- HTTP/1.1", RFC 2616, June 1999.
-
- [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
- 2000.
-
- [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046, November
- 1996.
-
- [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
- [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
- SDP", RFC 3264, June 2002.
-
- [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
- 1980.
-
- [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC
- 761, January 1980.
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 261]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
- H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
- "Stream Control Transmission Protocol", RFC 2960, October 2000.
-
- [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
- Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:
- Basic and Digest Access Authentication", RFC 2617, June 1999.
-
- [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
- Information in Internet Messages: The Content-Disposition Header
- Field", RFC 2183, August 1997.
-
- [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
- Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
- Objects", RFC 3204, December 2001.
-
- [20] Braden, R., "Requirements for Internet Hosts - Application and
- Support", STD 3, RFC 1123, October 1989.
-
- [21] Alvestrand, H., "IETF Policy on Character Sets and Languages",
- BCP 18, RFC 2277, January 1998.
-
- [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
- Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
- RFC 1847, October 1995.
-
- [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
- 1999.
-
- [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633,
- June 1999.
-
- [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
- 2246, January 1999.
-
- [26] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
-30 Informative References
-
- [27] R. Pandya, "Emerging mobile and personal communication systems,"
- IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.
-
- [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
- "RTP: A Transport Protocol for Real-Time Applications", RFC
- 1889, January 1996.
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 262]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming
- Protocol (RTSP)", RFC 2326, April 1998.
-
- [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and
- J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November
- 2000.
-
- [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
- "SIP: Session Initiation Protocol", RFC 2543, March 1999.
-
- [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
- scheme", RFC 2368, July 1998.
-
- [33] E. M. Schooler, "A multicast user directory service for
- synchronous rendezvous," Master's Thesis CS-TR-96-18, Department
- of Computer Science, California Institute of Technology,
- Pasadena, California, Aug. 1996.
-
- [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
-
- [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
- 1992.
-
- [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC
- 2426, September 1998.
-
- [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
- Specification", RFC 2849, June 2000.
-
- [38] Palme, J., "Common Internet Message Headers", RFC 2076,
- February 1997.
-
- [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
- Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
- Digest Access Authentication", RFC 2069, January 1997.
-
- [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis,
- D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call
- Flow Examples", Work in Progress.
-
- [41] E. M. Schooler, "Case study: multimedia conference control in a
- packet-switched teleconferencing system," Journal of
- Internetworking: Research and Experience, Vol. 4, pp. 99--120,
- June 1993. ISI reprint series ISI/RS-93-359.
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 263]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- [42] H. Schulzrinne, "Personal mobility for multimedia services in
- the Internet," in European Workshop on Interactive Distributed
- Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar.
- 1996.
-
- [43] Floyd, S., "Congestion Control Principles", RFC 2914, September
- 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 264]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-A Table of Timer Values
-
- Table 4 summarizes the meaning and defaults of the various timers
- used by this specification.
-
-Timer Value Section Meaning
-----------------------------------------------------------------------
-T1 500ms default Section 17.1.1.1 RTT Estimate
-T2 4s Section 17.1.2.2 The maximum retransmit
- interval for non-INVITE
- requests and INVITE
- responses
-T4 5s Section 17.1.2.2 Maximum duration a
- message will
- remain in the network
-Timer A initially T1 Section 17.1.1.2 INVITE request retransmit
- interval, for UDP only
-Timer B 64*T1 Section 17.1.1.2 INVITE transaction
- timeout timer
-Timer C > 3min Section 16.6 proxy INVITE transaction
- bullet 11 timeout
-Timer D > 32s for UDP Section 17.1.1.2 Wait time for response
- 0s for TCP/SCTP retransmits
-Timer E initially T1 Section 17.1.2.2 non-INVITE request
- retransmit interval,
- UDP only
-Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction
- timeout timer
-Timer G initially T1 Section 17.2.1 INVITE response
- retransmit interval
-Timer H 64*T1 Section 17.2.1 Wait time for
- ACK receipt
-Timer I T4 for UDP Section 17.2.1 Wait time for
- 0s for TCP/SCTP ACK retransmits
-Timer J 64*T1 for UDP Section 17.2.2 Wait time for
- 0s for TCP/SCTP non-INVITE request
- retransmits
-Timer K T4 for UDP Section 17.1.2.2 Wait time for
- 0s for TCP/SCTP response retransmits
-
- Table 4: Summary of timers
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 265]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Acknowledgments
-
- We wish to thank the members of the IETF MMUSIC and SIP WGs for their
- comments and suggestions. Detailed comments were provided by Ofir
- Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan,
- Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John
- Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema,
- Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders
- Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William
- Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe
- J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick
- Workman.
-
- Brian Rosen provided the compiled BNF.
-
- Jean Mahoney provided technical writing assistance.
-
- This work is based, inter alia, on [41,42].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 266]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Authors' Addresses
-
- Authors addresses are listed alphabetically for the editors, the
- writers, and then the original authors of RFC 2543. All listed
- authors actively contributed large amounts of text to this document.
-
- Jonathan Rosenberg
- dynamicsoft
- 72 Eagle Rock Ave
- East Hanover, NJ 07936
- USA
-
- EMail: jdrosen@dynamicsoft.com
-
-
- Henning Schulzrinne
- Dept. of Computer Science
- Columbia University
- 1214 Amsterdam Avenue
- New York, NY 10027
- USA
-
- EMail: schulzrinne@cs.columbia.edu
-
-
- Gonzalo Camarillo
- Ericsson
- Advanced Signalling Research Lab.
- FIN-02420 Jorvas
- Finland
-
- EMail: Gonzalo.Camarillo@ericsson.com
-
-
- Alan Johnston
- WorldCom
- 100 South 4th Street
- St. Louis, MO 63102
- USA
-
- EMail: alan.johnston@wcom.com
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 267]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
- Jon Peterson
- NeuStar, Inc
- 1800 Sutter Street, Suite 570
- Concord, CA 94520
- USA
-
- EMail: jon.peterson@neustar.com
-
-
- Robert Sparks
- dynamicsoft, Inc.
- 5100 Tennyson Parkway
- Suite 1200
- Plano, Texas 75024
- USA
-
- EMail: rsparks@dynamicsoft.com
-
-
- Mark Handley
- International Computer Science Institute
- 1947 Center St, Suite 600
- Berkeley, CA 94704
- USA
-
- EMail: mjh@icir.org
-
-
- Eve Schooler
- AT&T Labs-Research
- 75 Willow Road
- Menlo Park, CA 94025
- USA
-
- EMail: schooler@research.att.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 268]
-
-RFC 3261 SIP: Session Initiation Protocol June 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg, et. al. Standards Track [Page 269]
-
+
+
+
+
+
+
+Network Working Group J. Rosenberg
+Request for Comments: 3261 dynamicsoft
+Obsoletes: 2543 H. Schulzrinne
+Category: Standards Track Columbia U.
+ G. Camarillo
+ Ericsson
+ A. Johnston
+ WorldCom
+ J. Peterson
+ Neustar
+ R. Sparks
+ dynamicsoft
+ M. Handley
+ ICIR
+ E. Schooler
+ AT&T
+ June 2002
+
+ SIP: Session Initiation Protocol
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document describes Session Initiation Protocol (SIP), an
+ application-layer control (signaling) protocol for creating,
+ modifying, and terminating sessions with one or more participants.
+ These sessions include Internet telephone calls, multimedia
+ distribution, and multimedia conferences.
+
+ SIP invitations used to create sessions carry session descriptions
+ that allow participants to agree on a set of compatible media types.
+ SIP makes use of elements called proxy servers to help route requests
+ to the user's current location, authenticate and authorize users for
+ services, implement provider call-routing policies, and provide
+ features to users. SIP also provides a registration function that
+ allows users to upload their current locations for use by proxy
+ servers. SIP runs on top of several different transport protocols.
+
+
+
+Rosenberg, et. al. Standards Track [Page 1]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Table of Contents
+
+ 1 Introduction ........................................ 8
+ 2 Overview of SIP Functionality ....................... 9
+ 3 Terminology ......................................... 10
+ 4 Overview of Operation ............................... 10
+ 5 Structure of the Protocol ........................... 18
+ 6 Definitions ......................................... 20
+ 7 SIP Messages ........................................ 26
+ 7.1 Requests ............................................ 27
+ 7.2 Responses ........................................... 28
+ 7.3 Header Fields ....................................... 29
+ 7.3.1 Header Field Format ................................. 30
+ 7.3.2 Header Field Classification ......................... 32
+ 7.3.3 Compact Form ........................................ 32
+ 7.4 Bodies .............................................. 33
+ 7.4.1 Message Body Type ................................... 33
+ 7.4.2 Message Body Length ................................. 33
+ 7.5 Framing SIP Messages ................................ 34
+ 8 General User Agent Behavior ......................... 34
+ 8.1 UAC Behavior ........................................ 35
+ 8.1.1 Generating the Request .............................. 35
+ 8.1.1.1 Request-URI ......................................... 35
+ 8.1.1.2 To .................................................. 36
+ 8.1.1.3 From ................................................ 37
+ 8.1.1.4 Call-ID ............................................. 37
+ 8.1.1.5 CSeq ................................................ 38
+ 8.1.1.6 Max-Forwards ........................................ 38
+ 8.1.1.7 Via ................................................. 39
+ 8.1.1.8 Contact ............................................. 40
+ 8.1.1.9 Supported and Require ............................... 40
+ 8.1.1.10 Additional Message Components ....................... 41
+ 8.1.2 Sending the Request ................................. 41
+ 8.1.3 Processing Responses ................................ 42
+ 8.1.3.1 Transaction Layer Errors ............................ 42
+ 8.1.3.2 Unrecognized Responses .............................. 42
+ 8.1.3.3 Vias ................................................ 43
+ 8.1.3.4 Processing 3xx Responses ............................ 43
+ 8.1.3.5 Processing 4xx Responses ............................ 45
+ 8.2 UAS Behavior ........................................ 46
+ 8.2.1 Method Inspection ................................... 46
+ 8.2.2 Header Inspection ................................... 46
+ 8.2.2.1 To and Request-URI .................................. 46
+ 8.2.2.2 Merged Requests ..................................... 47
+ 8.2.2.3 Require ............................................. 47
+ 8.2.3 Content Processing .................................. 48
+ 8.2.4 Applying Extensions ................................. 49
+ 8.2.5 Processing the Request .............................. 49
+
+
+
+Rosenberg, et. al. Standards Track [Page 2]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 8.2.6 Generating the Response ............................. 49
+ 8.2.6.1 Sending a Provisional Response ...................... 49
+ 8.2.6.2 Headers and Tags .................................... 50
+ 8.2.7 Stateless UAS Behavior .............................. 50
+ 8.3 Redirect Servers .................................... 51
+ 9 Canceling a Request ................................. 53
+ 9.1 Client Behavior ..................................... 53
+ 9.2 Server Behavior ..................................... 55
+ 10 Registrations ....................................... 56
+ 10.1 Overview ............................................ 56
+ 10.2 Constructing the REGISTER Request ................... 57
+ 10.2.1 Adding Bindings ..................................... 59
+ 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60
+ 10.2.1.2 Preferences among Contact Addresses ................. 61
+ 10.2.2 Removing Bindings ................................... 61
+ 10.2.3 Fetching Bindings ................................... 61
+ 10.2.4 Refreshing Bindings ................................. 61
+ 10.2.5 Setting the Internal Clock .......................... 62
+ 10.2.6 Discovering a Registrar ............................. 62
+ 10.2.7 Transmitting a Request .............................. 62
+ 10.2.8 Error Responses ..................................... 63
+ 10.3 Processing REGISTER Requests ........................ 63
+ 11 Querying for Capabilities ........................... 66
+ 11.1 Construction of OPTIONS Request ..................... 67
+ 11.2 Processing of OPTIONS Request ....................... 68
+ 12 Dialogs ............................................. 69
+ 12.1 Creation of a Dialog ................................ 70
+ 12.1.1 UAS behavior ........................................ 70
+ 12.1.2 UAC Behavior ........................................ 71
+ 12.2 Requests within a Dialog ............................ 72
+ 12.2.1 UAC Behavior ........................................ 73
+ 12.2.1.1 Generating the Request .............................. 73
+ 12.2.1.2 Processing the Responses ............................ 75
+ 12.2.2 UAS Behavior ........................................ 76
+ 12.3 Termination of a Dialog ............................. 77
+ 13 Initiating a Session ................................ 77
+ 13.1 Overview ............................................ 77
+ 13.2 UAC Processing ...................................... 78
+ 13.2.1 Creating the Initial INVITE ......................... 78
+ 13.2.2 Processing INVITE Responses ......................... 81
+ 13.2.2.1 1xx Responses ....................................... 81
+ 13.2.2.2 3xx Responses ....................................... 81
+ 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81
+ 13.2.2.4 2xx Responses ....................................... 82
+ 13.3 UAS Processing ...................................... 83
+ 13.3.1 Processing of the INVITE ............................ 83
+ 13.3.1.1 Progress ............................................ 84
+ 13.3.1.2 The INVITE is Redirected ............................ 84
+
+
+
+Rosenberg, et. al. Standards Track [Page 3]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 13.3.1.3 The INVITE is Rejected .............................. 85
+ 13.3.1.4 The INVITE is Accepted .............................. 85
+ 14 Modifying an Existing Session ....................... 86
+ 14.1 UAC Behavior ........................................ 86
+ 14.2 UAS Behavior ........................................ 88
+ 15 Terminating a Session ............................... 89
+ 15.1 Terminating a Session with a BYE Request ............ 90
+ 15.1.1 UAC Behavior ........................................ 90
+ 15.1.2 UAS Behavior ........................................ 91
+ 16 Proxy Behavior ...................................... 91
+ 16.1 Overview ............................................ 91
+ 16.2 Stateful Proxy ...................................... 92
+ 16.3 Request Validation .................................. 94
+ 16.4 Route Information Preprocessing ..................... 96
+ 16.5 Determining Request Targets ......................... 97
+ 16.6 Request Forwarding .................................. 99
+ 16.7 Response Processing ................................. 107
+ 16.8 Processing Timer C .................................. 114
+ 16.9 Handling Transport Errors ........................... 115
+ 16.10 CANCEL Processing ................................... 115
+ 16.11 Stateless Proxy ..................................... 116
+ 16.12 Summary of Proxy Route Processing ................... 118
+ 16.12.1 Examples ............................................ 118
+ 16.12.1.1 Basic SIP Trapezoid ................................. 118
+ 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120
+ 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121
+ 17 Transactions ........................................ 122
+ 17.1 Client Transaction .................................. 124
+ 17.1.1 INVITE Client Transaction ........................... 125
+ 17.1.1.1 Overview of INVITE Transaction ...................... 125
+ 17.1.1.2 Formal Description .................................. 125
+ 17.1.1.3 Construction of the ACK Request ..................... 129
+ 17.1.2 Non-INVITE Client Transaction ....................... 130
+ 17.1.2.1 Overview of the non-INVITE Transaction .............. 130
+ 17.1.2.2 Formal Description .................................. 131
+ 17.1.3 Matching Responses to Client Transactions ........... 132
+ 17.1.4 Handling Transport Errors ........................... 133
+ 17.2 Server Transaction .................................. 134
+ 17.2.1 INVITE Server Transaction ........................... 134
+ 17.2.2 Non-INVITE Server Transaction ....................... 137
+ 17.2.3 Matching Requests to Server Transactions ............ 138
+ 17.2.4 Handling Transport Errors ........................... 141
+ 18 Transport ........................................... 141
+ 18.1 Clients ............................................. 142
+ 18.1.1 Sending Requests .................................... 142
+ 18.1.2 Receiving Responses ................................. 144
+ 18.2 Servers ............................................. 145
+ 18.2.1 Receiving Requests .................................. 145
+
+
+
+Rosenberg, et. al. Standards Track [Page 4]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 18.2.2 Sending Responses ................................... 146
+ 18.3 Framing ............................................. 147
+ 18.4 Error Handling ...................................... 147
+ 19 Common Message Components ........................... 147
+ 19.1 SIP and SIPS Uniform Resource Indicators ............ 148
+ 19.1.1 SIP and SIPS URI Components ......................... 148
+ 19.1.2 Character Escaping Requirements ..................... 152
+ 19.1.3 Example SIP and SIPS URIs ........................... 153
+ 19.1.4 URI Comparison ...................................... 153
+ 19.1.5 Forming Requests from a URI ......................... 156
+ 19.1.6 Relating SIP URIs and tel URLs ...................... 157
+ 19.2 Option Tags ......................................... 158
+ 19.3 Tags ................................................ 159
+ 20 Header Fields ....................................... 159
+ 20.1 Accept .............................................. 161
+ 20.2 Accept-Encoding ..................................... 163
+ 20.3 Accept-Language ..................................... 164
+ 20.4 Alert-Info .......................................... 164
+ 20.5 Allow ............................................... 165
+ 20.6 Authentication-Info ................................. 165
+ 20.7 Authorization ....................................... 165
+ 20.8 Call-ID ............................................. 166
+ 20.9 Call-Info ........................................... 166
+ 20.10 Contact ............................................. 167
+ 20.11 Content-Disposition ................................. 168
+ 20.12 Content-Encoding .................................... 169
+ 20.13 Content-Language .................................... 169
+ 20.14 Content-Length ...................................... 169
+ 20.15 Content-Type ........................................ 170
+ 20.16 CSeq ................................................ 170
+ 20.17 Date ................................................ 170
+ 20.18 Error-Info .......................................... 171
+ 20.19 Expires ............................................. 171
+ 20.20 From ................................................ 172
+ 20.21 In-Reply-To ......................................... 172
+ 20.22 Max-Forwards ........................................ 173
+ 20.23 Min-Expires ......................................... 173
+ 20.24 MIME-Version ........................................ 173
+ 20.25 Organization ........................................ 174
+ 20.26 Priority ............................................ 174
+ 20.27 Proxy-Authenticate .................................. 174
+ 20.28 Proxy-Authorization ................................. 175
+ 20.29 Proxy-Require ....................................... 175
+ 20.30 Record-Route ........................................ 175
+ 20.31 Reply-To ............................................ 176
+ 20.32 Require ............................................. 176
+ 20.33 Retry-After ......................................... 176
+ 20.34 Route ............................................... 177
+
+
+
+Rosenberg, et. al. Standards Track [Page 5]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 20.35 Server .............................................. 177
+ 20.36 Subject ............................................. 177
+ 20.37 Supported ........................................... 178
+ 20.38 Timestamp ........................................... 178
+ 20.39 To .................................................. 178
+ 20.40 Unsupported ......................................... 179
+ 20.41 User-Agent .......................................... 179
+ 20.42 Via ................................................. 179
+ 20.43 Warning ............................................. 180
+ 20.44 WWW-Authenticate .................................... 182
+ 21 Response Codes ...................................... 182
+ 21.1 Provisional 1xx ..................................... 182
+ 21.1.1 100 Trying .......................................... 183
+ 21.1.2 180 Ringing ......................................... 183
+ 21.1.3 181 Call Is Being Forwarded ......................... 183
+ 21.1.4 182 Queued .......................................... 183
+ 21.1.5 183 Session Progress ................................ 183
+ 21.2 Successful 2xx ...................................... 183
+ 21.2.1 200 OK .............................................. 183
+ 21.3 Redirection 3xx ..................................... 184
+ 21.3.1 300 Multiple Choices ................................ 184
+ 21.3.2 301 Moved Permanently ............................... 184
+ 21.3.3 302 Moved Temporarily ............................... 184
+ 21.3.4 305 Use Proxy ....................................... 185
+ 21.3.5 380 Alternative Service ............................. 185
+ 21.4 Request Failure 4xx ................................. 185
+ 21.4.1 400 Bad Request ..................................... 185
+ 21.4.2 401 Unauthorized .................................... 185
+ 21.4.3 402 Payment Required ................................ 186
+ 21.4.4 403 Forbidden ....................................... 186
+ 21.4.5 404 Not Found ....................................... 186
+ 21.4.6 405 Method Not Allowed .............................. 186
+ 21.4.7 406 Not Acceptable .................................. 186
+ 21.4.8 407 Proxy Authentication Required ................... 186
+ 21.4.9 408 Request Timeout ................................. 186
+ 21.4.10 410 Gone ............................................ 187
+ 21.4.11 413 Request Entity Too Large ........................ 187
+ 21.4.12 414 Request-URI Too Long ............................ 187
+ 21.4.13 415 Unsupported Media Type .......................... 187
+ 21.4.14 416 Unsupported URI Scheme .......................... 187
+ 21.4.15 420 Bad Extension ................................... 187
+ 21.4.16 421 Extension Required .............................. 188
+ 21.4.17 423 Interval Too Brief .............................. 188
+ 21.4.18 480 Temporarily Unavailable ......................... 188
+ 21.4.19 481 Call/Transaction Does Not Exist ................. 188
+ 21.4.20 482 Loop Detected ................................... 188
+ 21.4.21 483 Too Many Hops ................................... 189
+ 21.4.22 484 Address Incomplete .............................. 189
+
+
+
+Rosenberg, et. al. Standards Track [Page 6]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 21.4.23 485 Ambiguous ....................................... 189
+ 21.4.24 486 Busy Here ....................................... 189
+ 21.4.25 487 Request Terminated .............................. 190
+ 21.4.26 488 Not Acceptable Here ............................. 190
+ 21.4.27 491 Request Pending ................................. 190
+ 21.4.28 493 Undecipherable .................................. 190
+ 21.5 Server Failure 5xx .................................. 190
+ 21.5.1 500 Server Internal Error ........................... 190
+ 21.5.2 501 Not Implemented ................................. 191
+ 21.5.3 502 Bad Gateway ..................................... 191
+ 21.5.4 503 Service Unavailable ............................. 191
+ 21.5.5 504 Server Time-out ................................. 191
+ 21.5.6 505 Version Not Supported ........................... 192
+ 21.5.7 513 Message Too Large ............................... 192
+ 21.6 Global Failures 6xx ................................. 192
+ 21.6.1 600 Busy Everywhere ................................. 192
+ 21.6.2 603 Decline ......................................... 192
+ 21.6.3 604 Does Not Exist Anywhere ......................... 192
+ 21.6.4 606 Not Acceptable .................................. 192
+ 22 Usage of HTTP Authentication ........................ 193
+ 22.1 Framework ........................................... 193
+ 22.2 User-to-User Authentication ......................... 195
+ 22.3 Proxy-to-User Authentication ........................ 197
+ 22.4 The Digest Authentication Scheme .................... 199
+ 23 S/MIME .............................................. 201
+ 23.1 S/MIME Certificates ................................. 201
+ 23.2 S/MIME Key Exchange ................................. 202
+ 23.3 Securing MIME bodies ................................ 205
+ 23.4 SIP Header Privacy and Integrity using S/MIME:
+ Tunneling SIP ....................................... 207
+ 23.4.1 Integrity and Confidentiality Properties of SIP
+ Headers ............................................. 207
+ 23.4.1.1 Integrity ........................................... 207
+ 23.4.1.2 Confidentiality ..................................... 208
+ 23.4.2 Tunneling Integrity and Authentication .............. 209
+ 23.4.3 Tunneling Encryption ................................ 211
+ 24 Examples ............................................ 213
+ 24.1 Registration ........................................ 213
+ 24.2 Session Setup ....................................... 214
+ 25 Augmented BNF for the SIP Protocol .................. 219
+ 25.1 Basic Rules ......................................... 219
+ 26 Security Considerations: Threat Model and Security
+ Usage Recommendations ............................... 232
+ 26.1 Attacks and Threat Models ........................... 233
+ 26.1.1 Registration Hijacking .............................. 233
+ 26.1.2 Impersonating a Server .............................. 234
+ 26.1.3 Tampering with Message Bodies ....................... 235
+ 26.1.4 Tearing Down Sessions ............................... 235
+
+
+
+Rosenberg, et. al. Standards Track [Page 7]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 26.1.5 Denial of Service and Amplification ................. 236
+ 26.2 Security Mechanisms ................................. 237
+ 26.2.1 Transport and Network Layer Security ................ 238
+ 26.2.2 SIPS URI Scheme ..................................... 239
+ 26.2.3 HTTP Authentication ................................. 240
+ 26.2.4 S/MIME .............................................. 240
+ 26.3 Implementing Security Mechanisms .................... 241
+ 26.3.1 Requirements for Implementers of SIP ................ 241
+ 26.3.2 Security Solutions .................................. 242
+ 26.3.2.1 Registration ........................................ 242
+ 26.3.2.2 Interdomain Requests ................................ 243
+ 26.3.2.3 Peer-to-Peer Requests ............................... 245
+ 26.3.2.4 DoS Protection ...................................... 246
+ 26.4 Limitations ......................................... 247
+ 26.4.1 HTTP Digest ......................................... 247
+ 26.4.2 S/MIME .............................................. 248
+ 26.4.3 TLS ................................................. 249
+ 26.4.4 SIPS URIs ........................................... 249
+ 26.5 Privacy ............................................. 251
+ 27 IANA Considerations ................................. 252
+ 27.1 Option Tags ......................................... 252
+ 27.2 Warn-Codes .......................................... 252
+ 27.3 Header Field Names .................................. 253
+ 27.4 Method and Response Codes ........................... 253
+ 27.5 The "message/sip" MIME type. ....................... 254
+ 27.6 New Content-Disposition Parameter Registrations ..... 255
+ 28 Changes From RFC 2543 ............................... 255
+ 28.1 Major Functional Changes ............................ 255
+ 28.2 Minor Functional Changes ............................ 260
+ 29 Normative References ................................ 261
+ 30 Informative References .............................. 262
+ A Table of Timer Values ............................... 265
+ Acknowledgments ................................................ 266
+ Authors' Addresses ............................................. 267
+ Full Copyright Statement ....................................... 269
+
+1 Introduction
+
+ There are many applications of the Internet that require the creation
+ and management of a session, where a session is considered an
+ exchange of data between an association of participants. The
+ implementation of these applications is complicated by the practices
+ of participants: users may move between endpoints, they may be
+ addressable by multiple names, and they may communicate in several
+ different media - sometimes simultaneously. Numerous protocols have
+ been authored that carry various forms of real-time multimedia
+ session data such as voice, video, or text messages. The Session
+ Initiation Protocol (SIP) works in concert with these protocols by
+
+
+
+Rosenberg, et. al. Standards Track [Page 8]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ enabling Internet endpoints (called user agents) to discover one
+ another and to agree on a characterization of a session they would
+ like to share. For locating prospective session participants, and
+ for other functions, SIP enables the creation of an infrastructure of
+ network hosts (called proxy servers) to which user agents can send
+ registrations, invitations to sessions, and other requests. SIP is
+ an agile, general-purpose tool for creating, modifying, and
+ terminating sessions that works independently of underlying transport
+ protocols and without dependency on the type of session that is being
+ established.
+
+2 Overview of SIP Functionality
+
+ SIP is an application-layer control protocol that can establish,
+ modify, and terminate multimedia sessions (conferences) such as
+ Internet telephony calls. SIP can also invite participants to
+ already existing sessions, such as multicast conferences. Media can
+ be added to (and removed from) an existing session. SIP
+ transparently supports name mapping and redirection services, which
+ supports personal mobility [27] - users can maintain a single
+ externally visible identifier regardless of their network location.
+
+ SIP supports five facets of establishing and terminating multimedia
+ communications:
+
+ User location: determination of the end system to be used for
+ communication;
+
+ User availability: determination of the willingness of the called
+ party to engage in communications;
+
+ User capabilities: determination of the media and media parameters
+ to be used;
+
+ Session setup: "ringing", establishment of session parameters at
+ both called and calling party;
+
+ Session management: including transfer and termination of
+ sessions, modifying session parameters, and invoking
+ services.
+
+ SIP is not a vertically integrated communications system. SIP is
+ rather a component that can be used with other IETF protocols to
+ build a complete multimedia architecture. Typically, these
+ architectures will include protocols such as the Real-time Transport
+ Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
+ providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
+ 2326 [29]) for controlling delivery of streaming media, the Media
+
+
+
+Rosenberg, et. al. Standards Track [Page 9]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
+ gateways to the Public Switched Telephone Network (PSTN), and the
+ Session Description Protocol (SDP) (RFC 2327 [1]) for describing
+ multimedia sessions. Therefore, SIP should be used in conjunction
+ with other protocols in order to provide complete services to the
+ users. However, the basic functionality and operation of SIP does
+ not depend on any of these protocols.
+
+ SIP does not provide services. Rather, SIP provides primitives that
+ can be used to implement different services. For example, SIP can
+ locate a user and deliver an opaque object to his current location.
+ If this primitive is used to deliver a session description written in
+ SDP, for instance, the endpoints can agree on the parameters of a
+ session. If the same primitive is used to deliver a photo of the
+ caller as well as the session description, a "caller ID" service can
+ be easily implemented. As this example shows, a single primitive is
+ typically used to provide several different services.
+
+ SIP does not offer conference control services such as floor control
+ or voting and does not prescribe how a conference is to be managed.
+ SIP can be used to initiate a session that uses some other conference
+ control protocol. Since SIP messages and the sessions they establish
+ can pass through entirely different networks, SIP cannot, and does
+ not, provide any kind of network resource reservation capabilities.
+
+ The nature of the services provided make security particularly
+ important. To that end, SIP provides a suite of security services,
+ which include denial-of-service prevention, authentication (both user
+ to user and proxy to user), integrity protection, and encryption and
+ privacy services.
+
+ SIP works with both IPv4 and IPv6.
+
+3 Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
+ RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
+ described in BCP 14, RFC 2119 [2] and indicate requirement levels for
+ compliant SIP implementations.
+
+4 Overview of Operation
+
+ This section introduces the basic operations of SIP using simple
+ examples. This section is tutorial in nature and does not contain
+ any normative statements.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 10]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The first example shows the basic functions of SIP: location of an
+ end point, signal of a desire to communicate, negotiation of session
+ parameters to establish the session, and teardown of the session once
+ established.
+
+ Figure 1 shows a typical example of a SIP message exchange between
+ two users, Alice and Bob. (Each message is labeled with the letter
+ "F" and a number for reference by the text.) In this example, Alice
+ uses a SIP application on her PC (referred to as a softphone) to call
+ Bob on his SIP phone over the Internet. Also shown are two SIP proxy
+ servers that act on behalf of Alice and Bob to facilitate the session
+ establishment. This typical arrangement is often referred to as the
+ "SIP trapezoid" as shown by the geometric shape of the dotted lines
+ in Figure 1.
+
+ Alice "calls" Bob using his SIP identity, a type of Uniform Resource
+ Identifier (URI) called a SIP URI. SIP URIs are defined in Section
+ 19.1. It has a similar form to an email address, typically
+ containing a username and a host name. In this case, it is
+ sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP
+ service provider. Alice has a SIP URI of sip:alice@atlanta.com.
+ Alice might have typed in Bob's URI or perhaps clicked on a hyperlink
+ or an entry in an address book. SIP also provides a secure URI,
+ called a SIPS URI. An example would be sips:bob@biloxi.com. A call
+ made to a SIPS URI guarantees that secure, encrypted transport
+ (namely TLS) is used to carry all SIP messages from the caller to the
+ domain of the callee. From there, the request is sent securely to
+ the callee, but with security mechanisms that depend on the policy of
+ the domain of the callee.
+
+ SIP is based on an HTTP-like request/response transaction model.
+ Each transaction consists of a request that invokes a particular
+ method, or function, on the server and at least one response. In
+ this example, the transaction begins with Alice's softphone sending
+ an INVITE request addressed to Bob's SIP URI. INVITE is an example
+ of a SIP method that specifies the action that the requestor (Alice)
+ wants the server (Bob) to take. The INVITE request contains a number
+ of header fields. Header fields are named attributes that provide
+ additional information about a message. The ones present in an
+ INVITE include a unique identifier for the call, the destination
+ address, Alice's address, and information about the type of session
+ that Alice wishes to establish with Bob. The INVITE (message F1 in
+ Figure 1) might look like this:
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 11]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ atlanta.com . . . biloxi.com
+ . proxy proxy .
+ . .
+ Alice's . . . . . . . . . . . . . . . . . . . . Bob's
+ softphone SIP Phone
+ | | | |
+ | INVITE F1 | | |
+ |--------------->| INVITE F2 | |
+ | 100 Trying F3 |--------------->| INVITE F4 |
+ |<---------------| 100 Trying F5 |--------------->|
+ | |<-------------- | 180 Ringing F6 |
+ | | 180 Ringing F7 |<---------------|
+ | 180 Ringing F8 |<---------------| 200 OK F9 |
+ |<---------------| 200 OK F10 |<---------------|
+ | 200 OK F11 |<---------------| |
+ |<---------------| | |
+ | ACK F12 |
+ |------------------------------------------------->|
+ | Media Session |
+ |<================================================>|
+ | BYE F13 |
+ |<-------------------------------------------------|
+ | 200 OK F14 |
+ |------------------------------------------------->|
+ | |
+
+ Figure 1: SIP session setup example with SIP trapezoid
+
+ INVITE sip:bob@biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
+ Max-Forwards: 70
+ To: Bob <sip:bob@biloxi.com>
+ From: Alice <sip:alice@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710@pc33.atlanta.com
+ CSeq: 314159 INVITE
+ Contact: <sip:alice@pc33.atlanta.com>
+ Content-Type: application/sdp
+ Content-Length: 142
+
+ (Alice's SDP not shown)
+
+ The first line of the text-encoded message contains the method name
+ (INVITE). The lines that follow are a list of header fields. This
+ example contains a minimum required set. The header fields are
+ briefly described below:
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 12]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Via contains the address (pc33.atlanta.com) at which Alice is
+ expecting to receive responses to this request. It also contains a
+ branch parameter that identifies this transaction.
+
+ To contains a display name (Bob) and a SIP or SIPS URI
+ (sip:bob@biloxi.com) towards which the request was originally
+ directed. Display names are described in RFC 2822 [3].
+
+ From also contains a display name (Alice) and a SIP or SIPS URI
+ (sip:alice@atlanta.com) that indicate the originator of the request.
+ This header field also has a tag parameter containing a random string
+ (1928301774) that was added to the URI by the softphone. It is used
+ for identification purposes.
+
+ Call-ID contains a globally unique identifier for this call,
+ generated by the combination of a random string and the softphone's
+ host name or IP address. The combination of the To tag, From tag,
+ and Call-ID completely defines a peer-to-peer SIP relationship
+ between Alice and Bob and is referred to as a dialog.
+
+ CSeq or Command Sequence contains an integer and a method name. The
+ CSeq number is incremented for each new request within a dialog and
+ is a traditional sequence number.
+
+ Contact contains a SIP or SIPS URI that represents a direct route to
+ contact Alice, usually composed of a username at a fully qualified
+ domain name (FQDN). While an FQDN is preferred, many end systems do
+ not have registered domain names, so IP addresses are permitted.
+ While the Via header field tells other elements where to send the
+ response, the Contact header field tells other elements where to send
+ future requests.
+
+ Max-Forwards serves to limit the number of hops a request can make on
+ the way to its destination. It consists of an integer that is
+ decremented by one at each hop.
+
+ Content-Type contains a description of the message body (not shown).
+
+ Content-Length contains an octet (byte) count of the message body.
+
+ The complete set of SIP header fields is defined in Section 20.
+
+ The details of the session, such as the type of media, codec, or
+ sampling rate, are not described using SIP. Rather, the body of a
+ SIP message contains a description of the session, encoded in some
+ other protocol format. One such format is the Session Description
+ Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 13]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ example) is carried by the SIP message in a way that is analogous to
+ a document attachment being carried by an email message, or a web
+ page being carried in an HTTP message.
+
+ Since the softphone does not know the location of Bob or the SIP
+ server in the biloxi.com domain, the softphone sends the INVITE to
+ the SIP server that serves Alice's domain, atlanta.com. The address
+ of the atlanta.com SIP server could have been configured in Alice's
+ softphone, or it could have been discovered by DHCP, for example.
+
+ The atlanta.com SIP server is a type of SIP server known as a proxy
+ server. A proxy server receives SIP requests and forwards them on
+ behalf of the requestor. In this example, the proxy server receives
+ the INVITE request and sends a 100 (Trying) response back to Alice's
+ softphone. The 100 (Trying) response indicates that the INVITE has
+ been received and that the proxy is working on her behalf to route
+ the INVITE to the destination. Responses in SIP use a three-digit
+ code followed by a descriptive phrase. This response contains the
+ same To, From, Call-ID, CSeq and branch parameter in the Via as the
+ INVITE, which allows Alice's softphone to correlate this response to
+ the sent INVITE. The atlanta.com proxy server locates the proxy
+ server at biloxi.com, possibly by performing a particular type of DNS
+ (Domain Name Service) lookup to find the SIP server that serves the
+ biloxi.com domain. This is described in [4]. As a result, it
+ obtains the IP address of the biloxi.com proxy server and forwards,
+ or proxies, the INVITE request there. Before forwarding the request,
+ the atlanta.com proxy server adds an additional Via header field
+ value that contains its own address (the INVITE already contains
+ Alice's address in the first Via). The biloxi.com proxy server
+ receives the INVITE and responds with a 100 (Trying) response back to
+ the atlanta.com proxy server to indicate that it has received the
+ INVITE and is processing the request. The proxy server consults a
+ database, generically called a location service, that contains the
+ current IP address of Bob. (We shall see in the next section how
+ this database can be populated.) The biloxi.com proxy server adds
+ another Via header field value with its own address to the INVITE and
+ proxies it to Bob's SIP phone.
+
+ Bob's SIP phone receives the INVITE and alerts Bob to the incoming
+ call from Alice so that Bob can decide whether to answer the call,
+ that is, Bob's phone rings. Bob's SIP phone indicates this in a 180
+ (Ringing) response, which is routed back through the two proxies in
+ the reverse direction. Each proxy uses the Via header field to
+ determine where to send the response and removes its own address from
+ the top. As a result, although DNS and location service lookups were
+ required to route the initial INVITE, the 180 (Ringing) response can
+ be returned to the caller without lookups or without state being
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 14]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ maintained in the proxies. This also has the desirable property that
+ each proxy that sees the INVITE will also see all responses to the
+ INVITE.
+
+ When Alice's softphone receives the 180 (Ringing) response, it passes
+ this information to Alice, perhaps using an audio ringback tone or by
+ displaying a message on Alice's screen.
+
+ In this example, Bob decides to answer the call. When he picks up
+ the handset, his SIP phone sends a 200 (OK) response to indicate that
+ the call has been answered. The 200 (OK) contains a message body
+ with the SDP media description of the type of session that Bob is
+ willing to establish with Alice. As a result, there is a two-phase
+ exchange of SDP messages: Alice sent one to Bob, and Bob sent one
+ back to Alice. This two-phase exchange provides basic negotiation
+ capabilities and is based on a simple offer/answer model of SDP
+ exchange. If Bob did not wish to answer the call or was busy on
+ another call, an error response would have been sent instead of the
+ 200 (OK), which would have resulted in no media session being
+ established. The complete list of SIP response codes is in Section
+ 21. The 200 (OK) (message F9 in Figure 1) might look like this as
+ Bob sends it out:
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/UDP server10.biloxi.com
+ ;branch=z9hG4bKnashds8;received=192.0.2.3
+ Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
+ ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
+ Via: SIP/2.0/UDP pc33.atlanta.com
+ ;branch=z9hG4bK776asdhds ;received=192.0.2.1
+ To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+ From: Alice <sip:alice@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710@pc33.atlanta.com
+ CSeq: 314159 INVITE
+ Contact: <sip:bob@192.0.2.4>
+ Content-Type: application/sdp
+ Content-Length: 131
+
+ (Bob's SDP not shown)
+
+ The first line of the response contains the response code (200) and
+ the reason phrase (OK). The remaining lines contain header fields.
+ The Via, To, From, Call-ID, and CSeq header fields are copied from
+ the INVITE request. (There are three Via header field values - one
+ added by Alice's SIP phone, one added by the atlanta.com proxy, and
+ one added by the biloxi.com proxy.) Bob's SIP phone has added a tag
+ parameter to the To header field. This tag will be incorporated by
+ both endpoints into the dialog and will be included in all future
+
+
+
+Rosenberg, et. al. Standards Track [Page 15]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ requests and responses in this call. The Contact header field
+ contains a URI at which Bob can be directly reached at his SIP phone.
+ The Content-Type and Content-Length refer to the message body (not
+ shown) that contains Bob's SDP media information.
+
+ In addition to DNS and location service lookups shown in this
+ example, proxy servers can make flexible "routing decisions" to
+ decide where to send a request. For example, if Bob's SIP phone
+ returned a 486 (Busy Here) response, the biloxi.com proxy server
+ could proxy the INVITE to Bob's voicemail server. A proxy server can
+ also send an INVITE to a number of locations at the same time. This
+ type of parallel search is known as forking.
+
+ In this case, the 200 (OK) is routed back through the two proxies and
+ is received by Alice's softphone, which then stops the ringback tone
+ and indicates that the call has been answered. Finally, Alice's
+ softphone sends an acknowledgement message, ACK, to Bob's SIP phone
+ to confirm the reception of the final response (200 (OK)). In this
+ example, the ACK is sent directly from Alice's softphone to Bob's SIP
+ phone, bypassing the two proxies. This occurs because the endpoints
+ have learned each other's address from the Contact header fields
+ through the INVITE/200 (OK) exchange, which was not known when the
+ initial INVITE was sent. The lookups performed by the two proxies
+ are no longer needed, so the proxies drop out of the call flow. This
+ completes the INVITE/200/ACK three-way handshake used to establish
+ SIP sessions. Full details on session setup are in Section 13.
+
+ Alice and Bob's media session has now begun, and they send media
+ packets using the format to which they agreed in the exchange of SDP.
+ In general, the end-to-end media packets take a different path from
+ the SIP signaling messages.
+
+ During the session, either Alice or Bob may decide to change the
+ characteristics of the media session. This is accomplished by
+ sending a re-INVITE containing a new media description. This re-
+ INVITE references the existing dialog so that the other party knows
+ that it is to modify an existing session instead of establishing a
+ new session. The other party sends a 200 (OK) to accept the change.
+ The requestor responds to the 200 (OK) with an ACK. If the other
+ party does not accept the change, he sends an error response such as
+ 488 (Not Acceptable Here), which also receives an ACK. However, the
+ failure of the re-INVITE does not cause the existing call to fail -
+ the session continues using the previously negotiated
+ characteristics. Full details on session modification are in Section
+ 14.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 16]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ At the end of the call, Bob disconnects (hangs up) first and
+ generates a BYE message. This BYE is routed directly to Alice's
+ softphone, again bypassing the proxies. Alice confirms receipt of
+ the BYE with a 200 (OK) response, which terminates the session and
+ the BYE transaction. No ACK is sent - an ACK is only sent in
+ response to a response to an INVITE request. The reasons for this
+ special handling for INVITE will be discussed later, but relate to
+ the reliability mechanisms in SIP, the length of time it can take for
+ a ringing phone to be answered, and forking. For this reason,
+ request handling in SIP is often classified as either INVITE or non-
+ INVITE, referring to all other methods besides INVITE. Full details
+ on session termination are in Section 15.
+
+ Section 24.2 describes the messages shown in Figure 1 in full.
+
+ In some cases, it may be useful for proxies in the SIP signaling path
+ to see all the messaging between the endpoints for the duration of
+ the session. For example, if the biloxi.com proxy server wished to
+ remain in the SIP messaging path beyond the initial INVITE, it would
+ add to the INVITE a required routing header field known as Record-
+ Route that contained a URI resolving to the hostname or IP address of
+ the proxy. This information would be received by both Bob's SIP
+ phone and (due to the Record-Route header field being passed back in
+ the 200 (OK)) Alice's softphone and stored for the duration of the
+ dialog. The biloxi.com proxy server would then receive and proxy the
+ ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently
+ decide to receive subsequent messages, and those messages will pass
+ through all proxies that elect to receive it. This capability is
+ frequently used for proxies that are providing mid-call features.
+
+ Registration is another common operation in SIP. Registration is one
+ way that the biloxi.com server can learn the current location of Bob.
+ Upon initialization, and at periodic intervals, Bob's SIP phone sends
+ REGISTER messages to a server in the biloxi.com domain known as a SIP
+ registrar. The REGISTER messages associate Bob's SIP or SIPS URI
+ (sip:bob@biloxi.com) with the machine into which he is currently
+ logged (conveyed as a SIP or SIPS URI in the Contact header field).
+ The registrar writes this association, also called a binding, to a
+ database, called the location service, where it can be used by the
+ proxy in the biloxi.com domain. Often, a registrar server for a
+ domain is co-located with the proxy for that domain. It is an
+ important concept that the distinction between types of SIP servers
+ is logical, not physical.
+
+ Bob is not limited to registering from a single device. For example,
+ both his SIP phone at home and the one in the office could send
+ registrations. This information is stored together in the location
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 17]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ service and allows a proxy to perform various types of searches to
+ locate Bob. Similarly, more than one user can be registered on a
+ single device at the same time.
+
+ The location service is just an abstract concept. It generally
+ contains information that allows a proxy to input a URI and receive a
+ set of zero or more URIs that tell the proxy where to send the
+ request. Registrations are one way to create this information, but
+ not the only way. Arbitrary mapping functions can be configured at
+ the discretion of the administrator.
+
+ Finally, it is important to note that in SIP, registration is used
+ for routing incoming SIP requests and has no role in authorizing
+ outgoing requests. Authorization and authentication are handled in
+ SIP either on a request-by-request basis with a challenge/response
+ mechanism, or by using a lower layer scheme as discussed in Section
+ 26.
+
+ The complete set of SIP message details for this registration example
+ is in Section 24.1.
+
+ Additional operations in SIP, such as querying for the capabilities
+ of a SIP server or client using OPTIONS, or canceling a pending
+ request using CANCEL, will be introduced in later sections.
+
+5 Structure of the Protocol
+
+ SIP is structured as a layered protocol, which means that its
+ behavior is described in terms of a set of fairly independent
+ processing stages with only a loose coupling between each stage. The
+ protocol behavior is described as layers for the purpose of
+ presentation, allowing the description of functions common across
+ elements in a single section. It does not dictate an implementation
+ in any way. When we say that an element "contains" a layer, we mean
+ it is compliant to the set of rules defined by that layer.
+
+ Not every element specified by the protocol contains every layer.
+ Furthermore, the elements specified by SIP are logical elements, not
+ physical ones. A physical realization can choose to act as different
+ logical elements, perhaps even on a transaction-by-transaction basis.
+
+ The lowest layer of SIP is its syntax and encoding. Its encoding is
+ specified using an augmented Backus-Naur Form grammar (BNF). The
+ complete BNF is specified in Section 25; an overview of a SIP
+ message's structure can be found in Section 7.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 18]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The second layer is the transport layer. It defines how a client
+ sends requests and receives responses and how a server receives
+ requests and sends responses over the network. All SIP elements
+ contain a transport layer. The transport layer is described in
+ Section 18.
+
+ The third layer is the transaction layer. Transactions are a
+ fundamental component of SIP. A transaction is a request sent by a
+ client transaction (using the transport layer) to a server
+ transaction, along with all responses to that request sent from the
+ server transaction back to the client. The transaction layer handles
+ application-layer retransmissions, matching of responses to requests,
+ and application-layer timeouts. Any task that a user agent client
+ (UAC) accomplishes takes place using a series of transactions.
+ Discussion of transactions can be found in Section 17. User agents
+ contain a transaction layer, as do stateful proxies. Stateless
+ proxies do not contain a transaction layer. The transaction layer
+ has a client component (referred to as a client transaction) and a
+ server component (referred to as a server transaction), each of which
+ are represented by a finite state machine that is constructed to
+ process a particular request.
+
+ The layer above the transaction layer is called the transaction user
+ (TU). Each of the SIP entities, except the stateless proxy, is a
+ transaction user. When a TU wishes to send a request, it creates a
+ client transaction instance and passes it the request along with the
+ destination IP address, port, and transport to which to send the
+ request. A TU that creates a client transaction can also cancel it.
+ When a client cancels a transaction, it requests that the server stop
+ further processing, revert to the state that existed before the
+ transaction was initiated, and generate a specific error response to
+ that transaction. This is done with a CANCEL request, which
+ constitutes its own transaction, but references the transaction to be
+ cancelled (Section 9).
+
+ The SIP elements, that is, user agent clients and servers, stateless
+ and stateful proxies and registrars, contain a core that
+ distinguishes them from each other. Cores, except for the stateless
+ proxy, are transaction users. While the behavior of the UAC and UAS
+ cores depends on the method, there are some common rules for all
+ methods (Section 8). For a UAC, these rules govern the construction
+ of a request; for a UAS, they govern the processing of a request and
+ generating a response. Since registrations play an important role in
+ SIP, a UAS that handles a REGISTER is given the special name
+ registrar. Section 10 describes UAC and UAS core behavior for the
+ REGISTER method. Section 11 describes UAC and UAS core behavior for
+ the OPTIONS method, used for determining the capabilities of a UA.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 19]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Certain other requests are sent within a dialog. A dialog is a
+ peer-to-peer SIP relationship between two user agents that persists
+ for some time. The dialog facilitates sequencing of messages and
+ proper routing of requests between the user agents. The INVITE
+ method is the only way defined in this specification to establish a
+ dialog. When a UAC sends a request that is within the context of a
+ dialog, it follows the common UAC rules as discussed in Section 8 but
+ also the rules for mid-dialog requests. Section 12 discusses dialogs
+ and presents the procedures for their construction and maintenance,
+ in addition to construction of requests within a dialog.
+
+ The most important method in SIP is the INVITE method, which is used
+ to establish a session between participants. A session is a
+ collection of participants, and streams of media between them, for
+ the purposes of communication. Section 13 discusses how sessions are
+ initiated, resulting in one or more SIP dialogs. Section 14
+ discusses how characteristics of that session are modified through
+ the use of an INVITE request within a dialog. Finally, section 15
+ discusses how a session is terminated.
+
+ The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
+ entirely with the UA core (Section 9 describes cancellation, which
+ applies to both UA core and proxy core). Section 16 discusses the
+ proxy element, which facilitates routing of messages between user
+ agents.
+
+6 Definitions
+
+ The following terms have special significance for SIP.
+
+ Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
+ that points to a domain with a location service that can map
+ the URI to another URI where the user might be available.
+ Typically, the location service is populated through
+ registrations. An AOR is frequently thought of as the "public
+ address" of the user.
+
+ Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
+ logical entity that receives a request and processes it as a
+ user agent server (UAS). In order to determine how the request
+ should be answered, it acts as a user agent client (UAC) and
+ generates requests. Unlike a proxy server, it maintains dialog
+ state and must participate in all requests sent on the dialogs
+ it has established. Since it is a concatenation of a UAC and
+ UAS, no explicit definitions are needed for its behavior.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 20]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Call: A call is an informal term that refers to some communication
+ between peers, generally set up for the purposes of a
+ multimedia conversation.
+
+ Call Leg: Another name for a dialog [31]; no longer used in this
+ specification.
+
+ Call Stateful: A proxy is call stateful if it retains state for a
+ dialog from the initiating INVITE to the terminating BYE
+ request. A call stateful proxy is always transaction stateful,
+ but the converse is not necessarily true.
+
+ Client: A client is any network element that sends SIP requests
+ and receives SIP responses. Clients may or may not interact
+ directly with a human user. User agent clients and proxies are
+ clients.
+
+ Conference: A multimedia session (see below) that contains
+ multiple participants.
+
+ Core: Core designates the functions specific to a particular type
+ of SIP entity, i.e., specific to either a stateful or stateless
+ proxy, a user agent or registrar. All cores, except those for
+ the stateless proxy, are transaction users.
+
+ Dialog: A dialog is a peer-to-peer SIP relationship between two
+ UAs that persists for some time. A dialog is established by
+ SIP messages, such as a 2xx response to an INVITE request. A
+ dialog is identified by a call identifier, local tag, and a
+ remote tag. A dialog was formerly known as a call leg in RFC
+ 2543.
+
+ Downstream: A direction of message forwarding within a transaction
+ that refers to the direction that requests flow from the user
+ agent client to user agent server.
+
+ Final Response: A response that terminates a SIP transaction, as
+ opposed to a provisional response that does not. All 2xx, 3xx,
+ 4xx, 5xx and 6xx responses are final.
+
+ Header: A header is a component of a SIP message that conveys
+ information about the message. It is structured as a sequence
+ of header fields.
+
+ Header Field: A header field is a component of the SIP message
+ header. A header field can appear as one or more header field
+ rows. Header field rows consist of a header field name and zero
+ or more header field values. Multiple header field values on a
+
+
+
+Rosenberg, et. al. Standards Track [Page 21]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ given header field row are separated by commas. Some header
+ fields can only have a single header field value, and as a
+ result, always appear as a single header field row.
+
+ Header Field Value: A header field value is a single value; a
+ header field consists of zero or more header field values.
+
+ Home Domain: The domain providing service to a SIP user.
+ Typically, this is the domain present in the URI in the
+ address-of-record of a registration.
+
+ Informational Response: Same as a provisional response.
+
+ Initiator, Calling Party, Caller: The party initiating a session
+ (and dialog) with an INVITE request. A caller retains this
+ role from the time it sends the initial INVITE that established
+ a dialog until the termination of that dialog.
+
+ Invitation: An INVITE request.
+
+ Invitee, Invited User, Called Party, Callee: The party that
+ receives an INVITE request for the purpose of establishing a
+ new session. A callee retains this role from the time it
+ receives the INVITE until the termination of the dialog
+ established by that INVITE.
+
+ Location Service: A location service is used by a SIP redirect or
+ proxy server to obtain information about a callee's possible
+ location(s). It contains a list of bindings of address-of-
+ record keys to zero or more contact addresses. The bindings
+ can be created and removed in many ways; this specification
+ defines a REGISTER method that updates the bindings.
+
+ Loop: A request that arrives at a proxy, is forwarded, and later
+ arrives back at the same proxy. When it arrives the second
+ time, its Request-URI is identical to the first time, and other
+ header fields that affect proxy operation are unchanged, so
+ that the proxy would make the same processing decision on the
+ request it made the first time. Looped requests are errors,
+ and the procedures for detecting them and handling them are
+ described by the protocol.
+
+ Loose Routing: A proxy is said to be loose routing if it follows
+ the procedures defined in this specification for processing of
+ the Route header field. These procedures separate the
+ destination of the request (present in the Request-URI) from
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 22]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ the set of proxies that need to be visited along the way
+ (present in the Route header field). A proxy compliant to
+ these mechanisms is also known as a loose router.
+
+ Message: Data sent between SIP elements as part of the protocol.
+ SIP messages are either requests or responses.
+
+ Method: The method is the primary function that a request is meant
+ to invoke on a server. The method is carried in the request
+ message itself. Example methods are INVITE and BYE.
+
+ Outbound Proxy: A proxy that receives requests from a client, even
+ though it may not be the server resolved by the Request-URI.
+ Typically, a UA is manually configured with an outbound proxy,
+ or can learn about one through auto-configuration protocols.
+
+ Parallel Search: In a parallel search, a proxy issues several
+ requests to possible user locations upon receiving an incoming
+ request. Rather than issuing one request and then waiting for
+ the final response before issuing the next request as in a
+ sequential search, a parallel search issues requests without
+ waiting for the result of previous requests.
+
+ Provisional Response: A response used by the server to indicate
+ progress, but that does not terminate a SIP transaction. 1xx
+ responses are provisional, other responses are considered
+ final.
+
+ Proxy, Proxy Server: An intermediary entity that acts as both a
+ server and a client for the purpose of making requests on
+ behalf of other clients. A proxy server primarily plays the
+ role of routing, which means its job is to ensure that a
+ request is sent to another entity "closer" to the targeted
+ user. Proxies are also useful for enforcing policy (for
+ example, making sure a user is allowed to make a call). A
+ proxy interprets, and, if necessary, rewrites specific parts of
+ a request message before forwarding it.
+
+ Recursion: A client recurses on a 3xx response when it generates a
+ new request to one or more of the URIs in the Contact header
+ field in the response.
+
+ Redirect Server: A redirect server is a user agent server that
+ generates 3xx responses to requests it receives, directing the
+ client to contact an alternate set of URIs.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 23]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Registrar: A registrar is a server that accepts REGISTER requests
+ and places the information it receives in those requests into
+ the location service for the domain it handles.
+
+ Regular Transaction: A regular transaction is any transaction with
+ a method other than INVITE, ACK, or CANCEL.
+
+ Request: A SIP message sent from a client to a server, for the
+ purpose of invoking a particular operation.
+
+ Response: A SIP message sent from a server to a client, for
+ indicating the status of a request sent from the client to the
+ server.
+
+ Ringback: Ringback is the signaling tone produced by the calling
+ party's application indicating that a called party is being
+ alerted (ringing).
+
+ Route Set: A route set is a collection of ordered SIP or SIPS URI
+ which represent a list of proxies that must be traversed when
+ sending a particular request. A route set can be learned,
+ through headers like Record-Route, or it can be configured.
+
+ Server: A server is a network element that receives requests in
+ order to service them and sends back responses to those
+ requests. Examples of servers are proxies, user agent servers,
+ redirect servers, and registrars.
+
+ Sequential Search: In a sequential search, a proxy server attempts
+ each contact address in sequence, proceeding to the next one
+ only after the previous has generated a final response. A 2xx
+ or 6xx class final response always terminates a sequential
+ search.
+
+ Session: From the SDP specification: "A multimedia session is a
+ set of multimedia senders and receivers and the data streams
+ flowing from senders to receivers. A multimedia conference is
+ an example of a multimedia session." (RFC 2327 [1]) (A session
+ as defined for SDP can comprise one or more RTP sessions.) As
+ defined, a callee can be invited several times, by different
+ calls, to the same session. If SDP is used, a session is
+ defined by the concatenation of the SDP user name, session id,
+ network type, address type, and address elements in the origin
+ field.
+
+ SIP Transaction: A SIP transaction occurs between a client and a
+ server and comprises all messages from the first request sent
+ from the client to the server up to a final (non-1xx) response
+
+
+
+Rosenberg, et. al. Standards Track [Page 24]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ sent from the server to the client. If the request is INVITE
+ and the final response is a non-2xx, the transaction also
+ includes an ACK to the response. The ACK for a 2xx response to
+ an INVITE request is a separate transaction.
+
+ Spiral: A spiral is a SIP request that is routed to a proxy,
+ forwarded onwards, and arrives once again at that proxy, but
+ this time differs in a way that will result in a different
+ processing decision than the original request. Typically, this
+ means that the request's Request-URI differs from its previous
+ arrival. A spiral is not an error condition, unlike a loop. A
+ typical cause for this is call forwarding. A user calls
+ joe@example.com. The example.com proxy forwards it to Joe's
+ PC, which in turn, forwards it to bob@example.com. This
+ request is proxied back to the example.com proxy. However,
+ this is not a loop. Since the request is targeted at a
+ different user, it is considered a spiral, and is a valid
+ condition.
+
+ Stateful Proxy: A logical entity that maintains the client and
+ server transaction state machines defined by this specification
+ during the processing of a request, also known as a transaction
+ stateful proxy. The behavior of a stateful proxy is further
+ defined in Section 16. A (transaction) stateful proxy is not
+ the same as a call stateful proxy.
+
+ Stateless Proxy: A logical entity that does not maintain the
+ client or server transaction state machines defined in this
+ specification when it processes requests. A stateless proxy
+ forwards every request it receives downstream and every
+ response it receives upstream.
+
+ Strict Routing: A proxy is said to be strict routing if it follows
+ the Route processing rules of RFC 2543 and many prior work in
+ progress versions of this RFC. That rule caused proxies to
+ destroy the contents of the Request-URI when a Route header
+ field was present. Strict routing behavior is not used in this
+ specification, in favor of a loose routing behavior. Proxies
+ that perform strict routing are also known as strict routers.
+
+ Target Refresh Request: A target refresh request sent within a
+ dialog is defined as a request that can modify the remote
+ target of the dialog.
+
+ Transaction User (TU): The layer of protocol processing that
+ resides above the transaction layer. Transaction users include
+ the UAC core, UAS core, and proxy core.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 25]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Upstream: A direction of message forwarding within a transaction
+ that refers to the direction that responses flow from the user
+ agent server back to the user agent client.
+
+ URL-encoded: A character string encoded according to RFC 2396,
+ Section 2.4 [5].
+
+ User Agent Client (UAC): A user agent client is a logical entity
+ that creates a new request, and then uses the client
+ transaction state machinery to send it. The role of UAC lasts
+ only for the duration of that transaction. In other words, if
+ a piece of software initiates a request, it acts as a UAC for
+ the duration of that transaction. If it receives a request
+ later, it assumes the role of a user agent server for the
+ processing of that transaction.
+
+ UAC Core: The set of processing functions required of a UAC that
+ reside above the transaction and transport layers.
+
+ User Agent Server (UAS): A user agent server is a logical entity
+ that generates a response to a SIP request. The response
+ accepts, rejects, or redirects the request. This role lasts
+ only for the duration of that transaction. In other words, if
+ a piece of software responds to a request, it acts as a UAS for
+ the duration of that transaction. If it generates a request
+ later, it assumes the role of a user agent client for the
+ processing of that transaction.
+
+ UAS Core: The set of processing functions required at a UAS that
+ resides above the transaction and transport layers.
+
+ User Agent (UA): A logical entity that can act as both a user
+ agent client and user agent server.
+
+ The role of UAC and UAS, as well as proxy and redirect servers, are
+ defined on a transaction-by-transaction basis. For example, the user
+ agent initiating a call acts as a UAC when sending the initial INVITE
+ request and as a UAS when receiving a BYE request from the callee.
+ Similarly, the same software can act as a proxy server for one
+ request and as a redirect server for the next request.
+
+ Proxy, location, and registrar servers defined above are logical
+ entities; implementations MAY combine them into a single application.
+
+7 SIP Messages
+
+ SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
+ [7]).
+
+
+
+Rosenberg, et. al. Standards Track [Page 26]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ A SIP message is either a request from a client to a server, or a
+ response from a server to a client.
+
+ Both Request (section 7.1) and Response (section 7.2) messages use
+ the basic format of RFC 2822 [3], even though the syntax differs in
+ character set and syntax specifics. (SIP allows header fields that
+ would not be valid RFC 2822 header fields, for example.) Both types
+ of messages consist of a start-line, one or more header fields, an
+ empty line indicating the end of the header fields, and an optional
+ message-body.
+
+ generic-message = start-line
+ *message-header
+ CRLF
+ [ message-body ]
+ start-line = Request-Line / Status-Line
+
+ The start-line, each message-header line, and the empty line MUST be
+ terminated by a carriage-return line-feed sequence (CRLF). Note that
+ the empty line MUST be present even if the message-body is not.
+
+ Except for the above difference in character sets, much of SIP's
+ message and header field syntax is identical to HTTP/1.1. Rather
+ than repeating the syntax and semantics here, we use [HX.Y] to refer
+ to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).
+
+ However, SIP is not an extension of HTTP.
+
+7.1 Requests
+
+ SIP requests are distinguished by having a Request-Line for a start-
+ line. A Request-Line contains a method name, a Request-URI, and the
+ protocol version separated by a single space (SP) character.
+
+ The Request-Line ends with CRLF. No CR or LF are allowed except in
+ the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed
+ in any of the elements.
+
+ Request-Line = Method SP Request-URI SP SIP-Version CRLF
+
+ Method: This specification defines six methods: REGISTER for
+ registering contact information, INVITE, ACK, and CANCEL for
+ setting up sessions, BYE for terminating sessions, and
+ OPTIONS for querying servers about their capabilities. SIP
+ extensions, documented in standards track RFCs, may define
+ additional methods.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 27]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Request-URI: The Request-URI is a SIP or SIPS URI as described in
+ Section 19.1 or a general URI (RFC 2396 [5]). It indicates
+ the user or service to which this request is being addressed.
+ The Request-URI MUST NOT contain unescaped spaces or control
+ characters and MUST NOT be enclosed in "<>".
+
+ SIP elements MAY support Request-URIs with schemes other than
+ "sip" and "sips", for example the "tel" URI scheme of RFC
+ 2806 [9]. SIP elements MAY translate non-SIP URIs using any
+ mechanism at their disposal, resulting in SIP URI, SIPS URI,
+ or some other scheme.
+
+ SIP-Version: Both request and response messages include the
+ version of SIP in use, and follow [H3.1] (with HTTP replaced
+ by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version
+ ordering, compliance requirements, and upgrading of version
+ numbers. To be compliant with this specification,
+ applications sending SIP messages MUST include a SIP-Version
+ of "SIP/2.0". The SIP-Version string is case-insensitive,
+ but implementations MUST send upper-case.
+
+ Unlike HTTP/1.1, SIP treats the version number as a literal
+ string. In practice, this should make no difference.
+
+7.2 Responses
+
+ SIP responses are distinguished from requests by having a Status-Line
+ as their start-line. A Status-Line consists of the protocol version
+ followed by a numeric Status-Code and its associated textual phrase,
+ with each element separated by a single SP character.
+
+ No CR or LF is allowed except in the final CRLF sequence.
+
+ Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
+
+ The Status-Code is a 3-digit integer result code that indicates the
+ outcome of an attempt to understand and satisfy a request. The
+ Reason-Phrase is intended to give a short textual description of the
+ Status-Code. The Status-Code is intended for use by automata,
+ whereas the Reason-Phrase is intended for the human user. A client
+ is not required to examine or display the Reason-Phrase.
+
+ While this specification suggests specific wording for the reason
+ phrase, implementations MAY choose other text, for example, in the
+ language indicated in the Accept-Language header field of the
+ request.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 28]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The first digit of the Status-Code defines the class of response.
+ The last two digits do not have any categorization role. For this
+ reason, any response with a status code between 100 and 199 is
+ referred to as a "1xx response", any response with a status code
+ between 200 and 299 as a "2xx response", and so on. SIP/2.0 allows
+ six values for the first digit:
+
+ 1xx: Provisional -- request received, continuing to process the
+ request;
+
+ 2xx: Success -- the action was successfully received, understood,
+ and accepted;
+
+ 3xx: Redirection -- further action needs to be taken in order to
+ complete the request;
+
+ 4xx: Client Error -- the request contains bad syntax or cannot be
+ fulfilled at this server;
+
+ 5xx: Server Error -- the server failed to fulfill an apparently
+ valid request;
+
+ 6xx: Global Failure -- the request cannot be fulfilled at any
+ server.
+
+ Section 21 defines these classes and describes the individual codes.
+
+7.3 Header Fields
+
+ SIP header fields are similar to HTTP header fields in both syntax
+ and semantics. In particular, SIP header fields follow the [H4.2]
+ definitions of syntax for the message-header and the rules for
+ extending header fields over multiple lines. However, the latter is
+ specified in HTTP with implicit whitespace and folding. This
+ specification conforms to RFC 2234 [10] and uses only explicit
+ whitespace and folding as an integral part of the grammar.
+
+ [H4.2] also specifies that multiple header fields of the same field
+ name whose value is a comma-separated list can be combined into one
+ header field. That applies to SIP as well, but the specific rule is
+ different because of the different grammars. Specifically, any SIP
+ header whose grammar is of the form
+
+ header = "header-name" HCOLON header-value *(COMMA header-value)
+
+ allows for combining header fields of the same name into a comma-
+ separated list. The Contact header field allows a comma-separated
+ list unless the header field value is "*".
+
+
+
+Rosenberg, et. al. Standards Track [Page 29]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+7.3.1 Header Field Format
+
+ Header fields follow the same generic header format as that given in
+ Section 2.2 of RFC 2822 [3]. Each header field consists of a field
+ name followed by a colon (":") and the field value.
+
+ field-name: field-value
+
+ The formal grammar for a message-header specified in Section 25
+ allows for an arbitrary amount of whitespace on either side of the
+ colon; however, implementations should avoid spaces between the field
+ name and the colon and use a single space (SP) between the colon and
+ the field-value.
+
+ Subject: lunch
+ Subject : lunch
+ Subject :lunch
+ Subject: lunch
+
+ Thus, the above are all valid and equivalent, but the last is the
+ preferred form.
+
+ Header fields can be extended over multiple lines by preceding each
+ extra line with at least one SP or horizontal tab (HT). The line
+ break and the whitespace at the beginning of the next line are
+ treated as a single SP character. Thus, the following are
+ equivalent:
+
+ Subject: I know you're there, pick up the phone and talk to me!
+ Subject: I know you're there,
+ pick up the phone
+ and talk to me!
+
+ The relative order of header fields with different field names is not
+ significant. However, it is RECOMMENDED that header fields which are
+ needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
+ Max-Forwards, and Proxy-Authorization, for example) appear towards
+ the top of the message to facilitate rapid parsing. The relative
+ order of header field rows with the same field name is important.
+ Multiple header field rows with the same field-name MAY be present in
+ a message if and only if the entire field-value for that header field
+ is defined as a comma-separated list (that is, if follows the grammar
+ defined in Section 7.3). It MUST be possible to combine the multiple
+ header field rows into one "field-name: field-value" pair, without
+ changing the semantics of the message, by appending each subsequent
+ field-value to the first, each separated by a comma. The exceptions
+ to this rule are the WWW-Authenticate, Authorization, Proxy-
+ Authenticate, and Proxy-Authorization header fields. Multiple header
+
+
+
+Rosenberg, et. al. Standards Track [Page 30]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ field rows with these names MAY be present in a message, but since
+ their grammar does not follow the general form listed in Section 7.3,
+ they MUST NOT be combined into a single header field row.
+
+ Implementations MUST be able to process multiple header field rows
+ with the same name in any combination of the single-value-per-line or
+ comma-separated value forms.
+
+ The following groups of header field rows are valid and equivalent:
+
+ Route: <sip:alice@atlanta.com>
+ Subject: Lunch
+ Route: <sip:bob@biloxi.com>
+ Route: <sip:carol@chicago.com>
+
+ Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
+ Route: <sip:carol@chicago.com>
+ Subject: Lunch
+
+ Subject: Lunch
+ Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
+ <sip:carol@chicago.com>
+
+ Each of the following blocks is valid but not equivalent to the
+ others:
+
+ Route: <sip:alice@atlanta.com>
+ Route: <sip:bob@biloxi.com>
+ Route: <sip:carol@chicago.com>
+
+ Route: <sip:bob@biloxi.com>
+ Route: <sip:alice@atlanta.com>
+ Route: <sip:carol@chicago.com>
+
+ Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
+ <sip:bob@biloxi.com>
+
+ The format of a header field-value is defined per header-name. It
+ will always be either an opaque sequence of TEXT-UTF8 octets, or a
+ combination of whitespace, tokens, separators, and quoted strings.
+ Many existing header fields will adhere to the general form of a
+ value followed by a semi-colon separated sequence of parameter-name,
+ parameter-value pairs:
+
+ field-name: field-value *(;parameter-name=parameter-value)
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 31]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Even though an arbitrary number of parameter pairs may be attached to
+ a header field value, any given parameter-name MUST NOT appear more
+ than once.
+
+ When comparing header fields, field names are always case-
+ insensitive. Unless otherwise stated in the definition of a
+ particular header field, field values, parameter names, and parameter
+ values are case-insensitive. Tokens are always case-insensitive.
+ Unless specified otherwise, values expressed as quoted strings are
+ case-sensitive. For example,
+
+ Contact: <sip:alice@atlanta.com>;expires=3600
+
+ is equivalent to
+
+ CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
+
+ and
+
+ Content-Disposition: session;handling=optional
+
+ is equivalent to
+
+ content-disposition: Session;HANDLING=OPTIONAL
+
+ The following two header fields are not equivalent:
+
+ Warning: 370 devnull "Choose a bigger pipe"
+ Warning: 370 devnull "CHOOSE A BIGGER PIPE"
+
+7.3.2 Header Field Classification
+
+ Some header fields only make sense in requests or responses. These
+ are called request header fields and response header fields,
+ respectively. If a header field appears in a message not matching
+ its category (such as a request header field in a response), it MUST
+ be ignored. Section 20 defines the classification of each header
+ field.
+
+7.3.3 Compact Form
+
+ SIP provides a mechanism to represent common header field names in an
+ abbreviated form. This may be useful when messages would otherwise
+ become too large to be carried on the transport available to it
+ (exceeding the maximum transmission unit (MTU) when using UDP, for
+ example). These compact forms are defined in Section 20. A compact
+ form MAY be substituted for the longer form of a header field name at
+ any time without changing the semantics of the message. A header
+
+
+
+Rosenberg, et. al. Standards Track [Page 32]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ field name MAY appear in both long and short forms within the same
+ message. Implementations MUST accept both the long and short forms
+ of each header name.
+
+7.4 Bodies
+
+ Requests, including new requests defined in extensions to this
+ specification, MAY contain message bodies unless otherwise noted.
+ The interpretation of the body depends on the request method.
+
+ For response messages, the request method and the response status
+ code determine the type and interpretation of any message body. All
+ responses MAY include a body.
+
+7.4.1 Message Body Type
+
+ The Internet media type of the message body MUST be given by the
+ Content-Type header field. If the body has undergone any encoding
+ such as compression, then this MUST be indicated by the Content-
+ Encoding header field; otherwise, Content-Encoding MUST be omitted.
+ If applicable, the character set of the message body is indicated as
+ part of the Content-Type header-field value.
+
+ The "multipart" MIME type defined in RFC 2046 [11] MAY be used within
+ the body of the message. Implementations that send requests
+ containing multipart message bodies MUST send a session description
+ as a non-multipart message body if the remote implementation requests
+ this through an Accept header field that does not contain multipart.
+
+ SIP messages MAY contain binary bodies or body parts. When no
+ explicit charset parameter is provided by the sender, media subtypes
+ of the "text" type are defined to have a default charset value of
+ "UTF-8".
+
+7.4.2 Message Body Length
+
+ The body length in bytes is provided by the Content-Length header
+ field. Section 20.14 describes the necessary contents of this header
+ field in detail.
+
+ The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
+ (Note: The chunked encoding modifies the body of a message in order
+ to transfer it as a series of chunks, each with its own size
+ indicator.)
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 33]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+7.5 Framing SIP Messages
+
+ Unlike HTTP, SIP implementations can use UDP or other unreliable
+ datagram protocols. Each such datagram carries one request or
+ response. See Section 18 on constraints on usage of unreliable
+ transports.
+
+ Implementations processing SIP messages over stream-oriented
+ transports MUST ignore any CRLF appearing before the start-line
+ [H4.1].
+
+ The Content-Length header field value is used to locate the end of
+ each SIP message in a stream. It will always be present when SIP
+ messages are sent over stream-oriented transports.
+
+8 General User Agent Behavior
+
+ A user agent represents an end system. It contains a user agent
+ client (UAC), which generates requests, and a user agent server
+ (UAS), which responds to them. A UAC is capable of generating a
+ request based on some external stimulus (the user clicking a button,
+ or a signal on a PSTN line) and processing a response. A UAS is
+ capable of receiving a request and generating a response based on
+ user input, external stimulus, the result of a program execution, or
+ some other mechanism.
+
+ When a UAC sends a request, the request passes through some number of
+ proxy servers, which forward the request towards the UAS. When the
+ UAS generates a response, the response is forwarded towards the UAC.
+
+ UAC and UAS procedures depend strongly on two factors. First, based
+ on whether the request or response is inside or outside of a dialog,
+ and second, based on the method of a request. Dialogs are discussed
+ thoroughly in Section 12; they represent a peer-to-peer relationship
+ between user agents and are established by specific SIP methods, such
+ as INVITE.
+
+ In this section, we discuss the method-independent rules for UAC and
+ UAS behavior when processing requests that are outside of a dialog.
+ This includes, of course, the requests which themselves establish a
+ dialog.
+
+ Security procedures for requests and responses outside of a dialog
+ are described in Section 26. Specifically, mechanisms exist for the
+ UAS and UAC to mutually authenticate. A limited set of privacy
+ features are also supported through encryption of bodies using
+ S/MIME.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 34]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+8.1 UAC Behavior
+
+ This section covers UAC behavior outside of a dialog.
+
+8.1.1 Generating the Request
+
+ A valid SIP request formulated by a UAC MUST, at a minimum, contain
+ the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
+ and Via; all of these header fields are mandatory in all SIP
+ requests. These six header fields are the fundamental building
+ blocks of a SIP message, as they jointly provide for most of the
+ critical message routing services including the addressing of
+ messages, the routing of responses, limiting message propagation,
+ ordering of messages, and the unique identification of transactions.
+ These header fields are in addition to the mandatory request line,
+ which contains the method, Request-URI, and SIP version.
+
+ Examples of requests sent outside of a dialog include an INVITE to
+ establish a session (Section 13) and an OPTIONS to query for
+ capabilities (Section 11).
+
+8.1.1.1 Request-URI
+
+ The initial Request-URI of the message SHOULD be set to the value of
+ the URI in the To field. One notable exception is the REGISTER
+ method; behavior for setting the Request-URI of REGISTER is given in
+ Section 10. It may also be undesirable for privacy reasons or
+ convenience to set these fields to the same value (especially if the
+ originating UA expects that the Request-URI will be changed during
+ transit).
+
+ In some special circumstances, the presence of a pre-existing route
+ set can affect the Request-URI of the message. A pre-existing route
+ set is an ordered set of URIs that identify a chain of servers, to
+ which a UAC will send outgoing requests that are outside of a dialog.
+ Commonly, they are configured on the UA by a user or service provider
+ manually, or through some other non-SIP mechanism. When a provider
+ wishes to configure a UA with an outbound proxy, it is RECOMMENDED
+ that this be done by providing it with a pre-existing route set with
+ a single URI, that of the outbound proxy.
+
+ When a pre-existing route set is present, the procedures for
+ populating the Request-URI and Route header field detailed in Section
+ 12.2.1.1 MUST be followed (even though there is no dialog), using the
+ desired Request-URI as the remote target URI.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 35]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+8.1.1.2 To
+
+ The To header field first and foremost specifies the desired
+ "logical" recipient of the request, or the address-of-record of the
+ user or resource that is the target of this request. This may or may
+ not be the ultimate recipient of the request. The To header field
+ MAY contain a SIP or SIPS URI, but it may also make use of other URI
+ schemes (the tel URL (RFC 2806 [9]), for example) when appropriate.
+ All SIP implementations MUST support the SIP URI scheme. Any
+ implementation that supports TLS MUST support the SIPS URI scheme.
+ The To header field allows for a display name.
+
+ A UAC may learn how to populate the To header field for a particular
+ request in a number of ways. Usually the user will suggest the To
+ header field through a human interface, perhaps inputting the URI
+ manually or selecting it from some sort of address book. Frequently,
+ the user will not enter a complete URI, but rather a string of digits
+ or letters (for example, "bob"). It is at the discretion of the UA
+ to choose how to interpret this input. Using the string to form the
+ user part of a SIP URI implies that the UA wishes the name to be
+ resolved in the domain to the right-hand side (RHS) of the at-sign in
+ the SIP URI (for instance, sip:bob@example.com). Using the string to
+ form the user part of a SIPS URI implies that the UA wishes to
+ communicate securely, and that the name is to be resolved in the
+ domain to the RHS of the at-sign. The RHS will frequently be the
+ home domain of the requestor, which allows for the home domain to
+ process the outgoing request. This is useful for features like
+ "speed dial" that require interpretation of the user part in the home
+ domain. The tel URL may be used when the UA does not wish to specify
+ the domain that should interpret a telephone number that has been
+ input by the user. Rather, each domain through which the request
+ passes would be given that opportunity. As an example, a user in an
+ airport might log in and send requests through an outbound proxy in
+ the airport. If they enter "411" (this is the phone number for local
+ directory assistance in the United States), that needs to be
+ interpreted and processed by the outbound proxy in the airport, not
+ the user's home domain. In this case, tel:411 would be the right
+ choice.
+
+ A request outside of a dialog MUST NOT contain a To tag; the tag in
+ the To field of a request identifies the peer of the dialog. Since
+ no dialog is established, no tag is present.
+
+ For further information on the To header field, see Section 20.39.
+ The following is an example of a valid To header field:
+
+ To: Carol <sip:carol@chicago.com>
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 36]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+8.1.1.3 From
+
+ The From header field indicates the logical identity of the initiator
+ of the request, possibly the user's address-of-record. Like the To
+ header field, it contains a URI and optionally a display name. It is
+ used by SIP elements to determine which processing rules to apply to
+ a request (for example, automatic call rejection). As such, it is
+ very important that the From URI not contain IP addresses or the FQDN
+ of the host on which the UA is running, since these are not logical
+ names.
+
+ The From header field allows for a display name. A UAC SHOULD use
+ the display name "Anonymous", along with a syntactically correct, but
+ otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
+ identity of the client is to remain hidden.
+
+ Usually, the value that populates the From header field in requests
+ generated by a particular UA is pre-provisioned by the user or by the
+ administrators of the user's local domain. If a particular UA is
+ used by multiple users, it might have switchable profiles that
+ include a URI corresponding to the identity of the profiled user.
+ Recipients of requests can authenticate the originator of a request
+ in order to ascertain that they are who their From header field
+ claims they are (see Section 22 for more on authentication).
+
+ The From field MUST contain a new "tag" parameter, chosen by the UAC.
+ See Section 19.3 for details on choosing a tag.
+
+ For further information on the From header field, see Section 20.20.
+ Examples:
+
+ From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
+ From: sip:+12125551212@phone2net.com;tag=887s
+ From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
+
+8.1.1.4 Call-ID
+
+ The Call-ID header field acts as a unique identifier to group
+ together a series of messages. It MUST be the same for all requests
+ and responses sent by either UA in a dialog. It SHOULD be the same
+ in each registration from a UA.
+
+ In a new request created by a UAC outside of any dialog, the Call-ID
+ header field MUST be selected by the UAC as a globally unique
+ identifier over space and time unless overridden by method-specific
+ behavior. All SIP UAs must have a means to guarantee that the Call-
+ ID header fields they produce will not be inadvertently generated by
+ any other UA. Note that when requests are retried after certain
+
+
+
+Rosenberg, et. al. Standards Track [Page 37]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ failure responses that solicit an amendment to a request (for
+ example, a challenge for authentication), these retried requests are
+ not considered new requests, and therefore do not need new Call-ID
+ header fields; see Section 8.1.3.5.
+
+ Use of cryptographically random identifiers (RFC 1750 [12]) in the
+ generation of Call-IDs is RECOMMENDED. Implementations MAY use the
+ form "localid@host". Call-IDs are case-sensitive and are simply
+ compared byte-by-byte.
+
+ Using cryptographically random identifiers provides some
+ protection against session hijacking and reduces the likelihood of
+ unintentional Call-ID collisions.
+
+ No provisioning or human interface is required for the selection of
+ the Call-ID header field value for a request.
+
+ For further information on the Call-ID header field, see Section
+ 20.8.
+
+ Example:
+
+ Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
+
+8.1.1.5 CSeq
+
+ The CSeq header field serves as a way to identify and order
+ transactions. It consists of a sequence number and a method. The
+ method MUST match that of the request. For non-REGISTER requests
+ outside of a dialog, the sequence number value is arbitrary. The
+ sequence number value MUST be expressible as a 32-bit unsigned
+ integer and MUST be less than 2**31. As long as it follows the above
+ guidelines, a client may use any mechanism it would like to select
+ CSeq header field values.
+
+ Section 12.2.1.1 discusses construction of the CSeq for requests
+ within a dialog.
+
+ Example:
+
+ CSeq: 4711 INVITE
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 38]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+8.1.1.6 Max-Forwards
+
+ The Max-Forwards header field serves to limit the number of hops a
+ request can transit on the way to its destination. It consists of an
+ integer that is decremented by one at each hop. If the Max-Forwards
+ value reaches 0 before the request reaches its destination, it will
+ be rejected with a 483(Too Many Hops) error response.
+
+ A UAC MUST insert a Max-Forwards header field into each request it
+ originates with a value that SHOULD be 70. This number was chosen to
+ be sufficiently large to guarantee that a request would not be
+ dropped in any SIP network when there were no loops, but not so large
+ as to consume proxy resources when a loop does occur. Lower values
+ should be used with caution and only in networks where topologies are
+ known by the UA.
+
+8.1.1.7 Via
+
+ The Via header field indicates the transport used for the transaction
+ and identifies the location where the response is to be sent. A Via
+ header field value is added only after the transport that will be
+ used to reach the next hop has been selected (which may involve the
+ usage of the procedures in [4]).
+
+ When the UAC creates a request, it MUST insert a Via into that
+ request. The protocol name and protocol version in the header field
+ MUST be SIP and 2.0, respectively. The Via header field value MUST
+ contain a branch parameter. This parameter is used to identify the
+ transaction created by that request. This parameter is used by both
+ the client and the server.
+
+ The branch parameter value MUST be unique across space and time for
+ all requests sent by the UA. The exceptions to this rule are CANCEL
+ and ACK for non-2xx responses. As discussed below, a CANCEL request
+ will have the same value of the branch parameter as the request it
+ cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx
+ response will also have the same branch ID as the INVITE whose
+ response it acknowledges.
+
+ The uniqueness property of the branch ID parameter, to facilitate
+ its use as a transaction ID, was not part of RFC 2543.
+
+ The branch ID inserted by an element compliant with this
+ specification MUST always begin with the characters "z9hG4bK". These
+ 7 characters are used as a magic cookie (7 is deemed sufficient to
+ ensure that an older RFC 2543 implementation would not pick such a
+ value), so that servers receiving the request can determine that the
+ branch ID was constructed in the fashion described by this
+
+
+
+Rosenberg, et. al. Standards Track [Page 39]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ specification (that is, globally unique). Beyond this requirement,
+ the precise format of the branch token is implementation-defined.
+
+ The Via header maddr, ttl, and sent-by components will be set when
+ the request is processed by the transport layer (Section 18).
+
+ Via processing for proxies is described in Section 16.6 Item 8 and
+ Section 16.7 Item 3.
+
+8.1.1.8 Contact
+
+ The Contact header field provides a SIP or SIPS URI that can be used
+ to contact that specific instance of the UA for subsequent requests.
+ The Contact header field MUST be present and contain exactly one SIP
+ or SIPS URI in any request that can result in the establishment of a
+ dialog. For the methods defined in this specification, that includes
+ only the INVITE request. For these requests, the scope of the
+ Contact is global. That is, the Contact header field value contains
+ the URI at which the UA would like to receive requests, and this URI
+ MUST be valid even if used in subsequent requests outside of any
+ dialogs.
+
+ If the Request-URI or top Route header field value contains a SIPS
+ URI, the Contact header field MUST contain a SIPS URI as well.
+
+ For further information on the Contact header field, see Section
+ 20.10.
+
+8.1.1.9 Supported and Require
+
+ If the UAC supports extensions to SIP that can be applied by the
+ server to the response, the UAC SHOULD include a Supported header
+ field in the request listing the option tags (Section 19.2) for those
+ extensions.
+
+ The option tags listed MUST only refer to extensions defined in
+ standards-track RFCs. This is to prevent servers from insisting that
+ clients implement non-standard, vendor-defined features in order to
+ receive service. Extensions defined by experimental and
+ informational RFCs are explicitly excluded from usage with the
+ Supported header field in a request, since they too are often used to
+ document vendor-defined extensions.
+
+ If the UAC wishes to insist that a UAS understand an extension that
+ the UAC will apply to the request in order to process the request, it
+ MUST insert a Require header field into the request listing the
+ option tag for that extension. If the UAC wishes to apply an
+ extension to the request and insist that any proxies that are
+
+
+
+Rosenberg, et. al. Standards Track [Page 40]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ traversed understand that extension, it MUST insert a Proxy-Require
+ header field into the request listing the option tag for that
+ extension.
+
+ As with the Supported header field, the option tags in the Require
+ and Proxy-Require header fields MUST only refer to extensions defined
+ in standards-track RFCs.
+
+8.1.1.10 Additional Message Components
+
+ After a new request has been created, and the header fields described
+ above have been properly constructed, any additional optional header
+ fields are added, as are any header fields specific to the method.
+
+ SIP requests MAY contain a MIME-encoded message-body. Regardless of
+ the type of body that a request contains, certain header fields must
+ be formulated to characterize the contents of the body. For further
+ information on these header fields, see Sections 20.11 through 20.15.
+
+8.1.2 Sending the Request
+
+ The destination for the request is then computed. Unless there is
+ local policy specifying otherwise, the destination MUST be determined
+ by applying the DNS procedures described in [4] as follows. If the
+ first element in the route set indicated a strict router (resulting
+ in forming the request as described in Section 12.2.1.1), the
+ procedures MUST be applied to the Request-URI of the request.
+ Otherwise, the procedures are applied to the first Route header field
+ value in the request (if one exists), or to the request's Request-URI
+ if there is no Route header field present. These procedures yield an
+ ordered set of address, port, and transports to attempt. Independent
+ of which URI is used as input to the procedures of [4], if the
+ Request-URI specifies a SIPS resource, the UAC MUST follow the
+ procedures of [4] as if the input URI were a SIPS URI.
+
+ Local policy MAY specify an alternate set of destinations to attempt.
+ If the Request-URI contains a SIPS URI, any alternate destinations
+ MUST be contacted with TLS. Beyond that, there are no restrictions
+ on the alternate destinations if the request contains no Route header
+ field. This provides a simple alternative to a pre-existing route
+ set as a way to specify an outbound proxy. However, that approach
+ for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
+ route set with a single URI SHOULD be used instead. If the request
+ contains a Route header field, the request SHOULD be sent to the
+ locations derived from its topmost value, but MAY be sent to any
+ server that the UA is certain will honor the Route and Request-URI
+ policies specified in this document (as opposed to those in RFC
+ 2543). In particular, a UAC configured with an outbound proxy SHOULD
+
+
+
+Rosenberg, et. al. Standards Track [Page 41]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ attempt to send the request to the location indicated in the first
+ Route header field value instead of adopting the policy of sending
+ all messages to the outbound proxy.
+
+ This ensures that outbound proxies that do not add Record-Route
+ header field values will drop out of the path of subsequent
+ requests. It allows endpoints that cannot resolve the first Route
+ URI to delegate that task to an outbound proxy.
+
+ The UAC SHOULD follow the procedures defined in [4] for stateful
+ elements, trying each address until a server is contacted. Each try
+ constitutes a new transaction, and therefore each carries a different
+ topmost Via header field value with a new branch parameter.
+ Furthermore, the transport value in the Via header field is set to
+ whatever transport was determined for the target server.
+
+8.1.3 Processing Responses
+
+ Responses are first processed by the transport layer and then passed
+ up to the transaction layer. The transaction layer performs its
+ processing and then passes the response up to the TU. The majority
+ of response processing in the TU is method specific. However, there
+ are some general behaviors independent of the method.
+
+8.1.3.1 Transaction Layer Errors
+
+ In some cases, the response returned by the transaction layer will
+ not be a SIP message, but rather a transaction layer error. When a
+ timeout error is received from the transaction layer, it MUST be
+ treated as if a 408 (Request Timeout) status code has been received.
+ If a fatal transport error is reported by the transport layer
+ (generally, due to fatal ICMP errors in UDP or connection failures in
+ TCP), the condition MUST be treated as a 503 (Service Unavailable)
+ status code.
+
+8.1.3.2 Unrecognized Responses
+
+ A UAC MUST treat any final response it does not recognize as being
+ equivalent to the x00 response code of that class, and MUST be able
+ to process the x00 response code for all classes. For example, if a
+ UAC receives an unrecognized response code of 431, it can safely
+ assume that there was something wrong with its request and treat the
+ response as if it had received a 400 (Bad Request) response code. A
+ UAC MUST treat any provisional response different than 100 that it
+ does not recognize as 183 (Session Progress). A UAC MUST be able to
+ process 100 and 183 responses.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 42]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+8.1.3.3 Vias
+
+ If more than one Via header field value is present in a response, the
+ UAC SHOULD discard the message.
+
+ The presence of additional Via header field values that precede
+ the originator of the request suggests that the message was
+ misrouted or possibly corrupted.
+
+8.1.3.4 Processing 3xx Responses
+
+ Upon receipt of a redirection response (for example, a 301 response
+ status code), clients SHOULD use the URI(s) in the Contact header
+ field to formulate one or more new requests based on the redirected
+ request. This process is similar to that of a proxy recursing on a
+ 3xx class response as detailed in Sections 16.5 and 16.6. A client
+ starts with an initial target set containing exactly one URI, the
+ Request-URI of the original request. If a client wishes to formulate
+ new requests based on a 3xx class response to that request, it places
+ the URIs to try into the target set. Subject to the restrictions in
+ this specification, a client can choose which Contact URIs it places
+ into the target set. As with proxy recursion, a client processing
+ 3xx class responses MUST NOT add any given URI to the target set more
+ than once. If the original request had a SIPS URI in the Request-
+ URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD
+ inform the user of the redirection to an insecure URI.
+
+ Any new request may receive 3xx responses themselves containing
+ the original URI as a contact. Two locations can be configured to
+ redirect to each other. Placing any given URI in the target set
+ only once prevents infinite redirection loops.
+
+ As the target set grows, the client MAY generate new requests to the
+ URIs in any order. A common mechanism is to order the set by the "q"
+ parameter value from the Contact header field value. Requests to the
+ URIs MAY be generated serially or in parallel. One approach is to
+ process groups of decreasing q-values serially and process the URIs
+ in each q-value group in parallel. Another is to perform only serial
+ processing in decreasing q-value order, arbitrarily choosing between
+ contacts of equal q-value.
+
+ If contacting an address in the list results in a failure, as defined
+ in the next paragraph, the element moves to the next address in the
+ list, until the list is exhausted. If the list is exhausted, then
+ the request has failed.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 43]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Failures SHOULD be detected through failure response codes (codes
+ greater than 399); for network errors the client transaction will
+ report any transport layer failures to the transaction user. Note
+ that some response codes (detailed in 8.1.3.5) indicate that the
+ request can be retried; requests that are reattempted should not be
+ considered failures.
+
+ When a failure for a particular contact address is received, the
+ client SHOULD try the next contact address. This will involve
+ creating a new client transaction to deliver a new request.
+
+ In order to create a request based on a contact address in a 3xx
+ response, a UAC MUST copy the entire URI from the target set into the
+ Request-URI, except for the "method-param" and "header" URI
+ parameters (see Section 19.1.1 for a definition of these parameters).
+ It uses the "header" parameters to create header field values for the
+ new request, overwriting header field values associated with the
+ redirected request in accordance with the guidelines in Section
+ 19.1.5.
+
+ Note that in some instances, header fields that have been
+ communicated in the contact address may instead append to existing
+ request header fields in the original redirected request. As a
+ general rule, if the header field can accept a comma-separated list
+ of values, then the new header field value MAY be appended to any
+ existing values in the original redirected request. If the header
+ field does not accept multiple values, the value in the original
+ redirected request MAY be overwritten by the header field value
+ communicated in the contact address. For example, if a contact
+ address is returned with the following value:
+
+ sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
+
+ Then any Subject header field in the original redirected request is
+ overwritten, but the HTTP URL is merely appended to any existing
+ Call-Info header field values.
+
+ It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID
+ used in the original redirected request, but the UAC MAY also choose
+ to update the Call-ID header field value for new requests, for
+ example.
+
+ Finally, once the new request has been constructed, it is sent using
+ a new client transaction, and therefore MUST have a new branch ID in
+ the top Via field as discussed in Section 8.1.1.7.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 44]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ In all other respects, requests sent upon receipt of a redirect
+ response SHOULD re-use the header fields and bodies of the original
+ request.
+
+ In some instances, Contact header field values may be cached at UAC
+ temporarily or permanently depending on the status code received and
+ the presence of an expiration interval; see Sections 21.3.2 and
+ 21.3.3.
+
+8.1.3.5 Processing 4xx Responses
+
+ Certain 4xx response codes require specific UA processing,
+ independent of the method.
+
+ If a 401 (Unauthorized) or 407 (Proxy Authentication Required)
+ response is received, the UAC SHOULD follow the authorization
+ procedures of Section 22.2 and Section 22.3 to retry the request with
+ credentials.
+
+ If a 413 (Request Entity Too Large) response is received (Section
+ 21.4.11), the request contained a body that was longer than the UAS
+ was willing to accept. If possible, the UAC SHOULD retry the
+ request, either omitting the body or using one of a smaller length.
+
+ If a 415 (Unsupported Media Type) response is received (Section
+ 21.4.13), the request contained media types not supported by the UAS.
+ The UAC SHOULD retry sending the request, this time only using
+ content with types listed in the Accept header field in the response,
+ with encodings listed in the Accept-Encoding header field in the
+ response, and with languages listed in the Accept-Language in the
+ response.
+
+ If a 416 (Unsupported URI Scheme) response is received (Section
+ 21.4.14), the Request-URI used a URI scheme not supported by the
+ server. The client SHOULD retry the request, this time, using a SIP
+ URI.
+
+ If a 420 (Bad Extension) response is received (Section 21.4.15), the
+ request contained a Require or Proxy-Require header field listing an
+ option-tag for a feature not supported by a proxy or UAS. The UAC
+ SHOULD retry the request, this time omitting any extensions listed in
+ the Unsupported header field in the response.
+
+ In all of the above cases, the request is retried by creating a new
+ request with the appropriate modifications. This new request
+ constitutes a new transaction and SHOULD have the same value of the
+ Call-ID, To, and From of the previous request, but the CSeq should
+ contain a new sequence number that is one higher than the previous.
+
+
+
+Rosenberg, et. al. Standards Track [Page 45]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ With other 4xx responses, including those yet to be defined, a retry
+ may or may not be possible depending on the method and the use case.
+
+8.2 UAS Behavior
+
+ When a request outside of a dialog is processed by a UAS, there is a
+ set of processing rules that are followed, independent of the method.
+ Section 12 gives guidance on how a UAS can tell whether a request is
+ inside or outside of a dialog.
+
+ Note that request processing is atomic. If a request is accepted,
+ all state changes associated with it MUST be performed. If it is
+ rejected, all state changes MUST NOT be performed.
+
+ UASs SHOULD process the requests in the order of the steps that
+ follow in this section (that is, starting with authentication, then
+ inspecting the method, the header fields, and so on throughout the
+ remainder of this section).
+
+8.2.1 Method Inspection
+
+ Once a request is authenticated (or authentication is skipped), the
+ UAS MUST inspect the method of the request. If the UAS recognizes
+ but does not support the method of a request, it MUST generate a 405
+ (Method Not Allowed) response. Procedures for generating responses
+ are described in Section 8.2.6. The UAS MUST also add an Allow
+ header field to the 405 (Method Not Allowed) response. The Allow
+ header field MUST list the set of methods supported by the UAS
+ generating the message. The Allow header field is presented in
+ Section 20.5.
+
+ If the method is one supported by the server, processing continues.
+
+8.2.2 Header Inspection
+
+ If a UAS does not understand a header field in a request (that is,
+ the header field is not defined in this specification or in any
+ supported extension), the server MUST ignore that header field and
+ continue processing the message. A UAS SHOULD ignore any malformed
+ header fields that are not necessary for processing requests.
+
+8.2.2.1 To and Request-URI
+
+ The To header field identifies the original recipient of the request
+ designated by the user identified in the From field. The original
+ recipient may or may not be the UAS processing the request, due to
+ call forwarding or other proxy operations. A UAS MAY apply any
+ policy it wishes to determine whether to accept requests when the To
+
+
+
+Rosenberg, et. al. Standards Track [Page 46]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ header field is not the identity of the UAS. However, it is
+ RECOMMENDED that a UAS accept requests even if they do not recognize
+ the URI scheme (for example, a tel: URI) in the To header field, or
+ if the To header field does not address a known or current user of
+ this UAS. If, on the other hand, the UAS decides to reject the
+ request, it SHOULD generate a response with a 403 (Forbidden) status
+ code and pass it to the server transaction for transmission.
+
+ However, the Request-URI identifies the UAS that is to process the
+ request. If the Request-URI uses a scheme not supported by the UAS,
+ it SHOULD reject the request with a 416 (Unsupported URI Scheme)
+ response. If the Request-URI does not identify an address that the
+ UAS is willing to accept requests for, it SHOULD reject the request
+ with a 404 (Not Found) response. Typically, a UA that uses the
+ REGISTER method to bind its address-of-record to a specific contact
+ address will see requests whose Request-URI equals that contact
+ address. Other potential sources of received Request-URIs include
+ the Contact header fields of requests and responses sent by the UA
+ that establish or refresh dialogs.
+
+8.2.2.2 Merged Requests
+
+ If the request has no tag in the To header field, the UAS core MUST
+ check the request against ongoing transactions. If the From tag,
+ Call-ID, and CSeq exactly match those associated with an ongoing
+ transaction, but the request does not match that transaction (based
+ on the matching rules in Section 17.2.3), the UAS core SHOULD
+ generate a 482 (Loop Detected) response and pass it to the server
+ transaction.
+
+ The same request has arrived at the UAS more than once, following
+ different paths, most likely due to forking. The UAS processes
+ the first such request received and responds with a 482 (Loop
+ Detected) to the rest of them.
+
+8.2.2.3 Require
+
+ Assuming the UAS decides that it is the proper element to process the
+ request, it examines the Require header field, if present.
+
+ The Require header field is used by a UAC to tell a UAS about SIP
+ extensions that the UAC expects the UAS to support in order to
+ process the request properly. Its format is described in Section
+ 20.32. If a UAS does not understand an option-tag listed in a
+ Require header field, it MUST respond by generating a response with
+ status code 420 (Bad Extension). The UAS MUST add an Unsupported
+ header field, and list in it those options it does not understand
+ amongst those in the Require header field of the request.
+
+
+
+Rosenberg, et. al. Standards Track [Page 47]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL
+ request, or in an ACK request sent for a non-2xx response. These
+ header fields MUST be ignored if they are present in these requests.
+
+ An ACK request for a 2xx response MUST contain only those Require and
+ Proxy-Require values that were present in the initial request.
+
+ Example:
+
+ UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
+ Require: 100rel
+
+ UAS->UAC: SIP/2.0 420 Bad Extension
+ Unsupported: 100rel
+
+ This behavior ensures that the client-server interaction will
+ proceed without delay when all options are understood by both
+ sides, and only slow down if options are not understood (as in the
+ example above). For a well-matched client-server pair, the
+ interaction proceeds quickly, saving a round-trip often required
+ by negotiation mechanisms. In addition, it also removes ambiguity
+ when the client requires features that the server does not
+ understand. Some features, such as call handling fields, are only
+ of interest to end systems.
+
+8.2.3 Content Processing
+
+ Assuming the UAS understands any extensions required by the client,
+ the UAS examines the body of the message, and the header fields that
+ describe it. If there are any bodies whose type (indicated by the
+ Content-Type), language (indicated by the Content-Language) or
+ encoding (indicated by the Content-Encoding) are not understood, and
+ that body part is not optional (as indicated by the Content-
+ Disposition header field), the UAS MUST reject the request with a 415
+ (Unsupported Media Type) response. The response MUST contain an
+ Accept header field listing the types of all bodies it understands,
+ in the event the request contained bodies of types not supported by
+ the UAS. If the request contained content encodings not understood
+ by the UAS, the response MUST contain an Accept-Encoding header field
+ listing the encodings understood by the UAS. If the request
+ contained content with languages not understood by the UAS, the
+ response MUST contain an Accept-Language header field indicating the
+ languages understood by the UAS. Beyond these checks, body handling
+ depends on the method and type. For further information on the
+ processing of content-specific header fields, see Section 7.4 as well
+ as Section 20.11 through 20.15.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 48]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+8.2.4 Applying Extensions
+
+ A UAS that wishes to apply some extension when generating the
+ response MUST NOT do so unless support for that extension is
+ indicated in the Supported header field in the request. If the
+ desired extension is not supported, the server SHOULD rely only on
+ baseline SIP and any other extensions supported by the client. In
+ rare circumstances, where the server cannot process the request
+ without the extension, the server MAY send a 421 (Extension Required)
+ response. This response indicates that the proper response cannot be
+ generated without support of a specific extension. The needed
+ extension(s) MUST be included in a Require header field in the
+ response. This behavior is NOT RECOMMENDED, as it will generally
+ break interoperability.
+
+ Any extensions applied to a non-421 response MUST be listed in a
+ Require header field included in the response. Of course, the server
+ MUST NOT apply extensions not listed in the Supported header field in
+ the request. As a result of this, the Require header field in a
+ response will only ever contain option tags defined in standards-
+ track RFCs.
+
+8.2.5 Processing the Request
+
+ Assuming all of the checks in the previous subsections are passed,
+ the UAS processing becomes method-specific. Section 10 covers the
+ REGISTER request, Section 11 covers the OPTIONS request, Section 13
+ covers the INVITE request, and Section 15 covers the BYE request.
+
+8.2.6 Generating the Response
+
+ When a UAS wishes to construct a response to a request, it follows
+ the general procedures detailed in the following subsections.
+ Additional behaviors specific to the response code in question, which
+ are not detailed in this section, may also be required.
+
+ Once all procedures associated with the creation of a response have
+ been completed, the UAS hands the response back to the server
+ transaction from which it received the request.
+
+8.2.6.1 Sending a Provisional Response
+
+ One largely non-method-specific guideline for the generation of
+ responses is that UASs SHOULD NOT issue a provisional response for a
+ non-INVITE request. Rather, UASs SHOULD generate a final response to
+ a non-INVITE request as soon as possible.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 49]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ When a 100 (Trying) response is generated, any Timestamp header field
+ present in the request MUST be copied into this 100 (Trying)
+ response. If there is a delay in generating the response, the UAS
+ SHOULD add a delay value into the Timestamp value in the response.
+ This value MUST contain the difference between the time of sending of
+ the response and receipt of the request, measured in seconds.
+
+8.2.6.2 Headers and Tags
+
+ The From field of the response MUST equal the From header field of
+ the request. The Call-ID header field of the response MUST equal the
+ Call-ID header field of the request. The CSeq header field of the
+ response MUST equal the CSeq field of the request. The Via header
+ field values in the response MUST equal the Via header field values
+ in the request and MUST maintain the same ordering.
+
+ If a request contained a To tag in the request, the To header field
+ in the response MUST equal that of the request. However, if the To
+ header field in the request did not contain a tag, the URI in the To
+ header field in the response MUST equal the URI in the To header
+ field; additionally, the UAS MUST add a tag to the To header field in
+ the response (with the exception of the 100 (Trying) response, in
+ which a tag MAY be present). This serves to identify the UAS that is
+ responding, possibly resulting in a component of a dialog ID. The
+ same tag MUST be used for all responses to that request, both final
+ and provisional (again excepting the 100 (Trying)). Procedures for
+ the generation of tags are defined in Section 19.3.
+
+8.2.7 Stateless UAS Behavior
+
+ A stateless UAS is a UAS that does not maintain transaction state.
+ It replies to requests normally, but discards any state that would
+ ordinarily be retained by a UAS after a response has been sent. If a
+ stateless UAS receives a retransmission of a request, it regenerates
+ the response and resends it, just as if it were replying to the first
+ instance of the request. A UAS cannot be stateless unless the request
+ processing for that method would always result in the same response
+ if the requests are identical. This rules out stateless registrars,
+ for example. Stateless UASs do not use a transaction layer; they
+ receive requests directly from the transport layer and send responses
+ directly to the transport layer.
+
+ The stateless UAS role is needed primarily to handle unauthenticated
+ requests for which a challenge response is issued. If
+ unauthenticated requests were handled statefully, then malicious
+ floods of unauthenticated requests could create massive amounts of
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 50]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ transaction state that might slow or completely halt call processing
+ in a UAS, effectively creating a denial of service condition; for
+ more information see Section 26.1.5.
+
+ The most important behaviors of a stateless UAS are the following:
+
+ o A stateless UAS MUST NOT send provisional (1xx) responses.
+
+ o A stateless UAS MUST NOT retransmit responses.
+
+ o A stateless UAS MUST ignore ACK requests.
+
+ o A stateless UAS MUST ignore CANCEL requests.
+
+ o To header tags MUST be generated for responses in a stateless
+ manner - in a manner that will generate the same tag for the
+ same request consistently. For information on tag construction
+ see Section 19.3.
+
+ In all other respects, a stateless UAS behaves in the same manner as
+ a stateful UAS. A UAS can operate in either a stateful or stateless
+ mode for each new request.
+
+8.3 Redirect Servers
+
+ In some architectures it may be desirable to reduce the processing
+ load on proxy servers that are responsible for routing requests, and
+ improve signaling path robustness, by relying on redirection.
+
+ Redirection allows servers to push routing information for a request
+ back in a response to the client, thereby taking themselves out of
+ the loop of further messaging for this transaction while still aiding
+ in locating the target of the request. When the originator of the
+ request receives the redirection, it will send a new request based on
+ the URI(s) it has received. By propagating URIs from the core of the
+ network to its edges, redirection allows for considerable network
+ scalability.
+
+ A redirect server is logically constituted of a server transaction
+ layer and a transaction user that has access to a location service of
+ some kind (see Section 10 for more on registrars and location
+ services). This location service is effectively a database
+ containing mappings between a single URI and a set of one or more
+ alternative locations at which the target of that URI can be found.
+
+ A redirect server does not issue any SIP requests of its own. After
+ receiving a request other than CANCEL, the server either refuses the
+ request or gathers the list of alternative locations from the
+
+
+
+Rosenberg, et. al. Standards Track [Page 51]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ location service and returns a final response of class 3xx. For
+ well-formed CANCEL requests, it SHOULD return a 2xx response. This
+ response ends the SIP transaction. The redirect server maintains
+ transaction state for an entire SIP transaction. It is the
+ responsibility of clients to detect forwarding loops between redirect
+ servers.
+
+ When a redirect server returns a 3xx response to a request, it
+ populates the list of (one or more) alternative locations into the
+ Contact header field. An "expires" parameter to the Contact header
+ field values may also be supplied to indicate the lifetime of the
+ Contact data.
+
+ The Contact header field contains URIs giving the new locations or
+ user names to try, or may simply specify additional transport
+ parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily)
+ response may also give the same location and username that was
+ targeted by the initial request but specify additional transport
+ parameters such as a different server or multicast address to try, or
+ a change of SIP transport from UDP to TCP or vice versa.
+
+ However, redirect servers MUST NOT redirect a request to a URI equal
+ to the one in the Request-URI; instead, provided that the URI does
+ not point to itself, the server MAY proxy the request to the
+ destination URI, or MAY reject it with a 404.
+
+ If a client is using an outbound proxy, and that proxy actually
+ redirects requests, a potential arises for infinite redirection
+ loops.
+
+ Note that a Contact header field value MAY also refer to a different
+ resource than the one originally called. For example, a SIP call
+ connected to PSTN gateway may need to deliver a special informational
+ announcement such as "The number you have dialed has been changed."
+
+ A Contact response header field can contain any suitable URI
+ indicating where the called party can be reached, not limited to SIP
+ URIs. For example, it could contain URIs for phones, fax, or irc (if
+ they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4
+ discusses implications and limitations of redirecting a SIPS URI to a
+ non-SIPS URI.
+
+ The "expires" parameter of a Contact header field value indicates how
+ long the URI is valid. The value of the parameter is a number
+ indicating seconds. If this parameter is not provided, the value of
+ the Expires header field determines how long the URI is valid.
+ Malformed values SHOULD be treated as equivalent to 3600.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 52]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ This provides a modest level of backwards compatibility with RFC
+ 2543, which allowed absolute times in this header field. If an
+ absolute time is received, it will be treated as malformed, and
+ then default to 3600.
+
+ Redirect servers MUST ignore features that are not understood
+ (including unrecognized header fields, any unknown option tags in
+ Require, or even method names) and proceed with the redirection of
+ the request in question.
+
+9 Canceling a Request
+
+ The previous section has discussed general UA behavior for generating
+ requests and processing responses for requests of all methods. In
+ this section, we discuss a general purpose method, called CANCEL.
+
+ The CANCEL request, as the name implies, is used to cancel a previous
+ request sent by a client. Specifically, it asks the UAS to cease
+ processing the request and to generate an error response to that
+ request. CANCEL has no effect on a request to which a UAS has
+ already given a final response. Because of this, it is most useful
+ to CANCEL requests to which it can take a server long time to
+ respond. For this reason, CANCEL is best for INVITE requests, which
+ can take a long time to generate a response. In that usage, a UAS
+ that receives a CANCEL request for an INVITE, but has not yet sent a
+ final response, would "stop ringing", and then respond to the INVITE
+ with a specific error response (a 487).
+
+ CANCEL requests can be constructed and sent by both proxies and user
+ agent clients. Section 15 discusses under what conditions a UAC
+ would CANCEL an INVITE request, and Section 16.10 discusses proxy
+ usage of CANCEL.
+
+ A stateful proxy responds to a CANCEL, rather than simply forwarding
+ a response it would receive from a downstream element. For that
+ reason, CANCEL is referred to as a "hop-by-hop" request, since it is
+ responded to at each stateful proxy hop.
+
+9.1 Client Behavior
+
+ A CANCEL request SHOULD NOT be sent to cancel a request other than
+ INVITE.
+
+ Since requests other than INVITE are responded to immediately,
+ sending a CANCEL for a non-INVITE request would always create a
+ race condition.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 53]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The following procedures are used to construct a CANCEL request. The
+ Request-URI, Call-ID, To, the numeric part of CSeq, and From header
+ fields in the CANCEL request MUST be identical to those in the
+ request being cancelled, including tags. A CANCEL constructed by a
+ client MUST have only a single Via header field value matching the
+ top Via value in the request being cancelled. Using the same values
+ for these header fields allows the CANCEL to be matched with the
+ request it cancels (Section 9.2 indicates how such matching occurs).
+ However, the method part of the CSeq header field MUST have a value
+ of CANCEL. This allows it to be identified and processed as a
+ transaction in its own right (See Section 17).
+
+ If the request being cancelled contains a Route header field, the
+ CANCEL request MUST include that Route header field's values.
+
+ This is needed so that stateless proxies are able to route CANCEL
+ requests properly.
+
+ The CANCEL request MUST NOT contain any Require or Proxy-Require
+ header fields.
+
+ Once the CANCEL is constructed, the client SHOULD check whether it
+ has received any response (provisional or final) for the request
+ being cancelled (herein referred to as the "original request").
+
+ If no provisional response has been received, the CANCEL request MUST
+ NOT be sent; rather, the client MUST wait for the arrival of a
+ provisional response before sending the request. If the original
+ request has generated a final response, the CANCEL SHOULD NOT be
+ sent, as it is an effective no-op, since CANCEL has no effect on
+ requests that have already generated a final response. When the
+ client decides to send the CANCEL, it creates a client transaction
+ for the CANCEL and passes it the CANCEL request along with the
+ destination address, port, and transport. The destination address,
+ port, and transport for the CANCEL MUST be identical to those used to
+ send the original request.
+
+ If it was allowed to send the CANCEL before receiving a response
+ for the previous request, the server could receive the CANCEL
+ before the original request.
+
+ Note that both the transaction corresponding to the original request
+ and the CANCEL transaction will complete independently. However, a
+ UAC canceling a request cannot rely on receiving a 487 (Request
+ Terminated) response for the original request, as an RFC 2543-
+ compliant UAS will not generate such a response. If there is no
+ final response for the original request in 64*T1 seconds (T1 is
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 54]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ defined in Section 17.1.1.1), the client SHOULD then consider the
+ original transaction cancelled and SHOULD destroy the client
+ transaction handling the original request.
+
+9.2 Server Behavior
+
+ The CANCEL method requests that the TU at the server side cancel a
+ pending transaction. The TU determines the transaction to be
+ cancelled by taking the CANCEL request, and then assuming that the
+ request method is anything but CANCEL or ACK and applying the
+ transaction matching procedures of Section 17.2.3. The matching
+ transaction is the one to be cancelled.
+
+ The processing of a CANCEL request at a server depends on the type of
+ server. A stateless proxy will forward it, a stateful proxy might
+ respond to it and generate some CANCEL requests of its own, and a UAS
+ will respond to it. See Section 16.10 for proxy treatment of CANCEL.
+
+ A UAS first processes the CANCEL request according to the general UAS
+ processing described in Section 8.2. However, since CANCEL requests
+ are hop-by-hop and cannot be resubmitted, they cannot be challenged
+ by the server in order to get proper credentials in an Authorization
+ header field. Note also that CANCEL requests do not contain a
+ Require header field.
+
+ If the UAS did not find a matching transaction for the CANCEL
+ according to the procedure above, it SHOULD respond to the CANCEL
+ with a 481 (Call Leg/Transaction Does Not Exist). If the transaction
+ for the original request still exists, the behavior of the UAS on
+ receiving a CANCEL request depends on whether it has already sent a
+ final response for the original request. If it has, the CANCEL
+ request has no effect on the processing of the original request, no
+ effect on any session state, and no effect on the responses generated
+ for the original request. If the UAS has not issued a final response
+ for the original request, its behavior depends on the method of the
+ original request. If the original request was an INVITE, the UAS
+ SHOULD immediately respond to the INVITE with a 487 (Request
+ Terminated). A CANCEL request has no impact on the processing of
+ transactions with any other method defined in this specification.
+
+ Regardless of the method of the original request, as long as the
+ CANCEL matched an existing transaction, the UAS answers the CANCEL
+ request itself with a 200 (OK) response. This response is
+ constructed following the procedures described in Section 8.2.6
+ noting that the To tag of the response to the CANCEL and the To tag
+ in the response to the original request SHOULD be the same. The
+ response to CANCEL is passed to the server transaction for
+ transmission.
+
+
+
+Rosenberg, et. al. Standards Track [Page 55]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+10 Registrations
+
+10.1 Overview
+
+ SIP offers a discovery capability. If a user wants to initiate a
+ session with another user, SIP must discover the current host(s) at
+ which the destination user is reachable. This discovery process is
+ frequently accomplished by SIP network elements such as proxy servers
+ and redirect servers which are responsible for receiving a request,
+ determining where to send it based on knowledge of the location of
+ the user, and then sending it there. To do this, SIP network
+ elements consult an abstract service known as a location service,
+ which provides address bindings for a particular domain. These
+ address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com,
+ for example, to one or more URIs that are somehow "closer" to the
+ desired user, sip:bob@engineering.biloxi.com, for example.
+ Ultimately, a proxy will consult a location service that maps a
+ received URI to the user agent(s) at which the desired recipient is
+ currently residing.
+
+ Registration creates bindings in a location service for a particular
+ domain that associates an address-of-record URI with one or more
+ contact addresses. Thus, when a proxy for that domain receives a
+ request whose Request-URI matches the address-of-record, the proxy
+ will forward the request to the contact addresses registered to that
+ address-of-record. Generally, it only makes sense to register an
+ address-of-record at a domain's location service when requests for
+ that address-of-record would be routed to that domain. In most
+ cases, this means that the domain of the registration will need to
+ match the domain in the URI of the address-of-record.
+
+ There are many ways by which the contents of the location service can
+ be established. One way is administratively. In the above example,
+ Bob is known to be a member of the engineering department through
+ access to a corporate database. However, SIP provides a mechanism
+ for a UA to create a binding explicitly. This mechanism is known as
+ registration.
+
+ Registration entails sending a REGISTER request to a special type of
+ UAS known as a registrar. A registrar acts as the front end to the
+ location service for a domain, reading and writing mappings based on
+ the contents of REGISTER requests. This location service is then
+ typically consulted by a proxy server that is responsible for routing
+ requests for that domain.
+
+ An illustration of the overall registration process is given in
+ Figure 2. Note that the registrar and proxy server are logical roles
+ that can be played by a single device in a network; for purposes of
+
+
+
+Rosenberg, et. al. Standards Track [Page 56]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ clarity the two are separated in this illustration. Also note that
+ UAs may send requests through a proxy server in order to reach a
+ registrar if the two are separate elements.
+
+ SIP does not mandate a particular mechanism for implementing the
+ location service. The only requirement is that a registrar for some
+ domain MUST be able to read and write data to the location service,
+ and a proxy or a redirect server for that domain MUST be capable of
+ reading that same data. A registrar MAY be co-located with a
+ particular SIP proxy server for the same domain.
+
+10.2 Constructing the REGISTER Request
+
+ REGISTER requests add, remove, and query bindings. A REGISTER
+ request can add a new binding between an address-of-record and one or
+ more contact addresses. Registration on behalf of a particular
+ address-of-record can be performed by a suitably authorized third
+ party. A client can also remove previous bindings or query to
+ determine which bindings are currently in place for an address-of-
+ record.
+
+ Except as noted, the construction of the REGISTER request and the
+ behavior of clients sending a REGISTER request is identical to the
+ general UAC behavior described in Section 8.1 and Section 17.1.
+
+ A REGISTER request does not establish a dialog. A UAC MAY include a
+ Route header field in a REGISTER request based on a pre-existing
+ route set as described in Section 8.1. The Record-Route header field
+ has no meaning in REGISTER requests or responses, and MUST be ignored
+ if present. In particular, the UAC MUST NOT create a new route set
+ based on the presence or absence of a Record-Route header field in
+ any response to a REGISTER request.
+
+ The following header fields, except Contact, MUST be included in a
+ REGISTER request. A Contact header field MAY be included:
+
+ Request-URI: The Request-URI names the domain of the location
+ service for which the registration is meant (for example,
+ "sip:chicago.com"). The "userinfo" and "@" components of the
+ SIP URI MUST NOT be present.
+
+ To: The To header field contains the address of record whose
+ registration is to be created, queried, or modified. The To
+ header field and the Request-URI field typically differ, as
+ the former contains a user name. This address-of-record MUST
+ be a SIP URI or SIPS URI.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 57]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ From: The From header field contains the address-of-record of the
+ person responsible for the registration. The value is the
+ same as the To header field unless the request is a third-
+ party registration.
+
+ Call-ID: All registrations from a UAC SHOULD use the same Call-ID
+ header field value for registrations sent to a particular
+ registrar.
+
+ If the same client were to use different Call-ID values, a
+ registrar could not detect whether a delayed REGISTER request
+ might have arrived out of order.
+
+ CSeq: The CSeq value guarantees proper ordering of REGISTER
+ requests. A UA MUST increment the CSeq value by one for each
+ REGISTER request with the same Call-ID.
+
+ Contact: REGISTER requests MAY contain a Contact header field with
+ zero or more values containing address bindings.
+
+ UAs MUST NOT send a new registration (that is, containing new Contact
+ header field values, as opposed to a retransmission) until they have
+ received a final response from the registrar for the previous one or
+ the previous REGISTER request has timed out.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 58]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ bob
+ +----+
+ | UA |
+ | |
+ +----+
+ |
+ |3)INVITE
+ | carol@chicago.com
+ chicago.com +--------+ V
+ +---------+ 2)Store|Location|4)Query +-----+
+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
+ +---------+ +--------+=======>+-----+
+ A 5)Resp |
+ | |
+ | |
+ 1)REGISTER| |
+ | |
+ +----+ |
+ | UA |<-------------------------------+
+ cube2214a| | 6)INVITE
+ +----+ carol@cube2214a.chicago.com
+ carol
+
+ Figure 2: REGISTER example
+
+ The following Contact header parameters have a special meaning in
+ REGISTER requests:
+
+ action: The "action" parameter from RFC 2543 has been deprecated.
+ UACs SHOULD NOT use the "action" parameter.
+
+ expires: The "expires" parameter indicates how long the UA would
+ like the binding to be valid. The value is a number
+ indicating seconds. If this parameter is not provided, the
+ value of the Expires header field is used instead.
+ Implementations MAY treat values larger than 2**32-1
+ (4294967295 seconds or 136 years) as equivalent to 2**32-1.
+ Malformed values SHOULD be treated as equivalent to 3600.
+
+10.2.1 Adding Bindings
+
+ The REGISTER request sent to a registrar includes the contact
+ address(es) to which SIP requests for the address-of-record should be
+ forwarded. The address-of-record is included in the To header field
+ of the REGISTER request.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 59]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The Contact header field values of the request typically consist of
+ SIP or SIPS URIs that identify particular SIP endpoints (for example,
+ "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme.
+ A SIP UA can choose to register telephone numbers (with the tel URL,
+ RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
+ as Contacts for an address-of-record, for example.
+
+ For example, Carol, with address-of-record "sip:carol@chicago.com",
+ would register with the SIP registrar of the domain chicago.com. Her
+ registrations would then be used by a proxy server in the chicago.com
+ domain to route requests for Carol's address-of-record to her SIP
+ endpoint.
+
+ Once a client has established bindings at a registrar, it MAY send
+ subsequent registrations containing new bindings or modifications to
+ existing bindings as necessary. The 2xx response to the REGISTER
+ request will contain, in a Contact header field, a complete list of
+ bindings that have been registered for this address-of-record at this
+ registrar.
+
+ If the address-of-record in the To header field of a REGISTER request
+ is a SIPS URI, then any Contact header field values in the request
+ SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs
+ under a SIPS address-of-record when the security of the resource
+ represented by the contact address is guaranteed by other means.
+ This may be applicable to URIs that invoke protocols other than SIP,
+ or SIP devices secured by protocols other than TLS.
+
+ Registrations do not need to update all bindings. Typically, a UA
+ only updates its own contact addresses.
+
+10.2.1.1 Setting the Expiration Interval of Contact Addresses
+
+ When a client sends a REGISTER request, it MAY suggest an expiration
+ interval that indicates how long the client would like the
+ registration to be valid. (As described in Section 10.3, the
+ registrar selects the actual time interval based on its local
+ policy.)
+
+ There are two ways in which a client can suggest an expiration
+ interval for a binding: through an Expires header field or an
+ "expires" Contact header parameter. The latter allows expiration
+ intervals to be suggested on a per-binding basis when more than one
+ binding is given in a single REGISTER request, whereas the former
+ suggests an expiration interval for all Contact header field values
+ that do not contain the "expires" parameter.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 60]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ If neither mechanism for expressing a suggested expiration time is
+ present in a REGISTER, the client is indicating its desire for the
+ server to choose.
+
+10.2.1.2 Preferences among Contact Addresses
+
+ If more than one Contact is sent in a REGISTER request, the
+ registering UA intends to associate all of the URIs in these Contact
+ header field values with the address-of-record present in the To
+ field. This list can be prioritized with the "q" parameter in the
+ Contact header field. The "q" parameter indicates a relative
+ preference for the particular Contact header field value compared to
+ other bindings for this address-of-record. Section 16.6 describes
+ how a proxy server uses this preference indication.
+
+10.2.2 Removing Bindings
+
+ Registrations are soft state and expire unless refreshed, but can
+ also be explicitly removed. A client can attempt to influence the
+ expiration interval selected by the registrar as described in Section
+ 10.2.1. A UA requests the immediate removal of a binding by
+ specifying an expiration interval of "0" for that contact address in
+ a REGISTER request. UAs SHOULD support this mechanism so that
+ bindings can be removed before their expiration interval has passed.
+
+ The REGISTER-specific Contact header field value of "*" applies to
+ all registrations, but it MUST NOT be used unless the Expires header
+ field is present with a value of "0".
+
+ Use of the "*" Contact header field value allows a registering UA
+ to remove all bindings associated with an address-of-record
+ without knowing their precise values.
+
+10.2.3 Fetching Bindings
+
+ A success response to any REGISTER request contains the complete list
+ of existing bindings, regardless of whether the request contained a
+ Contact header field. If no Contact header field is present in a
+ REGISTER request, the list of bindings is left unchanged.
+
+10.2.4 Refreshing Bindings
+
+ Each UA is responsible for refreshing the bindings that it has
+ previously established. A UA SHOULD NOT refresh bindings set up by
+ other UAs.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 61]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The 200 (OK) response from the registrar contains a list of Contact
+ fields enumerating all current bindings. The UA compares each
+ contact address to see if it created the contact address, using
+ comparison rules in Section 19.1.4. If so, it updates the expiration
+ time interval according to the expires parameter or, if absent, the
+ Expires field value. The UA then issues a REGISTER request for each
+ of its bindings before the expiration interval has elapsed. It MAY
+ combine several updates into one REGISTER request.
+
+ A UA SHOULD use the same Call-ID for all registrations during a
+ single boot cycle. Registration refreshes SHOULD be sent to the same
+ network address as the original registration, unless redirected.
+
+10.2.5 Setting the Internal Clock
+
+ If the response for a REGISTER request contains a Date header field,
+ the client MAY use this header field to learn the current time in
+ order to set any internal clocks.
+
+10.2.6 Discovering a Registrar
+
+ UAs can use three ways to determine the address to which to send
+ registrations: by configuration, using the address-of-record, and
+ multicast. A UA can be configured, in ways beyond the scope of this
+ specification, with a registrar address. If there is no configured
+ registrar address, the UA SHOULD use the host part of the address-
+ of-record as the Request-URI and address the request there, using the
+ normal SIP server location mechanisms [4]. For example, the UA for
+ the user "sip:carol@chicago.com" addresses the REGISTER request to
+ "sip:chicago.com".
+
+ Finally, a UA can be configured to use multicast. Multicast
+ registrations are addressed to the well-known "all SIP servers"
+ multicast address "sip.mcast.net" (224.0.1.75 for IPv4). No well-
+ known IPv6 multicast address has been allocated; such an allocation
+ will be documented separately when needed. SIP UAs MAY listen to
+ that address and use it to become aware of the location of other
+ local users (see [33]); however, they do not respond to the request.
+
+ Multicast registration may be inappropriate in some environments,
+ for example, if multiple businesses share the same local area
+ network.
+
+10.2.7 Transmitting a Request
+
+ Once the REGISTER method has been constructed, and the destination of
+ the message identified, UACs follow the procedures described in
+ Section 8.1.2 to hand off the REGISTER to the transaction layer.
+
+
+
+Rosenberg, et. al. Standards Track [Page 62]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ If the transaction layer returns a timeout error because the REGISTER
+ yielded no response, the UAC SHOULD NOT immediately re-attempt a
+ registration to the same registrar.
+
+ An immediate re-attempt is likely to also timeout. Waiting some
+ reasonable time interval for the conditions causing the timeout to
+ be corrected reduces unnecessary load on the network. No specific
+ interval is mandated.
+
+10.2.8 Error Responses
+
+ If a UA receives a 423 (Interval Too Brief) response, it MAY retry
+ the registration after making the expiration interval of all contact
+ addresses in the REGISTER request equal to or greater than the
+ expiration interval within the Min-Expires header field of the 423
+ (Interval Too Brief) response.
+
+10.3 Processing REGISTER Requests
+
+ A registrar is a UAS that responds to REGISTER requests and maintains
+ a list of bindings that are accessible to proxy servers and redirect
+ servers within its administrative domain. A registrar handles
+ requests according to Section 8.2 and Section 17.2, but it accepts
+ only REGISTER requests. A registrar MUST not generate 6xx responses.
+
+ A registrar MAY redirect REGISTER requests as appropriate. One
+ common usage would be for a registrar listening on a multicast
+ interface to redirect multicast REGISTER requests to its own unicast
+ interface with a 302 (Moved Temporarily) response.
+
+ Registrars MUST ignore the Record-Route header field if it is
+ included in a REGISTER request. Registrars MUST NOT include a
+ Record-Route header field in any response to a REGISTER request.
+
+ A registrar might receive a request that traversed a proxy which
+ treats REGISTER as an unknown request and which added a Record-
+ Route header field value.
+
+ A registrar has to know (for example, through configuration) the set
+ of domain(s) for which it maintains bindings. REGISTER requests MUST
+ be processed by a registrar in the order that they are received.
+ REGISTER requests MUST also be processed atomically, meaning that a
+ particular REGISTER request is either processed completely or not at
+ all. Each REGISTER message MUST be processed independently of any
+ other registration or binding changes.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 63]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ When receiving a REGISTER request, a registrar follows these steps:
+
+ 1. The registrar inspects the Request-URI to determine whether it
+ has access to bindings for the domain identified in the
+ Request-URI. If not, and if the server also acts as a proxy
+ server, the server SHOULD forward the request to the addressed
+ domain, following the general behavior for proxying messages
+ described in Section 16.
+
+ 2. To guarantee that the registrar supports any necessary
+ extensions, the registrar MUST process the Require header field
+ values as described for UASs in Section 8.2.2.
+
+ 3. A registrar SHOULD authenticate the UAC. Mechanisms for the
+ authentication of SIP user agents are described in Section 22.
+ Registration behavior in no way overrides the generic
+ authentication framework for SIP. If no authentication
+ mechanism is available, the registrar MAY take the From address
+ as the asserted identity of the originator of the request.
+
+ 4. The registrar SHOULD determine if the authenticated user is
+ authorized to modify registrations for this address-of-record.
+ For example, a registrar might consult an authorization
+ database that maps user names to a list of addresses-of-record
+ for which that user has authorization to modify bindings. If
+ the authenticated user is not authorized to modify bindings,
+ the registrar MUST return a 403 (Forbidden) and skip the
+ remaining steps.
+
+ In architectures that support third-party registration, one
+ entity may be responsible for updating the registrations
+ associated with multiple addresses-of-record.
+
+ 5. The registrar extracts the address-of-record from the To header
+ field of the request. If the address-of-record is not valid
+ for the domain in the Request-URI, the registrar MUST send a
+ 404 (Not Found) response and skip the remaining steps. The URI
+ MUST then be converted to a canonical form. To do that, all
+ URI parameters MUST be removed (including the user-param), and
+ any escaped characters MUST be converted to their unescaped
+ form. The result serves as an index into the list of bindings.
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 64]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 6. The registrar checks whether the request contains the Contact
+ header field. If not, it skips to the last step. If the
+ Contact header field is present, the registrar checks if there
+ is one Contact field value that contains the special value "*"
+ and an Expires field. If the request has additional Contact
+ fields or an expiration time other than zero, the request is
+ invalid, and the server MUST return a 400 (Invalid Request) and
+ skip the remaining steps. If not, the registrar checks whether
+ the Call-ID agrees with the value stored for each binding. If
+ not, it MUST remove the binding. If it does agree, it MUST
+ remove the binding only if the CSeq in the request is higher
+ than the value stored for that binding. Otherwise, the update
+ MUST be aborted and the request fails.
+
+ 7. The registrar now processes each contact address in the Contact
+ header field in turn. For each address, it determines the
+ expiration interval as follows:
+
+ - If the field value has an "expires" parameter, that value
+ MUST be taken as the requested expiration.
+
+ - If there is no such parameter, but the request has an
+ Expires header field, that value MUST be taken as the
+ requested expiration.
+
+ - If there is neither, a locally-configured default value MUST
+ be taken as the requested expiration.
+
+ The registrar MAY choose an expiration less than the requested
+ expiration interval. If and only if the requested expiration
+ interval is greater than zero AND smaller than one hour AND
+ less than a registrar-configured minimum, the registrar MAY
+ reject the registration with a response of 423 (Interval Too
+ Brief). This response MUST contain a Min-Expires header field
+ that states the minimum expiration interval the registrar is
+ willing to honor. It then skips the remaining steps.
+
+ Allowing the registrar to set the registration interval
+ protects it against excessively frequent registration refreshes
+ while limiting the state that it needs to maintain and
+ decreasing the likelihood of registrations going stale. The
+ expiration interval of a registration is frequently used in the
+ creation of services. An example is a follow-me service, where
+ the user may only be available at a terminal for a brief
+ period. Therefore, registrars should accept brief
+ registrations; a request should only be rejected if the
+ interval is so short that the refreshes would degrade registrar
+ performance.
+
+
+
+Rosenberg, et. al. Standards Track [Page 65]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ For each address, the registrar then searches the list of
+ current bindings using the URI comparison rules. If the
+ binding does not exist, it is tentatively added. If the
+ binding does exist, the registrar checks the Call-ID value. If
+ the Call-ID value in the existing binding differs from the
+ Call-ID value in the request, the binding MUST be removed if
+ the expiration time is zero and updated otherwise. If they are
+ the same, the registrar compares the CSeq value. If the value
+ is higher than that of the existing binding, it MUST update or
+ remove the binding as above. If not, the update MUST be
+ aborted and the request fails.
+
+ This algorithm ensures that out-of-order requests from the same
+ UA are ignored.
+
+ Each binding record records the Call-ID and CSeq values from
+ the request.
+
+ The binding updates MUST be committed (that is, made visible to
+ the proxy or redirect server) if and only if all binding
+ updates and additions succeed. If any one of them fails (for
+ example, because the back-end database commit failed), the
+ request MUST fail with a 500 (Server Error) response and all
+ tentative binding updates MUST be removed.
+
+ 8. The registrar returns a 200 (OK) response. The response MUST
+ contain Contact header field values enumerating all current
+ bindings. Each Contact value MUST feature an "expires"
+ parameter indicating its expiration interval chosen by the
+ registrar. The response SHOULD include a Date header field.
+
+11 Querying for Capabilities
+
+ The SIP method OPTIONS allows a UA to query another UA or a proxy
+ server as to its capabilities. This allows a client to discover
+ information about the supported methods, content types, extensions,
+ codecs, etc. without "ringing" the other party. For example, before
+ a client inserts a Require header field into an INVITE listing an
+ option that it is not certain the destination UAS supports, the
+ client can query the destination UAS with an OPTIONS to see if this
+ option is returned in a Supported header field. All UAs MUST support
+ the OPTIONS method.
+
+ The target of the OPTIONS request is identified by the Request-URI,
+ which could identify another UA or a SIP server. If the OPTIONS is
+ addressed to a proxy server, the Request-URI is set without a user
+ part, similar to the way a Request-URI is set for a REGISTER request.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 66]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Alternatively, a server receiving an OPTIONS request with a Max-
+ Forwards header field value of 0 MAY respond to the request
+ regardless of the Request-URI.
+
+ This behavior is common with HTTP/1.1. This behavior can be used
+ as a "traceroute" functionality to check the capabilities of
+ individual hop servers by sending a series of OPTIONS requests
+ with incremented Max-Forwards values.
+
+ As is the case for general UA behavior, the transaction layer can
+ return a timeout error if the OPTIONS yields no response. This may
+ indicate that the target is unreachable and hence unavailable.
+
+ An OPTIONS request MAY be sent as part of an established dialog to
+ query the peer on capabilities that may be utilized later in the
+ dialog.
+
+11.1 Construction of OPTIONS Request
+
+ An OPTIONS request is constructed using the standard rules for a SIP
+ request as discussed in Section 8.1.1.
+
+ A Contact header field MAY be present in an OPTIONS.
+
+ An Accept header field SHOULD be included to indicate the type of
+ message body the UAC wishes to receive in the response. Typically,
+ this is set to a format that is used to describe the media
+ capabilities of a UA, such as SDP (application/sdp).
+
+ The response to an OPTIONS request is assumed to be scoped to the
+ Request-URI in the original request. However, only when an OPTIONS
+ is sent as part of an established dialog is it guaranteed that future
+ requests will be received by the server that generated the OPTIONS
+ response.
+
+ Example OPTIONS request:
+
+ OPTIONS sip:carol@chicago.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
+ Max-Forwards: 70
+ To: <sip:carol@chicago.com>
+ From: Alice <sip:alice@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 63104 OPTIONS
+ Contact: <sip:alice@pc33.atlanta.com>
+ Accept: application/sdp
+ Content-Length: 0
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 67]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+11.2 Processing of OPTIONS Request
+
+ The response to an OPTIONS is constructed using the standard rules
+ for a SIP response as discussed in Section 8.2.6. The response code
+ chosen MUST be the same that would have been chosen had the request
+ been an INVITE. That is, a 200 (OK) would be returned if the UAS is
+ ready to accept a call, a 486 (Busy Here) would be returned if the
+ UAS is busy, etc. This allows an OPTIONS request to be used to
+ determine the basic state of a UAS, which can be an indication of
+ whether the UAS will accept an INVITE request.
+
+ An OPTIONS request received within a dialog generates a 200 (OK)
+ response that is identical to one constructed outside a dialog and
+ does not have any impact on the dialog.
+
+ This use of OPTIONS has limitations due to the differences in proxy
+ handling of OPTIONS and INVITE requests. While a forked INVITE can
+ result in multiple 200 (OK) responses being returned, a forked
+ OPTIONS will only result in a single 200 (OK) response, since it is
+ treated by proxies using the non-INVITE handling. See Section 16.7
+ for the normative details.
+
+ If the response to an OPTIONS is generated by a proxy server, the
+ proxy returns a 200 (OK), listing the capabilities of the server.
+ The response does not contain a message body.
+
+ Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
+ fields SHOULD be present in a 200 (OK) response to an OPTIONS
+ request. If the response is generated by a proxy, the Allow header
+ field SHOULD be omitted as it is ambiguous since a proxy is method
+ agnostic. Contact header fields MAY be present in a 200 (OK)
+ response and have the same semantics as in a 3xx response. That is,
+ they may list a set of alternative names and methods of reaching the
+ user. A Warning header field MAY be present.
+
+ A message body MAY be sent, the type of which is determined by the
+ Accept header field in the OPTIONS request (application/sdp is the
+ default if the Accept header field is not present). If the types
+ include one that can describe media capabilities, the UAS SHOULD
+ include a body in the response for that purpose. Details on the
+ construction of such a body in the case of application/sdp are
+ described in [13].
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 68]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Example OPTIONS response generated by a UAS (corresponding to the
+ request in Section 11.1):
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
+ ;received=192.0.2.4
+ To: <sip:carol@chicago.com>;tag=93810874
+ From: Alice <sip:alice@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 63104 OPTIONS
+ Contact: <sip:carol@chicago.com>
+ Contact: <mailto:carol@chicago.com>
+ Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
+ Accept: application/sdp
+ Accept-Encoding: gzip
+ Accept-Language: en
+ Supported: foo
+ Content-Type: application/sdp
+ Content-Length: 274
+
+ (SDP not shown)
+
+12 Dialogs
+
+ A key concept for a user agent is that of a dialog. A dialog
+ represents a peer-to-peer SIP relationship between two user agents
+ that persists for some time. The dialog facilitates sequencing of
+ messages between the user agents and proper routing of requests
+ between both of them. The dialog represents a context in which to
+ interpret SIP messages. Section 8 discussed method independent UA
+ processing for requests and responses outside of a dialog. This
+ section discusses how those requests and responses are used to
+ construct a dialog, and then how subsequent requests and responses
+ are sent within a dialog.
+
+ A dialog is identified at each UA with a dialog ID, which consists of
+ a Call-ID value, a local tag and a remote tag. The dialog ID at each
+ UA involved in the dialog is not the same. Specifically, the local
+ tag at one UA is identical to the remote tag at the peer UA. The
+ tags are opaque tokens that facilitate the generation of unique
+ dialog IDs.
+
+ A dialog ID is also associated with all responses and with any
+ request that contains a tag in the To field. The rules for computing
+ the dialog ID of a message depend on whether the SIP element is a UAC
+ or UAS. For a UAC, the Call-ID value of the dialog ID is set to the
+ Call-ID of the message, the remote tag is set to the tag in the To
+ field of the message, and the local tag is set to the tag in the From
+
+
+
+Rosenberg, et. al. Standards Track [Page 69]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ field of the message (these rules apply to both requests and
+ responses). As one would expect for a UAS, the Call-ID value of the
+ dialog ID is set to the Call-ID of the message, the remote tag is set
+ to the tag in the From field of the message, and the local tag is set
+ to the tag in the To field of the message.
+
+ A dialog contains certain pieces of state needed for further message
+ transmissions within the dialog. This state consists of the dialog
+ ID, a local sequence number (used to order requests from the UA to
+ its peer), a remote sequence number (used to order requests from its
+ peer to the UA), a local URI, a remote URI, remote target, a boolean
+ flag called "secure", and a route set, which is an ordered list of
+ URIs. The route set is the list of servers that need to be traversed
+ to send a request to the peer. A dialog can also be in the "early"
+ state, which occurs when it is created with a provisional response,
+ and then transition to the "confirmed" state when a 2xx final
+ response arrives. For other responses, or if no response arrives at
+ all on that dialog, the early dialog terminates.
+
+12.1 Creation of a Dialog
+
+ Dialogs are created through the generation of non-failure responses
+ to requests with specific methods. Within this specification, only
+ 2xx and 101-199 responses with a To tag, where the request was
+ INVITE, will establish a dialog. A dialog established by a non-final
+ response to a request is in the "early" state and it is called an
+ early dialog. Extensions MAY define other means for creating
+ dialogs. Section 13 gives more details that are specific to the
+ INVITE method. Here, we describe the process for creation of dialog
+ state that is not dependent on the method.
+
+ UAs MUST assign values to the dialog ID components as described
+ below.
+
+12.1.1 UAS behavior
+
+ When a UAS responds to a request with a response that establishes a
+ dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
+ header field values from the request into the response (including the
+ URIs, URI parameters, and any Record-Route header field parameters,
+ whether they are known or unknown to the UAS) and MUST maintain the
+ order of those values. The UAS MUST add a Contact header field to
+ the response. The Contact header field contains an address where the
+ UAS would like to be contacted for subsequent requests in the dialog
+ (which includes the ACK for a 2xx response in the case of an INVITE).
+ Generally, the host portion of this URI is the IP address or FQDN of
+ the host. The URI provided in the Contact header field MUST be a SIP
+ or SIPS URI. If the request that initiated the dialog contained a
+
+
+
+Rosenberg, et. al. Standards Track [Page 70]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ SIPS URI in the Request-URI or in the top Record-Route header field
+ value, if there was any, or the Contact header field if there was no
+ Record-Route header field, the Contact header field in the response
+ MUST be a SIPS URI. The URI SHOULD have global scope (that is, the
+ same URI can be used in messages outside this dialog). The same way,
+ the scope of the URI in the Contact header field of the INVITE is not
+ limited to this dialog either. It can therefore be used in messages
+ to the UAC even outside this dialog.
+
+ The UAS then constructs the state of the dialog. This state MUST be
+ maintained for the duration of the dialog.
+
+ If the request arrived over TLS, and the Request-URI contained a SIPS
+ URI, the "secure" flag is set to TRUE.
+
+ The route set MUST be set to the list of URIs in the Record-Route
+ header field from the request, taken in order and preserving all URI
+ parameters. If no Record-Route header field is present in the
+ request, the route set MUST be set to the empty set. This route set,
+ even if empty, overrides any pre-existing route set for future
+ requests in this dialog. The remote target MUST be set to the URI
+ from the Contact header field of the request.
+
+ The remote sequence number MUST be set to the value of the sequence
+ number in the CSeq header field of the request. The local sequence
+ number MUST be empty. The call identifier component of the dialog ID
+ MUST be set to the value of the Call-ID in the request. The local
+ tag component of the dialog ID MUST be set to the tag in the To field
+ in the response to the request (which always includes a tag), and the
+ remote tag component of the dialog ID MUST be set to the tag from the
+ From field in the request. A UAS MUST be prepared to receive a
+ request without a tag in the From field, in which case the tag is
+ considered to have a value of null.
+
+ This is to maintain backwards compatibility with RFC 2543, which
+ did not mandate From tags.
+
+ The remote URI MUST be set to the URI in the From field, and the
+ local URI MUST be set to the URI in the To field.
+
+12.1.2 UAC Behavior
+
+ When a UAC sends a request that can establish a dialog (such as an
+ INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,
+ the same SIP URI can be used in messages outside this dialog) in the
+ Contact header field of the request. If the request has a Request-
+ URI or a topmost Route header field value with a SIPS URI, the
+ Contact header field MUST contain a SIPS URI.
+
+
+
+Rosenberg, et. al. Standards Track [Page 71]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ When a UAC receives a response that establishes a dialog, it
+ constructs the state of the dialog. This state MUST be maintained
+ for the duration of the dialog.
+
+ If the request was sent over TLS, and the Request-URI contained a
+ SIPS URI, the "secure" flag is set to TRUE.
+
+ The route set MUST be set to the list of URIs in the Record-Route
+ header field from the response, taken in reverse order and preserving
+ all URI parameters. If no Record-Route header field is present in
+ the response, the route set MUST be set to the empty set. This route
+ set, even if empty, overrides any pre-existing route set for future
+ requests in this dialog. The remote target MUST be set to the URI
+ from the Contact header field of the response.
+
+ The local sequence number MUST be set to the value of the sequence
+ number in the CSeq header field of the request. The remote sequence
+ number MUST be empty (it is established when the remote UA sends a
+ request within the dialog). The call identifier component of the
+ dialog ID MUST be set to the value of the Call-ID in the request.
+ The local tag component of the dialog ID MUST be set to the tag in
+ the From field in the request, and the remote tag component of the
+ dialog ID MUST be set to the tag in the To field of the response. A
+ UAC MUST be prepared to receive a response without a tag in the To
+ field, in which case the tag is considered to have a value of null.
+
+ This is to maintain backwards compatibility with RFC 2543, which
+ did not mandate To tags.
+
+ The remote URI MUST be set to the URI in the To field, and the local
+ URI MUST be set to the URI in the From field.
+
+12.2 Requests within a Dialog
+
+ Once a dialog has been established between two UAs, either of them
+ MAY initiate new transactions as needed within the dialog. The UA
+ sending the request will take the UAC role for the transaction. The
+ UA receiving the request will take the UAS role. Note that these may
+ be different roles than the UAs held during the transaction that
+ established the dialog.
+
+ Requests within a dialog MAY contain Record-Route and Contact header
+ fields. However, these requests do not cause the dialog's route set
+ to be modified, although they may modify the remote target URI.
+ Specifically, requests that are not target refresh requests do not
+ modify the dialog's remote target URI, and requests that are target
+ refresh requests do. For dialogs that have been established with an
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 72]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ INVITE, the only target refresh request defined is re-INVITE (see
+ Section 14). Other extensions may define different target refresh
+ requests for dialogs established in other ways.
+
+ Note that an ACK is NOT a target refresh request.
+
+ Target refresh requests only update the dialog's remote target URI,
+ and not the route set formed from the Record-Route. Updating the
+ latter would introduce severe backwards compatibility problems with
+ RFC 2543-compliant systems.
+
+12.2.1 UAC Behavior
+
+12.2.1.1 Generating the Request
+
+ A request within a dialog is constructed by using many of the
+ components of the state stored as part of the dialog.
+
+ The URI in the To field of the request MUST be set to the remote URI
+ from the dialog state. The tag in the To header field of the request
+ MUST be set to the remote tag of the dialog ID. The From URI of the
+ request MUST be set to the local URI from the dialog state. The tag
+ in the From header field of the request MUST be set to the local tag
+ of the dialog ID. If the value of the remote or local tags is null,
+ the tag parameter MUST be omitted from the To or From header fields,
+ respectively.
+
+ Usage of the URI from the To and From fields in the original
+ request within subsequent requests is done for backwards
+ compatibility with RFC 2543, which used the URI for dialog
+ identification. In this specification, only the tags are used for
+ dialog identification. It is expected that mandatory reflection
+ of the original To and From URI in mid-dialog requests will be
+ deprecated in a subsequent revision of this specification.
+
+ The Call-ID of the request MUST be set to the Call-ID of the dialog.
+ Requests within a dialog MUST contain strictly monotonically
+ increasing and contiguous CSeq sequence numbers (increasing-by-one)
+ in each direction (excepting ACK and CANCEL of course, whose numbers
+ equal the requests being acknowledged or cancelled). Therefore, if
+ the local sequence number is not empty, the value of the local
+ sequence number MUST be incremented by one, and this value MUST be
+ placed into the CSeq header field. If the local sequence number is
+ empty, an initial value MUST be chosen using the guidelines of
+ Section 8.1.1.5. The method field in the CSeq header field value
+ MUST match the method of the request.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 73]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ With a length of 32 bits, a client could generate, within a single
+ call, one request a second for about 136 years before needing to
+ wrap around. The initial value of the sequence number is chosen
+ so that subsequent requests within the same call will not wrap
+ around. A non-zero initial value allows clients to use a time-
+ based initial sequence number. A client could, for example,
+ choose the 31 most significant bits of a 32-bit second clock as an
+ initial sequence number.
+
+ The UAC uses the remote target and route set to build the Request-URI
+ and Route header field of the request.
+
+ If the route set is empty, the UAC MUST place the remote target URI
+ into the Request-URI. The UAC MUST NOT add a Route header field to
+ the request.
+
+ If the route set is not empty, and the first URI in the route set
+ contains the lr parameter (see Section 19.1.1), the UAC MUST place
+ the remote target URI into the Request-URI and MUST include a Route
+ header field containing the route set values in order, including all
+ parameters.
+
+ If the route set is not empty, and its first URI does not contain the
+ lr parameter, the UAC MUST place the first URI from the route set
+ into the Request-URI, stripping any parameters that are not allowed
+ in a Request-URI. The UAC MUST add a Route header field containing
+ the remainder of the route set values in order, including all
+ parameters. The UAC MUST then place the remote target URI into the
+ Route header field as the last value.
+
+ For example, if the remote target is sip:user@remoteua and the route
+ set contains:
+
+ <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
+
+ The request will be formed with the following Request-URI and Route
+ header field:
+
+ METHOD sip:proxy1
+ Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
+
+ If the first URI of the route set does not contain the lr
+ parameter, the proxy indicated does not understand the routing
+ mechanisms described in this document and will act as specified in
+ RFC 2543, replacing the Request-URI with the first Route header
+ field value it receives while forwarding the message. Placing the
+ Request-URI at the end of the Route header field preserves the
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 74]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ information in that Request-URI across the strict router (it will
+ be returned to the Request-URI when the request reaches a loose-
+ router).
+
+ A UAC SHOULD include a Contact header field in any target refresh
+ requests within a dialog, and unless there is a need to change it,
+ the URI SHOULD be the same as used in previous requests within the
+ dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.
+ As discussed in Section 12.2.2, a Contact header field in a target
+ refresh request updates the remote target URI. This allows a UA to
+ provide a new contact address, should its address change during the
+ duration of the dialog.
+
+ However, requests that are not target refresh requests do not affect
+ the remote target URI for the dialog.
+
+ The rest of the request is formed as described in Section 8.1.1.
+
+ Once the request has been constructed, the address of the server is
+ computed and the request is sent, using the same procedures for
+ requests outside of a dialog (Section 8.1.2).
+
+ The procedures in Section 8.1.2 will normally result in the
+ request being sent to the address indicated by the topmost Route
+ header field value or the Request-URI if no Route header field is
+ present. Subject to certain restrictions, they allow the request
+ to be sent to an alternate address (such as a default outbound
+ proxy not represented in the route set).
+
+12.2.1.2 Processing the Responses
+
+ The UAC will receive responses to the request from the transaction
+ layer. If the client transaction returns a timeout, this is treated
+ as a 408 (Request Timeout) response.
+
+ The behavior of a UAC that receives a 3xx response for a request sent
+ within a dialog is the same as if the request had been sent outside a
+ dialog. This behavior is described in Section 8.1.3.4.
+
+ Note, however, that when the UAC tries alternative locations, it
+ still uses the route set for the dialog to build the Route header
+ of the request.
+
+ When a UAC receives a 2xx response to a target refresh request, it
+ MUST replace the dialog's remote target URI with the URI from the
+ Contact header field in that response, if present.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 75]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ If the response for a request within a dialog is a 481
+ (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
+ SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if
+ no response at all is received for the request (the client
+ transaction would inform the TU about the timeout.)
+
+ For INVITE initiated dialogs, terminating the dialog consists of
+ sending a BYE.
+
+12.2.2 UAS Behavior
+
+ Requests sent within a dialog, as any other requests, are atomic. If
+ a particular request is accepted by the UAS, all the state changes
+ associated with it are performed. If the request is rejected, none
+ of the state changes are performed.
+
+ Note that some requests, such as INVITEs, affect several pieces of
+ state.
+
+ The UAS will receive the request from the transaction layer. If the
+ request has a tag in the To header field, the UAS core computes the
+ dialog identifier corresponding to the request and compares it with
+ existing dialogs. If there is a match, this is a mid-dialog request.
+ In that case, the UAS first applies the same processing rules for
+ requests outside of a dialog, discussed in Section 8.2.
+
+ If the request has a tag in the To header field, but the dialog
+ identifier does not match any existing dialogs, the UAS may have
+ crashed and restarted, or it may have received a request for a
+ different (possibly failed) UAS (the UASs can construct the To tags
+ so that a UAS can identify that the tag was for a UAS for which it is
+ providing recovery). Another possibility is that the incoming
+ request has been simply misrouted. Based on the To tag, the UAS MAY
+ either accept or reject the request. Accepting the request for
+ acceptable To tags provides robustness, so that dialogs can persist
+ even through crashes. UAs wishing to support this capability must
+ take into consideration some issues such as choosing monotonically
+ increasing CSeq sequence numbers even across reboots, reconstructing
+ the route set, and accepting out-of-range RTP timestamps and sequence
+ numbers.
+
+ If the UAS wishes to reject the request because it does not wish to
+ recreate the dialog, it MUST respond to the request with a 481
+ (Call/Transaction Does Not Exist) status code and pass that to the
+ server transaction.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 76]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Requests that do not change in any way the state of a dialog may be
+ received within a dialog (for example, an OPTIONS request). They are
+ processed as if they had been received outside the dialog.
+
+ If the remote sequence number is empty, it MUST be set to the value
+ of the sequence number in the CSeq header field value in the request.
+ If the remote sequence number was not empty, but the sequence number
+ of the request is lower than the remote sequence number, the request
+ is out of order and MUST be rejected with a 500 (Server Internal
+ Error) response. If the remote sequence number was not empty, and
+ the sequence number of the request is greater than the remote
+ sequence number, the request is in order. It is possible for the
+ CSeq sequence number to be higher than the remote sequence number by
+ more than one. This is not an error condition, and a UAS SHOULD be
+ prepared to receive and process requests with CSeq values more than
+ one higher than the previous received request. The UAS MUST then set
+ the remote sequence number to the value of the sequence number in the
+ CSeq header field value in the request.
+
+ If a proxy challenges a request generated by the UAC, the UAC has
+ to resubmit the request with credentials. The resubmitted request
+ will have a new CSeq number. The UAS will never see the first
+ request, and thus, it will notice a gap in the CSeq number space.
+ Such a gap does not represent any error condition.
+
+ When a UAS receives a target refresh request, it MUST replace the
+ dialog's remote target URI with the URI from the Contact header field
+ in that request, if present.
+
+12.3 Termination of a Dialog
+
+ Independent of the method, if a request outside of a dialog generates
+ a non-2xx final response, any early dialogs created through
+ provisional responses to that request are terminated. The mechanism
+ for terminating confirmed dialogs is method specific. In this
+ specification, the BYE method terminates a session and the dialog
+ associated with it. See Section 15 for details.
+
+13 Initiating a Session
+
+13.1 Overview
+
+ When a user agent client desires to initiate a session (for example,
+ audio, video, or a game), it formulates an INVITE request. The
+ INVITE request asks a server to establish a session. This request
+ may be forwarded by proxies, eventually arriving at one or more UAS
+ that can potentially accept the invitation. These UASs will
+ frequently need to query the user about whether to accept the
+
+
+
+Rosenberg, et. al. Standards Track [Page 77]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ invitation. After some time, those UASs can accept the invitation
+ (meaning the session is to be established) by sending a 2xx response.
+ If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is
+ sent, depending on the reason for the rejection. Before sending a
+ final response, the UAS can also send provisional responses (1xx) to
+ advise the UAC of progress in contacting the called user.
+
+ After possibly receiving one or more provisional responses, the UAC
+ will get one or more 2xx responses or one non-2xx final response.
+ Because of the protracted amount of time it can take to receive final
+ responses to INVITE, the reliability mechanisms for INVITE
+ transactions differ from those of other requests (like OPTIONS).
+ Once it receives a final response, the UAC needs to send an ACK for
+ every final response it receives. The procedure for sending this ACK
+ depends on the type of response. For final responses between 300 and
+ 699, the ACK processing is done in the transaction layer and follows
+ one set of rules (See Section 17). For 2xx responses, the ACK is
+ generated by the UAC core.
+
+ A 2xx response to an INVITE establishes a session, and it also
+ creates a dialog between the UA that issued the INVITE and the UA
+ that generated the 2xx response. Therefore, when multiple 2xx
+ responses are received from different remote UAs (because the INVITE
+ forked), each 2xx establishes a different dialog. All these dialogs
+ are part of the same call.
+
+ This section provides details on the establishment of a session using
+ INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and
+ BYE.
+
+13.2 UAC Processing
+
+13.2.1 Creating the Initial INVITE
+
+ Since the initial INVITE represents a request outside of a dialog,
+ its construction follows the procedures of Section 8.1.1. Additional
+ processing is required for the specific case of INVITE.
+
+ An Allow header field (Section 20.5) SHOULD be present in the INVITE.
+ It indicates what methods can be invoked within a dialog, on the UA
+ sending the INVITE, for the duration of the dialog. For example, a
+ UA capable of receiving INFO requests within a dialog [34] SHOULD
+ include an Allow header field listing the INFO method.
+
+ A Supported header field (Section 20.37) SHOULD be present in the
+ INVITE. It enumerates all the extensions understood by the UAC.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 78]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ An Accept (Section 20.1) header field MAY be present in the INVITE.
+ It indicates which Content-Types are acceptable to the UA, in both
+ the response received by it, and in any subsequent requests sent to
+ it within dialogs established by the INVITE. The Accept header field
+ is especially useful for indicating support of various session
+ description formats.
+
+ The UAC MAY add an Expires header field (Section 20.19) to limit the
+ validity of the invitation. If the time indicated in the Expires
+ header field is reached and no final answer for the INVITE has been
+ received, the UAC core SHOULD generate a CANCEL request for the
+ INVITE, as per Section 9.
+
+ A UAC MAY also find it useful to add, among others, Subject (Section
+ 20.36), Organization (Section 20.25) and User-Agent (Section 20.41)
+ header fields. They all contain information related to the INVITE.
+
+ The UAC MAY choose to add a message body to the INVITE. Section
+ 8.1.1.10 deals with how to construct the header fields -- Content-
+ Type among others -- needed to describe the message body.
+
+ There are special rules for message bodies that contain a session
+ description - their corresponding Content-Disposition is "session".
+ SIP uses an offer/answer model where one UA sends a session
+ description, called the offer, which contains a proposed description
+ of the session. The offer indicates the desired communications means
+ (audio, video, games), parameters of those means (such as codec
+ types) and addresses for receiving media from the answerer. The
+ other UA responds with another session description, called the
+ answer, which indicates which communications means are accepted, the
+ parameters that apply to those means, and addresses for receiving
+ media from the offerer. An offer/answer exchange is within the
+ context of a dialog, so that if a SIP INVITE results in multiple
+ dialogs, each is a separate offer/answer exchange. The offer/answer
+ model defines restrictions on when offers and answers can be made
+ (for example, you cannot make a new offer while one is in progress).
+ This results in restrictions on where the offers and answers can
+ appear in SIP messages. In this specification, offers and answers
+ can only appear in INVITE requests and responses, and ACK. The usage
+ of offers and answers is further restricted. For the initial INVITE
+ transaction, the rules are:
+
+ o The initial offer MUST be in either an INVITE or, if not there,
+ in the first reliable non-failure message from the UAS back to
+ the UAC. In this specification, that is the final 2xx
+ response.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 79]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o If the initial offer is in an INVITE, the answer MUST be in a
+ reliable non-failure message from UAS back to UAC which is
+ correlated to that INVITE. For this specification, that is
+ only the final 2xx response to that INVITE. That same exact
+ answer MAY also be placed in any provisional responses sent
+ prior to the answer. The UAC MUST treat the first session
+ description it receives as the answer, and MUST ignore any
+ session descriptions in subsequent responses to the initial
+ INVITE.
+
+ o If the initial offer is in the first reliable non-failure
+ message from the UAS back to UAC, the answer MUST be in the
+ acknowledgement for that message (in this specification, ACK
+ for a 2xx response).
+
+ o After having sent or received an answer to the first offer, the
+ UAC MAY generate subsequent offers in requests based on rules
+ specified for that method, but only if it has received answers
+ to any previous offers, and has not sent any offers to which it
+ hasn't gotten an answer.
+
+ o Once the UAS has sent or received an answer to the initial
+ offer, it MUST NOT generate subsequent offers in any responses
+ to the initial INVITE. This means that a UAS based on this
+ specification alone can never generate subsequent offers until
+ completion of the initial transaction.
+
+ Concretely, the above rules specify two exchanges for UAs compliant
+ to this specification alone - the offer is in the INVITE, and the
+ answer in the 2xx (and possibly in a 1xx as well, with the same
+ value), or the offer is in the 2xx, and the answer is in the ACK.
+ All user agents that support INVITE MUST support these two exchanges.
+
+ The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be
+ supported by all user agents as a means to describe sessions, and its
+ usage for constructing offers and answers MUST follow the procedures
+ defined in [13].
+
+ The restrictions of the offer-answer model just described only apply
+ to bodies whose Content-Disposition header field value is "session".
+ Therefore, it is possible that both the INVITE and the ACK contain a
+ body message (for example, the INVITE carries a photo (Content-
+ Disposition: render) and the ACK a session description (Content-
+ Disposition: session)).
+
+ If the Content-Disposition header field is missing, bodies of
+ Content-Type application/sdp imply the disposition "session", while
+ other content types imply "render".
+
+
+
+Rosenberg, et. al. Standards Track [Page 80]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Once the INVITE has been created, the UAC follows the procedures
+ defined for sending requests outside of a dialog (Section 8). This
+ results in the construction of a client transaction that will
+ ultimately send the request and deliver responses to the UAC.
+
+13.2.2 Processing INVITE Responses
+
+ Once the INVITE has been passed to the INVITE client transaction, the
+ UAC waits for responses for the INVITE. If the INVITE client
+ transaction returns a timeout rather than a response the TU acts as
+ if a 408 (Request Timeout) response had been received, as described
+ in Section 8.1.3.
+
+13.2.2.1 1xx Responses
+
+ Zero, one or multiple provisional responses may arrive before one or
+ more final responses are received. Provisional responses for an
+ INVITE request can create "early dialogs". If a provisional response
+ has a tag in the To field, and if the dialog ID of the response does
+ not match an existing dialog, one is constructed using the procedures
+ defined in Section 12.1.2.
+
+ The early dialog will only be needed if the UAC needs to send a
+ request to its peer within the dialog before the initial INVITE
+ transaction completes. Header fields present in a provisional
+ response are applicable as long as the dialog is in the early state
+ (for example, an Allow header field in a provisional response
+ contains the methods that can be used in the dialog while this is in
+ the early state).
+
+13.2.2.2 3xx Responses
+
+ A 3xx response may contain one or more Contact header field values
+ providing new addresses where the callee might be reachable.
+ Depending on the status code of the 3xx response (see Section 21.3),
+ the UAC MAY choose to try those new addresses.
+
+13.2.2.3 4xx, 5xx and 6xx Responses
+
+ A single non-2xx final response may be received for the INVITE. 4xx,
+ 5xx and 6xx responses may contain a Contact header field value
+ indicating the location where additional information about the error
+ can be found. Subsequent final responses (which would only arrive
+ under error conditions) MUST be ignored.
+
+ All early dialogs are considered terminated upon reception of the
+ non-2xx final response.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 81]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ After having received the non-2xx final response the UAC core
+ considers the INVITE transaction completed. The INVITE client
+ transaction handles the generation of ACKs for the response (see
+ Section 17).
+
+13.2.2.4 2xx Responses
+
+ Multiple 2xx responses may arrive at the UAC for a single INVITE
+ request due to a forking proxy. Each response is distinguished by
+ the tag parameter in the To header field, and each represents a
+ distinct dialog, with a distinct dialog identifier.
+
+ If the dialog identifier in the 2xx response matches the dialog
+ identifier of an existing dialog, the dialog MUST be transitioned to
+ the "confirmed" state, and the route set for the dialog MUST be
+ recomputed based on the 2xx response using the procedures of Section
+ 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be
+ constructed using the procedures of Section 12.1.2.
+
+ Note that the only piece of state that is recomputed is the route
+ set. Other pieces of state such as the highest sequence numbers
+ (remote and local) sent within the dialog are not recomputed. The
+ route set only is recomputed for backwards compatibility. RFC
+ 2543 did not mandate mirroring of the Record-Route header field in
+ a 1xx, only 2xx. However, we cannot update the entire state of
+ the dialog, since mid-dialog requests may have been sent within
+ the early dialog, modifying the sequence numbers, for example.
+
+ The UAC core MUST generate an ACK request for each 2xx received from
+ the transaction layer. The header fields of the ACK are constructed
+ in the same way as for any request sent within a dialog (see Section
+ 12) with the exception of the CSeq and the header fields related to
+ authentication. The sequence number of the CSeq header field MUST be
+ the same as the INVITE being acknowledged, but the CSeq method MUST
+ be ACK. The ACK MUST contain the same credentials as the INVITE. If
+ the 2xx contains an offer (based on the rules above), the ACK MUST
+ carry an answer in its body. If the offer in the 2xx response is not
+ acceptable, the UAC core MUST generate a valid answer in the ACK and
+ then send a BYE immediately.
+
+ Once the ACK has been constructed, the procedures of [4] are used to
+ determine the destination address, port and transport. However, the
+ request is passed to the transport layer directly for transmission,
+ rather than a client transaction. This is because the UAC core
+ handles retransmissions of the ACK, not the transaction layer. The
+ ACK MUST be passed to the client transport every time a
+ retransmission of the 2xx final response that triggered the ACK
+ arrives.
+
+
+
+Rosenberg, et. al. Standards Track [Page 82]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The UAC core considers the INVITE transaction completed 64*T1 seconds
+ after the reception of the first 2xx response. At this point all the
+ early dialogs that have not transitioned to established dialogs are
+ terminated. Once the INVITE transaction is considered completed by
+ the UAC core, no more new 2xx responses are expected to arrive.
+
+ If, after acknowledging any 2xx response to an INVITE, the UAC does
+ not want to continue with that dialog, then the UAC MUST terminate
+ the dialog by sending a BYE request as described in Section 15.
+
+13.3 UAS Processing
+
+13.3.1 Processing of the INVITE
+
+ The UAS core will receive INVITE requests from the transaction layer.
+ It first performs the request processing procedures of Section 8.2,
+ which are applied for both requests inside and outside of a dialog.
+
+ Assuming these processing states are completed without generating a
+ response, the UAS core performs the additional processing steps:
+
+ 1. If the request is an INVITE that contains an Expires header
+ field, the UAS core sets a timer for the number of seconds
+ indicated in the header field value. When the timer fires, the
+ invitation is considered to be expired. If the invitation
+ expires before the UAS has generated a final response, a 487
+ (Request Terminated) response SHOULD be generated.
+
+ 2. If the request is a mid-dialog request, the method-independent
+ processing described in Section 12.2.2 is first applied. It
+ might also modify the session; Section 14 provides details.
+
+ 3. If the request has a tag in the To header field but the dialog
+ identifier does not match any of the existing dialogs, the UAS
+ may have crashed and restarted, or may have received a request
+ for a different (possibly failed) UAS. Section 12.2.2 provides
+ guidelines to achieve a robust behavior under such a situation.
+
+ Processing from here forward assumes that the INVITE is outside of a
+ dialog, and is thus for the purposes of establishing a new session.
+
+ The INVITE may contain a session description, in which case the UAS
+ is being presented with an offer for that session. It is possible
+ that the user is already a participant in that session, even though
+ the INVITE is outside of a dialog. This can happen when a user is
+ invited to the same multicast conference by multiple other
+ participants. If desired, the UAS MAY use identifiers within the
+ session description to detect this duplication. For example, SDP
+
+
+
+Rosenberg, et. al. Standards Track [Page 83]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ contains a session id and version number in the origin (o) field. If
+ the user is already a member of the session, and the session
+ parameters contained in the session description have not changed, the
+ UAS MAY silently accept the INVITE (that is, send a 2xx response
+ without prompting the user).
+
+ If the INVITE does not contain a session description, the UAS is
+ being asked to participate in a session, and the UAC has asked that
+ the UAS provide the offer of the session. It MUST provide the offer
+ in its first non-failure reliable message back to the UAC. In this
+ specification, that is a 2xx response to the INVITE.
+
+ The UAS can indicate progress, accept, redirect, or reject the
+ invitation. In all of these cases, it formulates a response using
+ the procedures described in Section 8.2.6.
+
+13.3.1.1 Progress
+
+ If the UAS is not able to answer the invitation immediately, it can
+ choose to indicate some kind of progress to the UAC (for example, an
+ indication that a phone is ringing). This is accomplished with a
+ provisional response between 101 and 199. These provisional
+ responses establish early dialogs and therefore follow the procedures
+ of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY
+ send as many provisional responses as it likes. Each of these MUST
+ indicate the same dialog ID. However, these will not be delivered
+ reliably.
+
+ If the UAS desires an extended period of time to answer the INVITE,
+ it will need to ask for an "extension" in order to prevent proxies
+ from canceling the transaction. A proxy has the option of canceling
+ a transaction when there is a gap of 3 minutes between responses in a
+ transaction. To prevent cancellation, the UAS MUST send a non-100
+ provisional response at every minute, to handle the possibility of
+ lost provisional responses.
+
+ An INVITE transaction can go on for extended durations when the
+ user is placed on hold, or when interworking with PSTN systems
+ which allow communications to take place without answering the
+ call. The latter is common in Interactive Voice Response (IVR)
+ systems.
+
+13.3.1.2 The INVITE is Redirected
+
+ If the UAS decides to redirect the call, a 3xx response is sent. A
+ 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved
+ Temporarily) response SHOULD contain a Contact header field
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 84]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ containing one or more URIs of new addresses to be tried. The
+ response is passed to the INVITE server transaction, which will deal
+ with its retransmissions.
+
+13.3.1.3 The INVITE is Rejected
+
+ A common scenario occurs when the callee is currently not willing or
+ able to take additional calls at this end system. A 486 (Busy Here)
+ SHOULD be returned in such a scenario. If the UAS knows that no
+ other end system will be able to accept this call, a 600 (Busy
+ Everywhere) response SHOULD be sent instead. However, it is unlikely
+ that a UAS will be able to know this in general, and thus this
+ response will not usually be used. The response is passed to the
+ INVITE server transaction, which will deal with its retransmissions.
+
+ A UAS rejecting an offer contained in an INVITE SHOULD return a 488
+ (Not Acceptable Here) response. Such a response SHOULD include a
+ Warning header field value explaining why the offer was rejected.
+
+13.3.1.4 The INVITE is Accepted
+
+ The UAS core generates a 2xx response. This response establishes a
+ dialog, and therefore follows the procedures of Section 12.1.1 in
+ addition to those of Section 8.2.6.
+
+ A 2xx response to an INVITE SHOULD contain the Allow header field and
+ the Supported header field, and MAY contain the Accept header field.
+ Including these header fields allows the UAC to determine the
+ features and extensions supported by the UAS for the duration of the
+ call, without probing.
+
+ If the INVITE request contained an offer, and the UAS had not yet
+ sent an answer, the 2xx MUST contain an answer. If the INVITE did
+ not contain an offer, the 2xx MUST contain an offer if the UAS had
+ not yet sent an offer.
+
+ Once the response has been constructed, it is passed to the INVITE
+ server transaction. Note, however, that the INVITE server
+ transaction will be destroyed as soon as it receives this final
+ response and passes it to the transport. Therefore, it is necessary
+ to periodically pass the response directly to the transport until the
+ ACK arrives. The 2xx response is passed to the transport with an
+ interval that starts at T1 seconds and doubles for each
+ retransmission until it reaches T2 seconds (T1 and T2 are defined in
+ Section 17). Response retransmissions cease when an ACK request for
+ the response is received. This is independent of whatever transport
+ protocols are used to send the response.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 85]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Since 2xx is retransmitted end-to-end, there may be hops between
+ UAS and UAC that are UDP. To ensure reliable delivery across
+ these hops, the response is retransmitted periodically even if the
+ transport at the UAS is reliable.
+
+ If the server retransmits the 2xx response for 64*T1 seconds without
+ receiving an ACK, the dialog is confirmed, but the session SHOULD be
+ terminated. This is accomplished with a BYE, as described in Section
+ 15.
+
+14 Modifying an Existing Session
+
+ A successful INVITE request (see Section 13) establishes both a
+ dialog between two user agents and a session using the offer-answer
+ model. Section 12 explains how to modify an existing dialog using a
+ target refresh request (for example, changing the remote target URI
+ of the dialog). This section describes how to modify the actual
+ session. This modification can involve changing addresses or ports,
+ adding a media stream, deleting a media stream, and so on. This is
+ accomplished by sending a new INVITE request within the same dialog
+ that established the session. An INVITE request sent within an
+ existing dialog is known as a re-INVITE.
+
+ Note that a single re-INVITE can modify the dialog and the
+ parameters of the session at the same time.
+
+ Either the caller or callee can modify an existing session.
+
+ The behavior of a UA on detection of media failure is a matter of
+ local policy. However, automated generation of re-INVITE or BYE is
+ NOT RECOMMENDED to avoid flooding the network with traffic when there
+ is congestion. In any case, if these messages are sent
+ automatically, they SHOULD be sent after some randomized interval.
+
+ Note that the paragraph above refers to automatically generated
+ BYEs and re-INVITEs. If the user hangs up upon media failure, the
+ UA would send a BYE request as usual.
+
+14.1 UAC Behavior
+
+ The same offer-answer model that applies to session descriptions in
+ INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC
+ that wants to add a media stream, for example, will create a new
+ offer that contains this media stream, and send that in an INVITE
+ request to its peer. It is important to note that the full
+ description of the session, not just the change, is sent. This
+ supports stateless session processing in various elements, and
+ supports failover and recovery capabilities. Of course, a UAC MAY
+
+
+
+Rosenberg, et. al. Standards Track [Page 86]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ send a re-INVITE with no session description, in which case the first
+ reliable non-failure response to the re-INVITE will contain the offer
+ (in this specification, that is a 2xx response).
+
+ If the session description format has the capability for version
+ numbers, the offerer SHOULD indicate that the version of the session
+ description has changed.
+
+ The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set
+ following the same rules as for regular requests within an existing
+ dialog, described in Section 12.
+
+ A UAC MAY choose not to add an Alert-Info header field or a body with
+ Content-Disposition "alert" to re-INVITEs because UASs do not
+ typically alert the user upon reception of a re-INVITE.
+
+ Unlike an INVITE, which can fork, a re-INVITE will never fork, and
+ therefore, only ever generate a single final response. The reason a
+ re-INVITE will never fork is that the Request-URI identifies the
+ target as the UA instance it established the dialog with, rather than
+ identifying an address-of-record for the user.
+
+ Note that a UAC MUST NOT initiate a new INVITE transaction within a
+ dialog while another INVITE transaction is in progress in either
+ direction.
+
+ 1. If there is an ongoing INVITE client transaction, the TU MUST
+ wait until the transaction reaches the completed or terminated
+ state before initiating the new INVITE.
+
+ 2. If there is an ongoing INVITE server transaction, the TU MUST
+ wait until the transaction reaches the confirmed or terminated
+ state before initiating the new INVITE.
+
+ However, a UA MAY initiate a regular transaction while an INVITE
+ transaction is in progress. A UA MAY also initiate an INVITE
+ transaction while a regular transaction is in progress.
+
+ If a UA receives a non-2xx final response to a re-INVITE, the session
+ parameters MUST remain unchanged, as if no re-INVITE had been issued.
+ Note that, as stated in Section 12.2.1.2, if the non-2xx final
+ response is a 481 (Call/Transaction Does Not Exist), or a 408
+ (Request Timeout), or no response at all is received for the re-
+ INVITE (that is, a timeout is returned by the INVITE client
+ transaction), the UAC will terminate the dialog.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 87]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
+ timer with a value T chosen as follows:
+
+ 1. If the UAC is the owner of the Call-ID of the dialog ID
+ (meaning it generated the value), T has a randomly chosen value
+ between 2.1 and 4 seconds in units of 10 ms.
+
+ 2. If the UAC is not the owner of the Call-ID of the dialog ID, T
+ has a randomly chosen value of between 0 and 2 seconds in units
+ of 10 ms.
+
+ When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
+ if it still desires for that session modification to take place. For
+ example, if the call was already hung up with a BYE, the re-INVITE
+ would not take place.
+
+ The rules for transmitting a re-INVITE and for generating an ACK for
+ a 2xx response to re-INVITE are the same as for the initial INVITE
+ (Section 13.2.1).
+
+14.2 UAS Behavior
+
+ Section 13.3.1 describes the procedure for distinguishing incoming
+ re-INVITEs from incoming initial INVITEs and handling a re-INVITE for
+ an existing dialog.
+
+ A UAS that receives a second INVITE before it sends the final
+ response to a first INVITE with a lower CSeq sequence number on the
+ same dialog MUST return a 500 (Server Internal Error) response to the
+ second INVITE and MUST include a Retry-After header field with a
+ randomly chosen value of between 0 and 10 seconds.
+
+ A UAS that receives an INVITE on a dialog while an INVITE it had sent
+ on that dialog is in progress MUST return a 491 (Request Pending)
+ response to the received INVITE.
+
+ If a UA receives a re-INVITE for an existing dialog, it MUST check
+ any version identifiers in the session description or, if there are
+ no version identifiers, the content of the session description to see
+ if it has changed. If the session description has changed, the UAS
+ MUST adjust the session parameters accordingly, possibly after asking
+ the user for confirmation.
+
+ Versioning of the session description can be used to accommodate
+ the capabilities of new arrivals to a conference, add or delete
+ media, or change from a unicast to a multicast conference.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 88]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ If the new session description is not acceptable, the UAS can reject
+ it by returning a 488 (Not Acceptable Here) response for the re-
+ INVITE. This response SHOULD include a Warning header field.
+
+ If a UAS generates a 2xx response and never receives an ACK, it
+ SHOULD generate a BYE to terminate the dialog.
+
+ A UAS MAY choose not to generate 180 (Ringing) responses for a re-
+ INVITE because UACs do not typically render this information to the
+ user. For the same reason, UASs MAY choose not to use an Alert-Info
+ header field or a body with Content-Disposition "alert" in responses
+ to a re-INVITE.
+
+ A UAS providing an offer in a 2xx (because the INVITE did not contain
+ an offer) SHOULD construct the offer as if the UAS were making a
+ brand new call, subject to the constraints of sending an offer that
+ updates an existing session, as described in [13] in the case of SDP.
+ Specifically, this means that it SHOULD include as many media formats
+ and media types that the UA is willing to support. The UAS MUST
+ ensure that the session description overlaps with its previous
+ session description in media formats, transports, or other parameters
+ that require support from the peer. This is to avoid the need for
+ the peer to reject the session description. If, however, it is
+ unacceptable to the UAC, the UAC SHOULD generate an answer with a
+ valid session description, and then send a BYE to terminate the
+ session.
+
+15 Terminating a Session
+
+ This section describes the procedures for terminating a session
+ established by SIP. The state of the session and the state of the
+ dialog are very closely related. When a session is initiated with an
+ INVITE, each 1xx or 2xx response from a distinct UAS creates a
+ dialog, and if that response completes the offer/answer exchange, it
+ also creates a session. As a result, each session is "associated"
+ with a single dialog - the one which resulted in its creation. If an
+ initial INVITE generates a non-2xx final response, that terminates
+ all sessions (if any) and all dialogs (if any) that were created
+ through responses to the request. By virtue of completing the
+ transaction, a non-2xx final response also prevents further sessions
+ from being created as a result of the INVITE. The BYE request is
+ used to terminate a specific session or attempted session. In this
+ case, the specific session is the one with the peer UA on the other
+ side of the dialog. When a BYE is received on a dialog, any session
+ associated with that dialog SHOULD terminate. A UA MUST NOT send a
+ BYE outside of a dialog. The caller's UA MAY send a BYE for either
+ confirmed or early dialogs, and the callee's UA MAY send a BYE on
+ confirmed dialogs, but MUST NOT send a BYE on early dialogs.
+
+
+
+Rosenberg, et. al. Standards Track [Page 89]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ However, the callee's UA MUST NOT send a BYE on a confirmed dialog
+ until it has received an ACK for its 2xx response or until the server
+ transaction times out. If no SIP extensions have defined other
+ application layer states associated with the dialog, the BYE also
+ terminates the dialog.
+
+ The impact of a non-2xx final response to INVITE on dialogs and
+ sessions makes the use of CANCEL attractive. The CANCEL attempts to
+ force a non-2xx response to the INVITE (in particular, a 487).
+ Therefore, if a UAC wishes to give up on its call attempt entirely,
+ it can send a CANCEL. If the INVITE results in 2xx final response(s)
+ to the INVITE, this means that a UAS accepted the invitation while
+ the CANCEL was in progress. The UAC MAY continue with the sessions
+ established by any 2xx responses, or MAY terminate them with BYE.
+
+ The notion of "hanging up" is not well defined within SIP. It is
+ specific to a particular, albeit common, user interface.
+ Typically, when the user hangs up, it indicates a desire to
+ terminate the attempt to establish a session, and to terminate any
+ sessions already created. For the caller's UA, this would imply a
+ CANCEL request if the initial INVITE has not generated a final
+ response, and a BYE to all confirmed dialogs after a final
+ response. For the callee's UA, it would typically imply a BYE;
+ presumably, when the user picked up the phone, a 2xx was
+ generated, and so hanging up would result in a BYE after the ACK
+ is received. This does not mean a user cannot hang up before
+ receipt of the ACK, it just means that the software in his phone
+ needs to maintain state for a short while in order to clean up
+ properly. If the particular UI allows for the user to reject a
+ call before its answered, a 403 (Forbidden) is a good way to
+ express that. As per the rules above, a BYE can't be sent.
+
+15.1 Terminating a Session with a BYE Request
+
+15.1.1 UAC Behavior
+
+ A BYE request is constructed as would any other request within a
+ dialog, as described in Section 12.
+
+ Once the BYE is constructed, the UAC core creates a new non-INVITE
+ client transaction, and passes it the BYE request. The UAC MUST
+ consider the session terminated (and therefore stop sending or
+ listening for media) as soon as the BYE request is passed to the
+ client transaction. If the response for the BYE is a 481
+ (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 90]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ response at all is received for the BYE (that is, a timeout is
+ returned by the client transaction), the UAC MUST consider the
+ session and the dialog terminated.
+
+15.1.2 UAS Behavior
+
+ A UAS first processes the BYE request according to the general UAS
+ processing described in Section 8.2. A UAS core receiving a BYE
+ request checks if it matches an existing dialog. If the BYE does not
+ match an existing dialog, the UAS core SHOULD generate a 481
+ (Call/Transaction Does Not Exist) response and pass that to the
+ server transaction.
+
+ This rule means that a BYE sent without tags by a UAC will be
+ rejected. This is a change from RFC 2543, which allowed BYE
+ without tags.
+
+ A UAS core receiving a BYE request for an existing dialog MUST follow
+ the procedures of Section 12.2.2 to process the request. Once done,
+ the UAS SHOULD terminate the session (and therefore stop sending and
+ listening for media). The only case where it can elect not to are
+ multicast sessions, where participation is possible even if the other
+ participant in the dialog has terminated its involvement in the
+ session. Whether or not it ends its participation on the session,
+ the UAS core MUST generate a 2xx response to the BYE, and MUST pass
+ that to the server transaction for transmission.
+
+ The UAS MUST still respond to any pending requests received for that
+ dialog. It is RECOMMENDED that a 487 (Request Terminated) response
+ be generated to those pending requests.
+
+16 Proxy Behavior
+
+16.1 Overview
+
+ SIP proxies are elements that route SIP requests to user agent
+ servers and SIP responses to user agent clients. A request may
+ traverse several proxies on its way to a UAS. Each will make routing
+ decisions, modifying the request before forwarding it to the next
+ element. Responses will route through the same set of proxies
+ traversed by the request in the reverse order.
+
+ Being a proxy is a logical role for a SIP element. When a request
+ arrives, an element that can play the role of a proxy first decides
+ if it needs to respond to the request on its own. For instance, the
+ request may be malformed or the element may need credentials from the
+ client before acting as a proxy. The element MAY respond with any
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 91]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ appropriate error code. When responding directly to a request, the
+ element is playing the role of a UAS and MUST behave as described in
+ Section 8.2.
+
+ A proxy can operate in either a stateful or stateless mode for each
+ new request. When stateless, a proxy acts as a simple forwarding
+ element. It forwards each request downstream to a single element
+ determined by making a targeting and routing decision based on the
+ request. It simply forwards every response it receives upstream. A
+ stateless proxy discards information about a message once the message
+ has been forwarded. A stateful proxy remembers information
+ (specifically, transaction state) about each incoming request and any
+ requests it sends as a result of processing the incoming request. It
+ uses this information to affect the processing of future messages
+ associated with that request. A stateful proxy MAY choose to "fork"
+ a request, routing it to multiple destinations. Any request that is
+ forwarded to more than one location MUST be handled statefully.
+
+ In some circumstances, a proxy MAY forward requests using stateful
+ transports (such as TCP) without being transaction-stateful. For
+ instance, a proxy MAY forward a request from one TCP connection to
+ another transaction statelessly as long as it places enough
+ information in the message to be able to forward the response down
+ the same connection the request arrived on. Requests forwarded
+ between different types of transports where the proxy's TU must take
+ an active role in ensuring reliable delivery on one of the transports
+ MUST be forwarded transaction statefully.
+
+ A stateful proxy MAY transition to stateless operation at any time
+ during the processing of a request, so long as it did not do anything
+ that would otherwise prevent it from being stateless initially
+ (forking, for example, or generation of a 100 response). When
+ performing such a transition, all state is simply discarded. The
+ proxy SHOULD NOT initiate a CANCEL request.
+
+ Much of the processing involved when acting statelessly or statefully
+ for a request is identical. The next several subsections are written
+ from the point of view of a stateful proxy. The last section calls
+ out those places where a stateless proxy behaves differently.
+
+16.2 Stateful Proxy
+
+ When stateful, a proxy is purely a SIP transaction processing engine.
+ Its behavior is modeled here in terms of the server and client
+ transactions defined in Section 17. A stateful proxy has a server
+ transaction associated with one or more client transactions by a
+ higher layer proxy processing component (see figure 3), known as a
+ proxy core. An incoming request is processed by a server
+
+
+
+Rosenberg, et. al. Standards Track [Page 92]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ transaction. Requests from the server transaction are passed to a
+ proxy core. The proxy core determines where to route the request,
+ choosing one or more next-hop locations. An outgoing request for
+ each next-hop location is processed by its own associated client
+ transaction. The proxy core collects the responses from the client
+ transactions and uses them to send responses to the server
+ transaction.
+
+ A stateful proxy creates a new server transaction for each new
+ request received. Any retransmissions of the request will then be
+ handled by that server transaction per Section 17. The proxy core
+ MUST behave as a UAS with respect to sending an immediate provisional
+ on that server transaction (such as 100 Trying) as described in
+ Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100
+ (Trying) responses to non-INVITE requests.
+
+ This is a model of proxy behavior, not of software. An
+ implementation is free to take any approach that replicates the
+ external behavior this model defines.
+
+ For all new requests, including any with unknown methods, an element
+ intending to proxy the request MUST:
+
+ 1. Validate the request (Section 16.3)
+
+ 2. Preprocess routing information (Section 16.4)
+
+ 3. Determine target(s) for the request (Section 16.5)
+
+ +--------------------+
+ | | +---+
+ | | | C |
+ | | | T |
+ | | +---+
+ +---+ | Proxy | +---+ CT = Client Transaction
+ | S | | "Higher" Layer | | C |
+ | T | | | | T | ST = Server Transaction
+ +---+ | | +---+
+ | | +---+
+ | | | C |
+ | | | T |
+ | | +---+
+ +--------------------+
+
+ Figure 3: Stateful Proxy Model
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 93]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 4. Forward the request to each target (Section 16.6)
+
+ 5. Process all responses (Section 16.7)
+
+16.3 Request Validation
+
+ Before an element can proxy a request, it MUST verify the message's
+ validity. A valid message must pass the following checks:
+
+ 1. Reasonable Syntax
+
+ 2. URI scheme
+
+ 3. Max-Forwards
+
+ 4. (Optional) Loop Detection
+
+ 5. Proxy-Require
+
+ 6. Proxy-Authorization
+
+ If any of these checks fail, the element MUST behave as a user agent
+ server (see Section 8.2) and respond with an error code.
+
+ Notice that a proxy is not required to detect merged requests and
+ MUST NOT treat merged requests as an error condition. The endpoints
+ receiving the requests will resolve the merge as described in Section
+ 8.2.2.2.
+
+ 1. Reasonable syntax check
+
+ The request MUST be well-formed enough to be handled with a server
+ transaction. Any components involved in the remainder of these
+ Request Validation steps or the Request Forwarding section MUST be
+ well-formed. Any other components, well-formed or not, SHOULD be
+ ignored and remain unchanged when the message is forwarded. For
+ instance, an element would not reject a request because of a
+ malformed Date header field. Likewise, a proxy would not remove a
+ malformed Date header field before forwarding a request.
+
+ This protocol is designed to be extended. Future extensions may
+ define new methods and header fields at any time. An element MUST
+ NOT refuse to proxy a request because it contains a method or
+ header field it does not know about.
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 94]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 2. URI scheme check
+
+ If the Request-URI has a URI whose scheme is not understood by the
+ proxy, the proxy SHOULD reject the request with a 416 (Unsupported
+ URI Scheme) response.
+
+ 3. Max-Forwards check
+
+ The Max-Forwards header field (Section 20.22) is used to limit the
+ number of elements a SIP request can traverse.
+
+ If the request does not contain a Max-Forwards header field, this
+ check is passed.
+
+ If the request contains a Max-Forwards header field with a field
+ value greater than zero, the check is passed.
+
+ If the request contains a Max-Forwards header field with a field
+ value of zero (0), the element MUST NOT forward the request. If
+ the request was for OPTIONS, the element MAY act as the final
+ recipient and respond per Section 11. Otherwise, the element MUST
+ return a 483 (Too many hops) response.
+
+ 4. Optional Loop Detection check
+
+ An element MAY check for forwarding loops before forwarding a
+ request. If the request contains a Via header field with a sent-
+ by value that equals a value placed into previous requests by the
+ proxy, the request has been forwarded by this element before. The
+ request has either looped or is legitimately spiraling through the
+ element. To determine if the request has looped, the element MAY
+ perform the branch parameter calculation described in Step 8 of
+ Section 16.6 on this message and compare it to the parameter
+ received in that Via header field. If the parameters match, the
+ request has looped. If they differ, the request is spiraling, and
+ processing continues. If a loop is detected, the element MAY
+ return a 482 (Loop Detected) response.
+
+ 5. Proxy-Require check
+
+ Future extensions to this protocol may introduce features that
+ require special handling by proxies. Endpoints will include a
+ Proxy-Require header field in requests that use these features,
+ telling the proxy not to process the request unless the feature is
+ understood.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 95]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ If the request contains a Proxy-Require header field (Section
+ 20.29) with one or more option-tags this element does not
+ understand, the element MUST return a 420 (Bad Extension)
+ response. The response MUST include an Unsupported (Section
+ 20.40) header field listing those option-tags the element did not
+ understand.
+
+ 6. Proxy-Authorization check
+
+ If an element requires credentials before forwarding a request,
+ the request MUST be inspected as described in Section 22.3. That
+ section also defines what the element must do if the inspection
+ fails.
+
+16.4 Route Information Preprocessing
+
+ The proxy MUST inspect the Request-URI of the request. If the
+ Request-URI of the request contains a value this proxy previously
+ placed into a Record-Route header field (see Section 16.6 item 4),
+ the proxy MUST replace the Request-URI in the request with the last
+ value from the Route header field, and remove that value from the
+ Route header field. The proxy MUST then proceed as if it received
+ this modified request.
+
+ This will only happen when the element sending the request to the
+ proxy (which may have been an endpoint) is a strict router. This
+ rewrite on receive is necessary to enable backwards compatibility
+ with those elements. It also allows elements following this
+ specification to preserve the Request-URI through strict-routing
+ proxies (see Section 12.2.1.1).
+
+ This requirement does not obligate a proxy to keep state in order
+ to detect URIs it previously placed in Record-Route header fields.
+ Instead, a proxy need only place enough information in those URIs
+ to recognize them as values it provided when they later appear.
+
+ If the Request-URI contains a maddr parameter, the proxy MUST check
+ to see if its value is in the set of addresses or domains the proxy
+ is configured to be responsible for. If the Request-URI has a maddr
+ parameter with a value the proxy is responsible for, and the request
+ was received using the port and transport indicated (explicitly or by
+ default) in the Request-URI, the proxy MUST strip the maddr and any
+ non-default port or transport parameter and continue processing as if
+ those values had not been present in the request.
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 96]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ A request may arrive with a maddr matching the proxy, but on a
+ port or transport different from that indicated in the URI. Such
+ a request needs to be forwarded to the proxy using the indicated
+ port and transport.
+
+ If the first value in the Route header field indicates this proxy,
+ the proxy MUST remove that value from the request.
+
+16.5 Determining Request Targets
+
+ Next, the proxy calculates the target(s) of the request. The set of
+ targets will either be predetermined by the contents of the request
+ or will be obtained from an abstract location service. Each target
+ in the set is represented as a URI.
+
+ If the Request-URI of the request contains an maddr parameter, the
+ Request-URI MUST be placed into the target set as the only target
+ URI, and the proxy MUST proceed to Section 16.6.
+
+ If the domain of the Request-URI indicates a domain this element is
+ not responsible for, the Request-URI MUST be placed into the target
+ set as the only target, and the element MUST proceed to the task of
+ Request Forwarding (Section 16.6).
+
+ There are many circumstances in which a proxy might receive a
+ request for a domain it is not responsible for. A firewall proxy
+ handling outgoing calls (the way HTTP proxies handle outgoing
+ requests) is an example of where this is likely to occur.
+
+ If the target set for the request has not been predetermined as
+ described above, this implies that the element is responsible for the
+ domain in the Request-URI, and the element MAY use whatever mechanism
+ it desires to determine where to send the request. Any of these
+ mechanisms can be modeled as accessing an abstract Location Service.
+ This may consist of obtaining information from a location service
+ created by a SIP Registrar, reading a database, consulting a presence
+ server, utilizing other protocols, or simply performing an
+ algorithmic substitution on the Request-URI. When accessing the
+ location service constructed by a registrar, the Request-URI MUST
+ first be canonicalized as described in Section 10.3 before being used
+ as an index. The output of these mechanisms is used to construct the
+ target set.
+
+ If the Request-URI does not provide sufficient information for the
+ proxy to determine the target set, it SHOULD return a 485 (Ambiguous)
+ response. This response SHOULD contain a Contact header field
+ containing URIs of new addresses to be tried. For example, an INVITE
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 97]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ to sip:John.Smith@company.com may be ambiguous at a proxy whose
+ location service has multiple John Smiths listed. See Section
+ 21.4.23 for details.
+
+ Any information in or about the request or the current environment of
+ the element MAY be used in the construction of the target set. For
+ instance, different sets may be constructed depending on contents or
+ the presence of header fields and bodies, the time of day of the
+ request's arrival, the interface on which the request arrived,
+ failure of previous requests, or even the element's current level of
+ utilization.
+
+ As potential targets are located through these services, their URIs
+ are added to the target set. Targets can only be placed in the
+ target set once. If a target URI is already present in the set
+ (based on the definition of equality for the URI type), it MUST NOT
+ be added again.
+
+ A proxy MUST NOT add additional targets to the target set if the
+ Request-URI of the original request does not indicate a resource this
+ proxy is responsible for.
+
+ A proxy can only change the Request-URI of a request during
+ forwarding if it is responsible for that URI. If the proxy is not
+ responsible for that URI, it will not recurse on 3xx or 416
+ responses as described below.
+
+ If the Request-URI of the original request indicates a resource this
+ proxy is responsible for, the proxy MAY continue to add targets to
+ the set after beginning Request Forwarding. It MAY use any
+ information obtained during that processing to determine new targets.
+ For instance, a proxy may choose to incorporate contacts obtained in
+ a redirect response (3xx) into the target set. If a proxy uses a
+ dynamic source of information while building the target set (for
+ instance, if it consults a SIP Registrar), it SHOULD monitor that
+ source for the duration of processing the request. New locations
+ SHOULD be added to the target set as they become available. As
+ above, any given URI MUST NOT be added to the set more than once.
+
+ Allowing a URI to be added to the set only once reduces
+ unnecessary network traffic, and in the case of incorporating
+ contacts from redirect requests prevents infinite recursion.
+
+ For example, a trivial location service is a "no-op", where the
+ target URI is equal to the incoming request URI. The request is sent
+ to a specific next hop proxy for further processing. During request
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 98]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ forwarding of Section 16.6, Item 6, the identity of that next hop,
+ expressed as a SIP or SIPS URI, is inserted as the top-most Route
+ header field value into the request.
+
+ If the Request-URI indicates a resource at this proxy that does not
+ exist, the proxy MUST return a 404 (Not Found) response.
+
+ If the target set remains empty after applying all of the above, the
+ proxy MUST return an error response, which SHOULD be the 480
+ (Temporarily Unavailable) response.
+
+16.6 Request Forwarding
+
+ As soon as the target set is non-empty, a proxy MAY begin forwarding
+ the request. A stateful proxy MAY process the set in any order. It
+ MAY process multiple targets serially, allowing each client
+ transaction to complete before starting the next. It MAY start
+ client transactions with every target in parallel. It also MAY
+ arbitrarily divide the set into groups, processing the groups
+ serially and processing the targets in each group in parallel.
+
+ A common ordering mechanism is to use the qvalue parameter of targets
+ obtained from Contact header fields (see Section 20.10). Targets are
+ processed from highest qvalue to lowest. Targets with equal qvalues
+ may be processed in parallel.
+
+ A stateful proxy must have a mechanism to maintain the target set as
+ responses are received and associate the responses to each forwarded
+ request with the original request. For the purposes of this model,
+ this mechanism is a "response context" created by the proxy layer
+ before forwarding the first request.
+
+ For each target, the proxy forwards the request following these
+ steps:
+
+ 1. Make a copy of the received request
+
+ 2. Update the Request-URI
+
+ 3. Update the Max-Forwards header field
+
+ 4. Optionally add a Record-route header field value
+
+ 5. Optionally add additional header fields
+
+ 6. Postprocess routing information
+
+ 7. Determine the next-hop address, port, and transport
+
+
+
+Rosenberg, et. al. Standards Track [Page 99]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 8. Add a Via header field value
+
+ 9. Add a Content-Length header field if necessary
+
+ 10. Forward the new request
+
+ 11. Set timer C
+
+ Each of these steps is detailed below:
+
+ 1. Copy request
+
+ The proxy starts with a copy of the received request. The copy
+ MUST initially contain all of the header fields from the
+ received request. Fields not detailed in the processing
+ described below MUST NOT be removed. The copy SHOULD maintain
+ the ordering of the header fields as in the received request.
+ The proxy MUST NOT reorder field values with a common field
+ name (See Section 7.3.1). The proxy MUST NOT add to, modify,
+ or remove the message body.
+
+ An actual implementation need not perform a copy; the primary
+ requirement is that the processing for each next hop begin with
+ the same request.
+
+ 2. Request-URI
+
+ The Request-URI in the copy's start line MUST be replaced with
+ the URI for this target. If the URI contains any parameters
+ not allowed in a Request-URI, they MUST be removed.
+
+ This is the essence of a proxy's role. This is the mechanism
+ through which a proxy routes a request toward its destination.
+
+ In some circumstances, the received Request-URI is placed into
+ the target set without being modified. For that target, the
+ replacement above is effectively a no-op.
+
+ 3. Max-Forwards
+
+ If the copy contains a Max-Forwards header field, the proxy
+ MUST decrement its value by one (1).
+
+ If the copy does not contain a Max-Forwards header field, the
+ proxy MUST add one with a field value, which SHOULD be 70.
+
+ Some existing UAs will not provide a Max-Forwards header field
+ in a request.
+
+
+
+Rosenberg, et. al. Standards Track [Page 100]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 4. Record-Route
+
+ If this proxy wishes to remain on the path of future requests
+ in a dialog created by this request (assuming the request
+ creates a dialog), it MUST insert a Record-Route header field
+ value into the copy before any existing Record-Route header
+ field values, even if a Route header field is already present.
+
+ Requests establishing a dialog may contain a preloaded Route
+ header field.
+
+ If this request is already part of a dialog, the proxy SHOULD
+ insert a Record-Route header field value if it wishes to remain
+ on the path of future requests in the dialog. In normal
+ endpoint operation as described in Section 12, these Record-
+ Route header field values will not have any effect on the route
+ sets used by the endpoints.
+
+ The proxy will remain on the path if it chooses to not insert a
+ Record-Route header field value into requests that are already
+ part of a dialog. However, it would be removed from the path
+ when an endpoint that has failed reconstitutes the dialog.
+
+ A proxy MAY insert a Record-Route header field value into any
+ request. If the request does not initiate a dialog, the
+ endpoints will ignore the value. See Section 12 for details on
+ how endpoints use the Record-Route header field values to
+ construct Route header fields.
+
+ Each proxy in the path of a request chooses whether to add a
+ Record-Route header field value independently - the presence of
+ a Record-Route header field in a request does not obligate this
+ proxy to add a value.
+
+ The URI placed in the Record-Route header field value MUST be a
+ SIP or SIPS URI. This URI MUST contain an lr parameter (see
+ Section 19.1.1). This URI MAY be different for each
+ destination the request is forwarded to. The URI SHOULD NOT
+ contain the transport parameter unless the proxy has knowledge
+ (such as in a private network) that the next downstream element
+ that will be in the path of subsequent requests supports that
+ transport.
+
+ The URI this proxy provides will be used by some other element
+ to make a routing decision. This proxy, in general, has no way
+ of knowing the capabilities of that element, so it must
+ restrict itself to the mandatory elements of a SIP
+ implementation: SIP URIs and either the TCP or UDP transports.
+
+
+
+Rosenberg, et. al. Standards Track [Page 101]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The URI placed in the Record-Route header field MUST resolve to
+ the element inserting it (or a suitable stand-in) when the
+ server location procedures of [4] are applied to it, so that
+ subsequent requests reach the same SIP element. If the
+ Request-URI contains a SIPS URI, or the topmost Route header
+ field value (after the post processing of bullet 6) contains a
+ SIPS URI, the URI placed into the Record-Route header field
+ MUST be a SIPS URI. Furthermore, if the request was not
+ received over TLS, the proxy MUST insert a Record-Route header
+ field. In a similar fashion, a proxy that receives a request
+ over TLS, but generates a request without a SIPS URI in the
+ Request-URI or topmost Route header field value (after the post
+ processing of bullet 6), MUST insert a Record-Route header
+ field that is not a SIPS URI.
+
+ A proxy at a security perimeter must remain on the perimeter
+ throughout the dialog.
+
+ If the URI placed in the Record-Route header field needs to be
+ rewritten when it passes back through in a response, the URI
+ MUST be distinct enough to locate at that time. (The request
+ may spiral through this proxy, resulting in more than one
+ Record-Route header field value being added). Item 8 of
+ Section 16.7 recommends a mechanism to make the URI
+ sufficiently distinct.
+
+ The proxy MAY include parameters in the Record-Route header
+ field value. These will be echoed in some responses to the
+ request such as the 200 (OK) responses to INVITE. Such
+ parameters may be useful for keeping state in the message
+ rather than the proxy.
+
+ If a proxy needs to be in the path of any type of dialog (such
+ as one straddling a firewall), it SHOULD add a Record-Route
+ header field value to every request with a method it does not
+ understand since that method may have dialog semantics.
+
+ The URI a proxy places into a Record-Route header field is only
+ valid for the lifetime of any dialog created by the transaction
+ in which it occurs. A dialog-stateful proxy, for example, MAY
+ refuse to accept future requests with that value in the
+ Request-URI after the dialog has terminated. Non-dialog-
+ stateful proxies, of course, have no concept of when the dialog
+ has terminated, but they MAY encode enough information in the
+ value to compare it against the dialog identifier of future
+ requests and MAY reject requests not matching that information.
+ Endpoints MUST NOT use a URI obtained from a Record-Route
+ header field outside the dialog in which it was provided. See
+
+
+
+Rosenberg, et. al. Standards Track [Page 102]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Section 12 for more information on an endpoint's use of
+ Record-Route header fields.
+
+ Record-routing may be required by certain services where the
+ proxy needs to observe all messages in a dialog. However, it
+ slows down processing and impairs scalability and thus proxies
+ should only record-route if required for a particular service.
+
+ The Record-Route process is designed to work for any SIP
+ request that initiates a dialog. INVITE is the only such
+ request in this specification, but extensions to the protocol
+ MAY define others.
+
+ 5. Add Additional Header Fields
+
+ The proxy MAY add any other appropriate header fields to the
+ copy at this point.
+
+ 6. Postprocess routing information
+
+ A proxy MAY have a local policy that mandates that a request
+ visit a specific set of proxies before being delivered to the
+ destination. A proxy MUST ensure that all such proxies are
+ loose routers. Generally, this can only be known with
+ certainty if the proxies are within the same administrative
+ domain. This set of proxies is represented by a set of URIs
+ (each of which contains the lr parameter). This set MUST be
+ pushed into the Route header field of the copy ahead of any
+ existing values, if present. If the Route header field is
+ absent, it MUST be added, containing that list of URIs.
+
+ If the proxy has a local policy that mandates that the request
+ visit one specific proxy, an alternative to pushing a Route
+ value into the Route header field is to bypass the forwarding
+ logic of item 10 below, and instead just send the request to
+ the address, port, and transport for that specific proxy. If
+ the request has a Route header field, this alternative MUST NOT
+ be used unless it is known that next hop proxy is a loose
+ router. Otherwise, this approach MAY be used, but the Route
+ insertion mechanism above is preferred for its robustness,
+ flexibility, generality and consistency of operation.
+ Furthermore, if the Request-URI contains a SIPS URI, TLS MUST
+ be used to communicate with that proxy.
+
+ If the copy contains a Route header field, the proxy MUST
+ inspect the URI in its first value. If that URI does not
+ contain an lr parameter, the proxy MUST modify the copy as
+ follows:
+
+
+
+Rosenberg, et. al. Standards Track [Page 103]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ - The proxy MUST place the Request-URI into the Route header
+ field as the last value.
+
+ - The proxy MUST then place the first Route header field value
+ into the Request-URI and remove that value from the Route
+ header field.
+
+ Appending the Request-URI to the Route header field is part of
+ a mechanism used to pass the information in that Request-URI
+ through strict-routing elements. "Popping" the first Route
+ header field value into the Request-URI formats the message the
+ way a strict-routing element expects to receive it (with its
+ own URI in the Request-URI and the next location to visit in
+ the first Route header field value).
+
+ 7. Determine Next-Hop Address, Port, and Transport
+
+ The proxy MAY have a local policy to send the request to a
+ specific IP address, port, and transport, independent of the
+ values of the Route and Request-URI. Such a policy MUST NOT be
+ used if the proxy is not certain that the IP address, port, and
+ transport correspond to a server that is a loose router.
+ However, this mechanism for sending the request through a
+ specific next hop is NOT RECOMMENDED; instead a Route header
+ field should be used for that purpose as described above.
+
+ In the absence of such an overriding mechanism, the proxy
+ applies the procedures listed in [4] as follows to determine
+ where to send the request. If the proxy has reformatted the
+ request to send to a strict-routing element as described in
+ step 6 above, the proxy MUST apply those procedures to the
+ Request-URI of the request. Otherwise, the proxy MUST apply
+ the procedures to the first value in the Route header field, if
+ present, else the Request-URI. The procedures will produce an
+ ordered set of (address, port, transport) tuples.
+ Independently of which URI is being used as input to the
+ procedures of [4], if the Request-URI specifies a SIPS
+ resource, the proxy MUST follow the procedures of [4] as if the
+ input URI were a SIPS URI.
+
+ As described in [4], the proxy MUST attempt to deliver the
+ message to the first tuple in that set, and proceed through the
+ set in order until the delivery attempt succeeds.
+
+ For each tuple attempted, the proxy MUST format the message as
+ appropriate for the tuple and send the request using a new
+ client transaction as detailed in steps 8 through 10.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 104]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Since each attempt uses a new client transaction, it represents
+ a new branch. Thus, the branch parameter provided with the Via
+ header field inserted in step 8 MUST be different for each
+ attempt.
+
+ If the client transaction reports failure to send the request
+ or a timeout from its state machine, the proxy continues to the
+ next address in that ordered set. If the ordered set is
+ exhausted, the request cannot be forwarded to this element in
+ the target set. The proxy does not need to place anything in
+ the response context, but otherwise acts as if this element of
+ the target set returned a 408 (Request Timeout) final response.
+
+ 8. Add a Via header field value
+
+ The proxy MUST insert a Via header field value into the copy
+ before the existing Via header field values. The construction
+ of this value follows the same guidelines of Section 8.1.1.7.
+ This implies that the proxy will compute its own branch
+ parameter, which will be globally unique for that branch, and
+ contain the requisite magic cookie. Note that this implies that
+ the branch parameter will be different for different instances
+ of a spiraled or looped request through a proxy.
+
+ Proxies choosing to detect loops have an additional constraint
+ in the value they use for construction of the branch parameter.
+ A proxy choosing to detect loops SHOULD create a branch
+ parameter separable into two parts by the implementation. The
+ first part MUST satisfy the constraints of Section 8.1.1.7 as
+ described above. The second is used to perform loop detection
+ and distinguish loops from spirals.
+
+ Loop detection is performed by verifying that, when a request
+ returns to a proxy, those fields having an impact on the
+ processing of the request have not changed. The value placed
+ in this part of the branch parameter SHOULD reflect all of
+ those fields (including any Route, Proxy-Require and Proxy-
+ Authorization header fields). This is to ensure that if the
+ request is routed back to the proxy and one of those fields
+ changes, it is treated as a spiral and not a loop (see Section
+ 16.3). A common way to create this value is to compute a
+ cryptographic hash of the To tag, From tag, Call-ID header
+ field, the Request-URI of the request received (before
+ translation), the topmost Via header, and the sequence number
+ from the CSeq header field, in addition to any Proxy-Require
+ and Proxy-Authorization header fields that may be present. The
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 105]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ algorithm used to compute the hash is implementation-dependent,
+ but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a
+ reasonable choice. (Base64 is not permissible for a token.)
+
+ If a proxy wishes to detect loops, the "branch" parameter it
+ supplies MUST depend on all information affecting processing of
+ a request, including the incoming Request-URI and any header
+ fields affecting the request's admission or routing. This is
+ necessary to distinguish looped requests from requests whose
+ routing parameters have changed before returning to this
+ server.
+
+ The request method MUST NOT be included in the calculation of
+ the branch parameter. In particular, CANCEL and ACK requests
+ (for non-2xx responses) MUST have the same branch value as the
+ corresponding request they cancel or acknowledge. The branch
+ parameter is used in correlating those requests at the server
+ handling them (see Sections 17.2.3 and 9.2).
+
+ 9. Add a Content-Length header field if necessary
+
+ If the request will be sent to the next hop using a stream-
+ based transport and the copy contains no Content-Length header
+ field, the proxy MUST insert one with the correct value for the
+ body of the request (see Section 20.14).
+
+ 10. Forward Request
+
+ A stateful proxy MUST create a new client transaction for this
+ request as described in Section 17.1 and instructs the
+ transaction to send the request using the address, port and
+ transport determined in step 7.
+
+ 11. Set timer C
+
+ In order to handle the case where an INVITE request never
+ generates a final response, the TU uses a timer which is called
+ timer C. Timer C MUST be set for each client transaction when
+ an INVITE request is proxied. The timer MUST be larger than 3
+ minutes. Section 16.7 bullet 2 discusses how this timer is
+ updated with provisional responses, and Section 16.8 discusses
+ processing when it fires.
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 106]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+16.7 Response Processing
+
+ When a response is received by an element, it first tries to locate a
+ client transaction (Section 17.1.3) matching the response. If none
+ is found, the element MUST process the response (even if it is an
+ informational response) as a stateless proxy (described below). If a
+ match is found, the response is handed to the client transaction.
+
+ Forwarding responses for which a client transaction (or more
+ generally any knowledge of having sent an associated request) is
+ not found improves robustness. In particular, it ensures that
+ "late" 2xx responses to INVITE requests are forwarded properly.
+
+ As client transactions pass responses to the proxy layer, the
+ following processing MUST take place:
+
+ 1. Find the appropriate response context
+
+ 2. Update timer C for provisional responses
+
+ 3. Remove the topmost Via
+
+ 4. Add the response to the response context
+
+ 5. Check to see if this response should be forwarded immediately
+
+ 6. When necessary, choose the best final response from the
+ response context
+
+ If no final response has been forwarded after every client
+ transaction associated with the response context has been terminated,
+ the proxy must choose and forward the "best" response from those it
+ has seen so far.
+
+ The following processing MUST be performed on each response that is
+ forwarded. It is likely that more than one response to each request
+ will be forwarded: at least each provisional and one final response.
+
+ 7. Aggregate authorization header field values if necessary
+
+ 8. Optionally rewrite Record-Route header field values
+
+ 9. Forward the response
+
+ 10. Generate any necessary CANCEL requests
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 107]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Each of the above steps are detailed below:
+
+ 1. Find Context
+
+ The proxy locates the "response context" it created before
+ forwarding the original request using the key described in
+ Section 16.6. The remaining processing steps take place in
+ this context.
+
+ 2. Update timer C for provisional responses
+
+ For an INVITE transaction, if the response is a provisional
+ response with status codes 101 to 199 inclusive (i.e., anything
+ but 100), the proxy MUST reset timer C for that client
+ transaction. The timer MAY be reset to a different value, but
+ this value MUST be greater than 3 minutes.
+
+ 3. Via
+
+ The proxy removes the topmost Via header field value from the
+ response.
+
+ If no Via header field values remain in the response, the
+ response was meant for this element and MUST NOT be forwarded.
+ The remainder of the processing described in this section is
+ not performed on this message, the UAC processing rules
+ described in Section 8.1.3 are followed instead (transport
+ layer processing has already occurred).
+
+ This will happen, for instance, when the element generates
+ CANCEL requests as described in Section 10.
+
+ 4. Add response to context
+
+ Final responses received are stored in the response context
+ until a final response is generated on the server transaction
+ associated with this context. The response may be a candidate
+ for the best final response to be returned on that server
+ transaction. Information from this response may be needed in
+ forming the best response, even if this response is not chosen.
+
+ If the proxy chooses to recurse on any contacts in a 3xx
+ response by adding them to the target set, it MUST remove them
+ from the response before adding the response to the response
+ context. However, a proxy SHOULD NOT recurse to a non-SIPS URI
+ if the Request-URI of the original request was a SIPS URI. If
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 108]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ the proxy recurses on all of the contacts in a 3xx response,
+ the proxy SHOULD NOT add the resulting contactless response to
+ the response context.
+
+ Removing the contact before adding the response to the response
+ context prevents the next element upstream from retrying a
+ location this proxy has already attempted.
+
+ 3xx responses may contain a mixture of SIP, SIPS, and non-SIP
+ URIs. A proxy may choose to recurse on the SIP and SIPS URIs
+ and place the remainder into the response context to be
+ returned, potentially in the final response.
+
+ If a proxy receives a 416 (Unsupported URI Scheme) response to
+ a request whose Request-URI scheme was not SIP, but the scheme
+ in the original received request was SIP or SIPS (that is, the
+ proxy changed the scheme from SIP or SIPS to something else
+ when it proxied a request), the proxy SHOULD add a new URI to
+ the target set. This URI SHOULD be a SIP URI version of the
+ non-SIP URI that was just tried. In the case of the tel URL,
+ this is accomplished by placing the telephone-subscriber part
+ of the tel URL into the user part of the SIP URI, and setting
+ the hostpart to the domain where the prior request was sent.
+ See Section 19.1.6 for more detail on forming SIP URIs from tel
+ URLs.
+
+ As with a 3xx response, if a proxy "recurses" on the 416 by
+ trying a SIP or SIPS URI instead, the 416 response SHOULD NOT
+ be added to the response context.
+
+ 5. Check response for forwarding
+
+ Until a final response has been sent on the server transaction,
+ the following responses MUST be forwarded immediately:
+
+ - Any provisional response other than 100 (Trying)
+
+ - Any 2xx response
+
+ If a 6xx response is received, it is not immediately forwarded,
+ but the stateful proxy SHOULD cancel all client pending
+ transactions as described in Section 10, and it MUST NOT create
+ any new branches in this context.
+
+ This is a change from RFC 2543, which mandated that the proxy
+ was to forward the 6xx response immediately. For an INVITE
+ transaction, this approach had the problem that a 2xx response
+ could arrive on another branch, in which case the proxy would
+
+
+
+Rosenberg, et. al. Standards Track [Page 109]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ have to forward the 2xx. The result was that the UAC could
+ receive a 6xx response followed by a 2xx response, which should
+ never be allowed to happen. Under the new rules, upon
+ receiving a 6xx, a proxy will issue a CANCEL request, which
+ will generally result in 487 responses from all outstanding
+ client transactions, and then at that point the 6xx is
+ forwarded upstream.
+
+ After a final response has been sent on the server transaction,
+ the following responses MUST be forwarded immediately:
+
+ - Any 2xx response to an INVITE request
+
+ A stateful proxy MUST NOT immediately forward any other
+ responses. In particular, a stateful proxy MUST NOT forward
+ any 100 (Trying) response. Those responses that are candidates
+ for forwarding later as the "best" response have been gathered
+ as described in step "Add Response to Context".
+
+ Any response chosen for immediate forwarding MUST be processed
+ as described in steps "Aggregate Authorization Header Field
+ Values" through "Record-Route".
+
+ This step, combined with the next, ensures that a stateful
+ proxy will forward exactly one final response to a non-INVITE
+ request, and either exactly one non-2xx response or one or more
+ 2xx responses to an INVITE request.
+
+ 6. Choosing the best response
+
+ A stateful proxy MUST send a final response to a response
+ context's server transaction if no final responses have been
+ immediately forwarded by the above rules and all client
+ transactions in this response context have been terminated.
+
+ The stateful proxy MUST choose the "best" final response among
+ those received and stored in the response context.
+
+ If there are no final responses in the context, the proxy MUST
+ send a 408 (Request Timeout) response to the server
+ transaction.
+
+ Otherwise, the proxy MUST forward a response from the responses
+ stored in the response context. It MUST choose from the 6xx
+ class responses if any exist in the context. If no 6xx class
+ responses are present, the proxy SHOULD choose from the lowest
+ response class stored in the response context. The proxy MAY
+ select any response within that chosen class. The proxy SHOULD
+
+
+
+Rosenberg, et. al. Standards Track [Page 110]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ give preference to responses that provide information affecting
+ resubmission of this request, such as 401, 407, 415, 420, and
+ 484 if the 4xx class is chosen.
+
+ A proxy which receives a 503 (Service Unavailable) response
+ SHOULD NOT forward it upstream unless it can determine that any
+ subsequent requests it might proxy will also generate a 503.
+ In other words, forwarding a 503 means that the proxy knows it
+ cannot service any requests, not just the one for the Request-
+ URI in the request which generated the 503. If the only
+ response that was received is a 503, the proxy SHOULD generate
+ a 500 response and forward that upstream.
+
+ The forwarded response MUST be processed as described in steps
+ "Aggregate Authorization Header Field Values" through "Record-
+ Route".
+
+ For example, if a proxy forwarded a request to 4 locations, and
+ received 503, 407, 501, and 404 responses, it may choose to
+ forward the 407 (Proxy Authentication Required) response.
+
+ 1xx and 2xx responses may be involved in the establishment of
+ dialogs. When a request does not contain a To tag, the To tag
+ in the response is used by the UAC to distinguish multiple
+ responses to a dialog creating request. A proxy MUST NOT
+ insert a tag into the To header field of a 1xx or 2xx response
+ if the request did not contain one. A proxy MUST NOT modify
+ the tag in the To header field of a 1xx or 2xx response.
+
+ Since a proxy may not insert a tag into the To header field of
+ a 1xx response to a request that did not contain one, it cannot
+ issue non-100 provisional responses on its own. However, it
+ can branch the request to a UAS sharing the same element as the
+ proxy. This UAS can return its own provisional responses,
+ entering into an early dialog with the initiator of the
+ request. The UAS does not have to be a discreet process from
+ the proxy. It could be a virtual UAS implemented in the same
+ code space as the proxy.
+
+ 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx
+ response, the element is effectively acting as a UAS, issuing
+ its own response, usually based on the responses received from
+ downstream elements. An element SHOULD preserve the To tag
+ when simply forwarding a 3-6xx response to a request that did
+ not contain a To tag.
+
+ A proxy MUST NOT modify the To tag in any forwarded response to
+ a request that contains a To tag.
+
+
+
+Rosenberg, et. al. Standards Track [Page 111]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ While it makes no difference to the upstream elements if the
+ proxy replaced the To tag in a forwarded 3-6xx response,
+ preserving the original tag may assist with debugging.
+
+ When the proxy is aggregating information from several
+ responses, choosing a To tag from among them is arbitrary, and
+ generating a new To tag may make debugging easier. This
+ happens, for instance, when combining 401 (Unauthorized) and
+ 407 (Proxy Authentication Required) challenges, or combining
+ Contact values from unencrypted and unauthenticated 3xx
+ responses.
+
+ 7. Aggregate Authorization Header Field Values
+
+ If the selected response is a 401 (Unauthorized) or 407 (Proxy
+ Authentication Required), the proxy MUST collect any WWW-
+ Authenticate and Proxy-Authenticate header field values from
+ all other 401 (Unauthorized) and 407 (Proxy Authentication
+ Required) responses received so far in this response context
+ and add them to this response without modification before
+ forwarding. The resulting 401 (Unauthorized) or 407 (Proxy
+ Authentication Required) response could have several WWW-
+ Authenticate AND Proxy-Authenticate header field values.
+
+ This is necessary because any or all of the destinations the
+ request was forwarded to may have requested credentials. The
+ client needs to receive all of those challenges and supply
+ credentials for each of them when it retries the request.
+ Motivation for this behavior is provided in Section 26.
+
+ 8. Record-Route
+
+ If the selected response contains a Record-Route header field
+ value originally provided by this proxy, the proxy MAY choose
+ to rewrite the value before forwarding the response. This
+ allows the proxy to provide different URIs for itself to the
+ next upstream and downstream elements. A proxy may choose to
+ use this mechanism for any reason. For instance, it is useful
+ for multi-homed hosts.
+
+ If the proxy received the request over TLS, and sent it out
+ over a non-TLS connection, the proxy MUST rewrite the URI in
+ the Record-Route header field to be a SIPS URI. If the proxy
+ received the request over a non-TLS connection, and sent it out
+ over TLS, the proxy MUST rewrite the URI in the Record-Route
+ header field to be a SIP URI.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 112]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The new URI provided by the proxy MUST satisfy the same
+ constraints on URIs placed in Record-Route header fields in
+ requests (see Step 4 of Section 16.6) with the following
+ modifications:
+
+ The URI SHOULD NOT contain the transport parameter unless the
+ proxy has knowledge that the next upstream (as opposed to
+ downstream) element that will be in the path of subsequent
+ requests supports that transport.
+
+ When a proxy does decide to modify the Record-Route header
+ field in the response, one of the operations it performs is
+ locating the Record-Route value that it had inserted. If the
+ request spiraled, and the proxy inserted a Record-Route value
+ in each iteration of the spiral, locating the correct value in
+ the response (which must be the proper iteration in the reverse
+ direction) is tricky. The rules above recommend that a proxy
+ wishing to rewrite Record-Route header field values insert
+ sufficiently distinct URIs into the Record-Route header field
+ so that the right one may be selected for rewriting. A
+ RECOMMENDED mechanism to achieve this is for the proxy to
+ append a unique identifier for the proxy instance to the user
+ portion of the URI.
+
+ When the response arrives, the proxy modifies the first
+ Record-Route whose identifier matches the proxy instance. The
+ modification results in a URI without this piece of data
+ appended to the user portion of the URI. Upon the next
+ iteration, the same algorithm (find the topmost Record-Route
+ header field value with the parameter) will correctly extract
+ the next Record-Route header field value inserted by that
+ proxy.
+
+ Not every response to a request to which a proxy adds a
+ Record-Route header field value will contain a Record-Route
+ header field. If the response does contain a Record-Route
+ header field, it will contain the value the proxy added.
+
+ 9. Forward response
+
+ After performing the processing described in steps "Aggregate
+ Authorization Header Field Values" through "Record-Route", the
+ proxy MAY perform any feature specific manipulations on the
+ selected response. The proxy MUST NOT add to, modify, or
+ remove the message body. Unless otherwise specified, the proxy
+ MUST NOT remove any header field values other than the Via
+ header field value discussed in Section 16.7 Item 3. In
+ particular, the proxy MUST NOT remove any "received" parameter
+
+
+
+Rosenberg, et. al. Standards Track [Page 113]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ it may have added to the next Via header field value while
+ processing the request associated with this response. The
+ proxy MUST pass the response to the server transaction
+ associated with the response context. This will result in the
+ response being sent to the location now indicated in the
+ topmost Via header field value. If the server transaction is
+ no longer available to handle the transmission, the element
+ MUST forward the response statelessly by sending it to the
+ server transport. The server transaction might indicate
+ failure to send the response or signal a timeout in its state
+ machine. These errors would be logged for diagnostic purposes
+ as appropriate, but the protocol requires no remedial action
+ from the proxy.
+
+ The proxy MUST maintain the response context until all of its
+ associated transactions have been terminated, even after
+ forwarding a final response.
+
+ 10. Generate CANCELs
+
+ If the forwarded response was a final response, the proxy MUST
+ generate a CANCEL request for all pending client transactions
+ associated with this response context. A proxy SHOULD also
+ generate a CANCEL request for all pending client transactions
+ associated with this response context when it receives a 6xx
+ response. A pending client transaction is one that has
+ received a provisional response, but no final response (it is
+ in the proceeding state) and has not had an associated CANCEL
+ generated for it. Generating CANCEL requests is described in
+ Section 9.1.
+
+ The requirement to CANCEL pending client transactions upon
+ forwarding a final response does not guarantee that an endpoint
+ will not receive multiple 200 (OK) responses to an INVITE. 200
+ (OK) responses on more than one branch may be generated before
+ the CANCEL requests can be sent and processed. Further, it is
+ reasonable to expect that a future extension may override this
+ requirement to issue CANCEL requests.
+
+16.8 Processing Timer C
+
+ If timer C should fire, the proxy MUST either reset the timer with
+ any value it chooses, or terminate the client transaction. If the
+ client transaction has received a provisional response, the proxy
+ MUST generate a CANCEL request matching that transaction. If the
+ client transaction has not received a provisional response, the proxy
+ MUST behave as if the transaction received a 408 (Request Timeout)
+ response.
+
+
+
+Rosenberg, et. al. Standards Track [Page 114]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Allowing the proxy to reset the timer allows the proxy to dynamically
+ extend the transaction's lifetime based on current conditions (such
+ as utilization) when the timer fires.
+
+16.9 Handling Transport Errors
+
+ If the transport layer notifies a proxy of an error when it tries to
+ forward a request (see Section 18.4), the proxy MUST behave as if the
+ forwarded request received a 503 (Service Unavailable) response.
+
+ If the proxy is notified of an error when forwarding a response, it
+ drops the response. The proxy SHOULD NOT cancel any outstanding
+ client transactions associated with this response context due to this
+ notification.
+
+ If a proxy cancels its outstanding client transactions, a single
+ malicious or misbehaving client can cause all transactions to fail
+ through its Via header field.
+
+16.10 CANCEL Processing
+
+ A stateful proxy MAY generate a CANCEL to any other request it has
+ generated at any time (subject to receiving a provisional response to
+ that request as described in section 9.1). A proxy MUST cancel any
+ pending client transactions associated with a response context when
+ it receives a matching CANCEL request.
+
+ A stateful proxy MAY generate CANCEL requests for pending INVITE
+ client transactions based on the period specified in the INVITE's
+ Expires header field elapsing. However, this is generally
+ unnecessary since the endpoints involved will take care of signaling
+ the end of the transaction.
+
+ While a CANCEL request is handled in a stateful proxy by its own
+ server transaction, a new response context is not created for it.
+ Instead, the proxy layer searches its existing response contexts for
+ the server transaction handling the request associated with this
+ CANCEL. If a matching response context is found, the element MUST
+ immediately return a 200 (OK) response to the CANCEL request. In
+ this case, the element is acting as a user agent server as defined in
+ Section 8.2. Furthermore, the element MUST generate CANCEL requests
+ for all pending client transactions in the context as described in
+ Section 16.7 step 10.
+
+ If a response context is not found, the element does not have any
+ knowledge of the request to apply the CANCEL to. It MUST statelessly
+ forward the CANCEL request (it may have statelessly forwarded the
+ associated request previously).
+
+
+
+Rosenberg, et. al. Standards Track [Page 115]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+16.11 Stateless Proxy
+
+ When acting statelessly, a proxy is a simple message forwarder. Much
+ of the processing performed when acting statelessly is the same as
+ when behaving statefully. The differences are detailed here.
+
+ A stateless proxy does not have any notion of a transaction, or of
+ the response context used to describe stateful proxy behavior.
+ Instead, the stateless proxy takes messages, both requests and
+ responses, directly from the transport layer (See section 18). As a
+ result, stateless proxies do not retransmit messages on their own.
+ They do, however, forward all retransmissions they receive (they do
+ not have the ability to distinguish a retransmission from the
+ original message). Furthermore, when handling a request statelessly,
+ an element MUST NOT generate its own 100 (Trying) or any other
+ provisional response.
+
+ A stateless proxy MUST validate a request as described in Section
+ 16.3
+
+ A stateless proxy MUST follow the request processing steps described
+ in Sections 16.4 through 16.5 with the following exception:
+
+ o A stateless proxy MUST choose one and only one target from the
+ target set. This choice MUST only rely on fields in the
+ message and time-invariant properties of the server. In
+ particular, a retransmitted request MUST be forwarded to the
+ same destination each time it is processed. Furthermore,
+ CANCEL and non-Routed ACK requests MUST generate the same
+ choice as their associated INVITE.
+
+ A stateless proxy MUST follow the request processing steps described
+ in Section 16.6 with the following exceptions:
+
+ o The requirement for unique branch IDs across space and time
+ applies to stateless proxies as well. However, a stateless
+ proxy cannot simply use a random number generator to compute
+ the first component of the branch ID, as described in Section
+ 16.6 bullet 8. This is because retransmissions of a request
+ need to have the same value, and a stateless proxy cannot tell
+ a retransmission from the original request. Therefore, the
+ component of the branch parameter that makes it unique MUST be
+ the same each time a retransmitted request is forwarded. Thus
+ for a stateless proxy, the branch parameter MUST be computed as
+ a combinatoric function of message parameters which are
+ invariant on retransmission.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 116]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The stateless proxy MAY use any technique it likes to guarantee
+ uniqueness of its branch IDs across transactions. However, the
+ following procedure is RECOMMENDED. The proxy examines the
+ branch ID in the topmost Via header field of the received
+ request. If it begins with the magic cookie, the first
+ component of the branch ID of the outgoing request is computed
+ as a hash of the received branch ID. Otherwise, the first
+ component of the branch ID is computed as a hash of the topmost
+ Via, the tag in the To header field, the tag in the From header
+ field, the Call-ID header field, the CSeq number (but not
+ method), and the Request-URI from the received request. One of
+ these fields will always vary across two different
+ transactions.
+
+ o All other message transformations specified in Section 16.6
+ MUST result in the same transformation of a retransmitted
+ request. In particular, if the proxy inserts a Record-Route
+ value or pushes URIs into the Route header field, it MUST place
+ the same values in retransmissions of the request. As for the
+ Via branch parameter, this implies that the transformations
+ MUST be based on time-invariant configuration or
+ retransmission-invariant properties of the request.
+
+ o A stateless proxy determines where to forward the request as
+ described for stateful proxies in Section 16.6 Item 10. The
+ request is sent directly to the transport layer instead of
+ through a client transaction.
+
+ Since a stateless proxy must forward retransmitted requests to
+ the same destination and add identical branch parameters to
+ each of them, it can only use information from the message
+ itself and time-invariant configuration data for those
+ calculations. If the configuration state is not time-invariant
+ (for example, if a routing table is updated) any requests that
+ could be affected by the change may not be forwarded
+ statelessly during an interval equal to the transaction timeout
+ window before or after the change. The method of processing
+ the affected requests in that interval is an implementation
+ decision. A common solution is to forward them transaction
+ statefully.
+
+ Stateless proxies MUST NOT perform special processing for CANCEL
+ requests. They are processed by the above rules as any other
+ requests. In particular, a stateless proxy applies the same Route
+ header field processing to CANCEL requests that it applies to any
+ other request.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 117]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Response processing as described in Section 16.7 does not apply to a
+ proxy behaving statelessly. When a response arrives at a stateless
+ proxy, the proxy MUST inspect the sent-by value in the first
+ (topmost) Via header field value. If that address matches the proxy,
+ (it equals a value this proxy has inserted into previous requests)
+ the proxy MUST remove that header field value from the response and
+ forward the result to the location indicated in the next Via header
+ field value. The proxy MUST NOT add to, modify, or remove the
+ message body. Unless specified otherwise, the proxy MUST NOT remove
+ any other header field values. If the address does not match the
+ proxy, the message MUST be silently discarded.
+
+16.12 Summary of Proxy Route Processing
+
+ In the absence of local policy to the contrary, the processing a
+ proxy performs on a request containing a Route header field can be
+ summarized in the following steps.
+
+ 1. The proxy will inspect the Request-URI. If it indicates a
+ resource owned by this proxy, the proxy will replace it with
+ the results of running a location service. Otherwise, the
+ proxy will not change the Request-URI.
+
+ 2. The proxy will inspect the URI in the topmost Route header
+ field value. If it indicates this proxy, the proxy removes it
+ from the Route header field (this route node has been
+ reached).
+
+ 3. The proxy will forward the request to the resource indicated
+ by the URI in the topmost Route header field value or in the
+ Request-URI if no Route header field is present. The proxy
+ determines the address, port and transport to use when
+ forwarding the request by applying the procedures in [4] to
+ that URI.
+
+ If no strict-routing elements are encountered on the path of the
+ request, the Request-URI will always indicate the target of the
+ request.
+
+16.12.1 Examples
+
+16.12.1.1 Basic SIP Trapezoid
+
+ This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with
+ both proxies record-routing. Here is the flow.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 118]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ U1 sends:
+
+ INVITE sip:callee@domain.com SIP/2.0
+ Contact: sip:caller@u1.example.com
+
+ to P1. P1 is an outbound proxy. P1 is not responsible for
+ domain.com, so it looks it up in DNS and sends it there. It also
+ adds a Record-Route header field value:
+
+ INVITE sip:callee@domain.com SIP/2.0
+ Contact: sip:caller@u1.example.com
+ Record-Route: <sip:p1.example.com;lr>
+
+ P2 gets this. It is responsible for domain.com so it runs a location
+ service and rewrites the Request-URI. It also adds a Record-Route
+ header field value. There is no Route header field, so it resolves
+ the new Request-URI to determine where to send the request:
+
+ INVITE sip:callee@u2.domain.com SIP/2.0
+ Contact: sip:caller@u1.example.com
+ Record-Route: <sip:p2.domain.com;lr>
+ Record-Route: <sip:p1.example.com;lr>
+
+ The callee at u2.domain.com gets this and responds with a 200 OK:
+
+ SIP/2.0 200 OK
+ Contact: sip:callee@u2.domain.com
+ Record-Route: <sip:p2.domain.com;lr>
+ Record-Route: <sip:p1.example.com;lr>
+
+ The callee at u2 also sets its dialog state's remote target URI to
+ sip:caller@u1.example.com and its route set to:
+
+ (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
+
+ This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its
+ dialog state's remote target URI to sip:callee@u2.domain.com and its
+ route set to:
+
+ (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
+
+ Since all the route set elements contain the lr parameter, U1
+ constructs the following BYE request:
+
+ BYE sip:callee@u2.domain.com SIP/2.0
+ Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 119]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ As any other element (including proxies) would do, it resolves the
+ URI in the topmost Route header field value using DNS to determine
+ where to send the request. This goes to P1. P1 notices that it is
+ not responsible for the resource indicated in the Request-URI so it
+ doesn't change it. It does see that it is the first value in the
+ Route header field, so it removes that value, and forwards the
+ request to P2:
+
+ BYE sip:callee@u2.domain.com SIP/2.0
+ Route: <sip:p2.domain.com;lr>
+
+ P2 also notices it is not responsible for the resource indicated by
+ the Request-URI (it is responsible for domain.com, not
+ u2.domain.com), so it doesn't change it. It does see itself in the
+ first Route header field value, so it removes it and forwards the
+ following to u2.domain.com based on a DNS lookup against the
+ Request-URI:
+
+ BYE sip:callee@u2.domain.com SIP/2.0
+
+16.12.1.2 Traversing a Strict-Routing Proxy
+
+ In this scenario, a dialog is established across four proxies, each
+ of which adds Record-Route header field values. The third proxy
+ implements the strict-routing procedures specified in RFC 2543 and
+ many works in progress.
+
+ U1->P1->P2->P3->P4->U2
+
+ The INVITE arriving at U2 contains:
+
+ INVITE sip:callee@u2.domain.com SIP/2.0
+ Contact: sip:caller@u1.example.com
+ Record-Route: <sip:p4.domain.com;lr>
+ Record-Route: <sip:p3.middle.com>
+ Record-Route: <sip:p2.example.com;lr>
+ Record-Route: <sip:p1.example.com;lr>
+
+ Which U2 responds to with a 200 OK. Later, U2 sends the following
+ BYE request to P4 based on the first Route header field value.
+
+ BYE sip:caller@u1.example.com SIP/2.0
+ Route: <sip:p4.domain.com;lr>
+ Route: <sip:p3.middle.com>
+ Route: <sip:p2.example.com;lr>
+ Route: <sip:p1.example.com;lr>
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 120]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ P4 is not responsible for the resource indicated in the Request-URI
+ so it will leave it alone. It notices that it is the element in the
+ first Route header field value so it removes it. It then prepares to
+ send the request based on the now first Route header field value of
+ sip:p3.middle.com, but it notices that this URI does not contain the
+ lr parameter, so before sending, it reformats the request to be:
+
+ BYE sip:p3.middle.com SIP/2.0
+ Route: <sip:p2.example.com;lr>
+ Route: <sip:p1.example.com;lr>
+ Route: <sip:caller@u1.example.com>
+
+ P3 is a strict router, so it forwards the following to P2:
+
+ BYE sip:p2.example.com;lr SIP/2.0
+ Route: <sip:p1.example.com;lr>
+ Route: <sip:caller@u1.example.com>
+
+ P2 sees the request-URI is a value it placed into a Record-Route
+ header field, so before further processing, it rewrites the request
+ to be:
+
+ BYE sip:caller@u1.example.com SIP/2.0
+ Route: <sip:p1.example.com;lr>
+
+ P2 is not responsible for u1.example.com, so it sends the request to
+ P1 based on the resolution of the Route header field value.
+
+ P1 notices itself in the topmost Route header field value, so it
+ removes it, resulting in:
+
+ BYE sip:caller@u1.example.com SIP/2.0
+
+ Since P1 is not responsible for u1.example.com and there is no Route
+ header field, P1 will forward the request to u1.example.com based on
+ the Request-URI.
+
+16.12.1.3 Rewriting Record-Route Header Field Values
+
+ In this scenario, U1 and U2 are in different private namespaces and
+ they enter a dialog through a proxy P1, which acts as a gateway
+ between the namespaces.
+
+ U1->P1->U2
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 121]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ U1 sends:
+
+ INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
+ Contact: <sip:caller@u1.leftprivatespace.com>
+
+ P1 uses its location service and sends the following to U2:
+
+ INVITE sip:callee@rightprivatespace.com SIP/2.0
+ Contact: <sip:caller@u1.leftprivatespace.com>
+ Record-Route: <sip:gateway.rightprivatespace.com;lr>
+
+ U2 sends this 200 (OK) back to P1:
+
+ SIP/2.0 200 OK
+ Contact: <sip:callee@u2.rightprivatespace.com>
+ Record-Route: <sip:gateway.rightprivatespace.com;lr>
+
+ P1 rewrites its Record-Route header parameter to provide a value that
+ U1 will find useful, and sends the following to U1:
+
+ SIP/2.0 200 OK
+ Contact: <sip:callee@u2.rightprivatespace.com>
+ Record-Route: <sip:gateway.leftprivatespace.com;lr>
+
+ Later, U1 sends the following BYE request to P1:
+
+ BYE sip:callee@u2.rightprivatespace.com SIP/2.0
+ Route: <sip:gateway.leftprivatespace.com;lr>
+
+ which P1 forwards to U2 as:
+
+ BYE sip:callee@u2.rightprivatespace.com SIP/2.0
+
+17 Transactions
+
+ SIP is a transactional protocol: interactions between components take
+ place in a series of independent message exchanges. Specifically, a
+ SIP transaction consists of a single request and any responses to
+ that request, which include zero or more provisional responses and
+ one or more final responses. In the case of a transaction where the
+ request was an INVITE (known as an INVITE transaction), the
+ transaction also includes the ACK only if the final response was not
+ a 2xx response. If the response was a 2xx, the ACK is not considered
+ part of the transaction.
+
+ The reason for this separation is rooted in the importance of
+ delivering all 200 (OK) responses to an INVITE to the UAC. To
+ deliver them all to the UAC, the UAS alone takes responsibility
+
+
+
+Rosenberg, et. al. Standards Track [Page 122]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ for retransmitting them (see Section 13.3.1.4), and the UAC alone
+ takes responsibility for acknowledging them with ACK (see Section
+ 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is
+ effectively considered its own transaction.
+
+ Transactions have a client side and a server side. The client side
+ is known as a client transaction and the server side as a server
+ transaction. The client transaction sends the request, and the
+ server transaction sends the response. The client and server
+ transactions are logical functions that are embedded in any number of
+ elements. Specifically, they exist within user agents and stateful
+ proxy servers. Consider the example in Section 4. In this example,
+ the UAC executes the client transaction, and its outbound proxy
+ executes the server transaction. The outbound proxy also executes a
+ client transaction, which sends the request to a server transaction
+ in the inbound proxy. That proxy also executes a client transaction,
+ which in turn sends the request to a server transaction in the UAS.
+ This is shown in Figure 4.
+
+ +---------+ +---------+ +---------+ +---------+
+ | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ |
+ | |C||------->||S| |C||------->||S| |C||------->||S| |
+ | |l|| ||e| |l|| ||e| |l|| ||e| |
+ | |i|| ||r| |i|| ||r| |i|| ||r| |
+ | |e|| ||v| |e|| ||v| |e|| ||v| |
+ | |n|| ||e| |n|| ||e| |n|| ||e| |
+ | |t|| ||r| |t|| ||r| |t|| ||r| |
+ | | || || | | || || | | || || | |
+ | |T|| ||T| |T|| ||T| |T|| ||T| |
+ | |r|| ||r| |r|| ||r| |r|| ||r| |
+ | |a|| ||a| |a|| ||a| |a|| ||a| |
+ | |n|| ||n| |n|| ||n| |n|| ||n| |
+ | |s||Response||s| |s||Response||s| |s||Response||s| |
+ | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ |
+ +---------+ +---------+ +---------+ +---------+
+ UAC Outbound Inbound UAS
+ Proxy Proxy
+
+ Figure 4: Transaction relationships
+
+ A stateless proxy does not contain a client or server transaction.
+ The transaction exists between the UA or stateful proxy on one side,
+ and the UA or stateful proxy on the other side. As far as SIP
+ transactions are concerned, stateless proxies are effectively
+ transparent. The purpose of the client transaction is to receive a
+ request from the element in which the client is embedded (call this
+ element the "Transaction User" or TU; it can be a UA or a stateful
+ proxy), and reliably deliver the request to a server transaction.
+
+
+
+Rosenberg, et. al. Standards Track [Page 123]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The client transaction is also responsible for receiving responses
+ and delivering them to the TU, filtering out any response
+ retransmissions or disallowed responses (such as a response to ACK).
+ Additionally, in the case of an INVITE request, the client
+ transaction is responsible for generating the ACK request for any
+ final response accepting a 2xx response.
+
+ Similarly, the purpose of the server transaction is to receive
+ requests from the transport layer and deliver them to the TU. The
+ server transaction filters any request retransmissions from the
+ network. The server transaction accepts responses from the TU and
+ delivers them to the transport layer for transmission over the
+ network. In the case of an INVITE transaction, it absorbs the ACK
+ request for any final response excepting a 2xx response.
+
+ The 2xx response and its ACK receive special treatment. This
+ response is retransmitted only by a UAS, and its ACK generated only
+ by the UAC. This end-to-end treatment is needed so that a caller
+ knows the entire set of users that have accepted the call. Because
+ of this special handling, retransmissions of the 2xx response are
+ handled by the UA core, not the transaction layer. Similarly,
+ generation of the ACK for the 2xx is handled by the UA core. Each
+ proxy along the path merely forwards each 2xx response to INVITE and
+ its corresponding ACK.
+
+17.1 Client Transaction
+
+ The client transaction provides its functionality through the
+ maintenance of a state machine.
+
+ The TU communicates with the client transaction through a simple
+ interface. When the TU wishes to initiate a new transaction, it
+ creates a client transaction and passes it the SIP request to send
+ and an IP address, port, and transport to which to send it. The
+ client transaction begins execution of its state machine. Valid
+ responses are passed up to the TU from the client transaction.
+
+ There are two types of client transaction state machines, depending
+ on the method of the request passed by the TU. One handles client
+ transactions for INVITE requests. This type of machine is referred
+ to as an INVITE client transaction. Another type handles client
+ transactions for all requests except INVITE and ACK. This is
+ referred to as a non-INVITE client transaction. There is no client
+ transaction for ACK. If the TU wishes to send an ACK, it passes one
+ directly to the transport layer for transmission.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 124]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The INVITE transaction is different from those of other methods
+ because of its extended duration. Normally, human input is required
+ in order to respond to an INVITE. The long delays expected for
+ sending a response argue for a three-way handshake. On the other
+ hand, requests of other methods are expected to complete rapidly.
+ Because of the non-INVITE transaction's reliance on a two-way
+ handshake, TUs SHOULD respond immediately to non-INVITE requests.
+
+17.1.1 INVITE Client Transaction
+
+17.1.1.1 Overview of INVITE Transaction
+
+ The INVITE transaction consists of a three-way handshake. The client
+ transaction sends an INVITE, the server transaction sends responses,
+ and the client transaction sends an ACK. For unreliable transports
+ (such as UDP), the client transaction retransmits requests at an
+ interval that starts at T1 seconds and doubles after every
+ retransmission. T1 is an estimate of the round-trip time (RTT), and
+ it defaults to 500 ms. Nearly all of the transaction timers
+ described here scale with T1, and changing T1 adjusts their values.
+ The request is not retransmitted over reliable transports. After
+ receiving a 1xx response, any retransmissions cease altogether, and
+ the client waits for further responses. The server transaction can
+ send additional 1xx responses, which are not transmitted reliably by
+ the server transaction. Eventually, the server transaction decides
+ to send a final response. For unreliable transports, that response
+ is retransmitted periodically, and for reliable transports, it is
+ sent once. For each final response that is received at the client
+ transaction, the client transaction sends an ACK, the purpose of
+ which is to quench retransmissions of the response.
+
+17.1.1.2 Formal Description
+
+ The state machine for the INVITE client transaction is shown in
+ Figure 5. The initial state, "calling", MUST be entered when the TU
+ initiates a new client transaction with an INVITE request. The
+ client transaction MUST pass the request to the transport layer for
+ transmission (see Section 18). If an unreliable transport is being
+ used, the client transaction MUST start timer A with a value of T1.
+ If a reliable transport is being used, the client transaction SHOULD
+ NOT start timer A (Timer A controls request retransmissions). For
+ any transport, the client transaction MUST start timer B with a value
+ of 64*T1 seconds (Timer B controls transaction timeouts).
+
+ When timer A fires, the client transaction MUST retransmit the
+ request by passing it to the transport layer, and MUST reset the
+ timer with a value of 2*T1. The formal definition of retransmit
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 125]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ within the context of the transaction layer is to take the message
+ previously sent to the transport layer and pass it to the transport
+ layer once more.
+
+ When timer A fires 2*T1 seconds later, the request MUST be
+ retransmitted again (assuming the client transaction is still in this
+ state). This process MUST continue so that the request is
+ retransmitted with intervals that double after each transmission.
+ These retransmissions SHOULD only be done while the client
+ transaction is in the "calling" state.
+
+ The default value for T1 is 500 ms. T1 is an estimate of the RTT
+ between the client and server transactions. Elements MAY (though it
+ is NOT RECOMMENDED) use smaller values of T1 within closed, private
+ networks that do not permit general Internet connection. T1 MAY be
+ chosen larger, and this is RECOMMENDED if it is known in advance
+ (such as on high latency access links) that the RTT is larger.
+ Whatever the value of T1, the exponential backoffs on retransmissions
+ described in this section MUST be used.
+
+ If the client transaction is still in the "Calling" state when timer
+ B fires, the client transaction SHOULD inform the TU that a timeout
+ has occurred. The client transaction MUST NOT generate an ACK. The
+ value of 64*T1 is equal to the amount of time required to send seven
+ requests in the case of an unreliable transport.
+
+ If the client transaction receives a provisional response while in
+ the "Calling" state, it transitions to the "Proceeding" state. In the
+ "Proceeding" state, the client transaction SHOULD NOT retransmit the
+ request any longer. Furthermore, the provisional response MUST be
+ passed to the TU. Any further provisional responses MUST be passed
+ up to the TU while in the "Proceeding" state.
+
+ When in either the "Calling" or "Proceeding" states, reception of a
+ response with status code from 300-699 MUST cause the client
+ transaction to transition to "Completed". The client transaction
+ MUST pass the received response up to the TU, and the client
+ transaction MUST generate an ACK request, even if the transport is
+ reliable (guidelines for constructing the ACK from the response are
+ given in Section 17.1.1.3) and then pass the ACK to the transport
+ layer for transmission. The ACK MUST be sent to the same address,
+ port, and transport to which the original request was sent. The
+ client transaction SHOULD start timer D when it enters the
+ "Completed" state, with a value of at least 32 seconds for unreliable
+ transports, and a value of zero seconds for reliable transports.
+ Timer D reflects the amount of time that the server transaction can
+ remain in the "Completed" state when unreliable transports are used.
+ This is equal to Timer H in the INVITE server transaction, whose
+
+
+
+Rosenberg, et. al. Standards Track [Page 126]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ default is 64*T1. However, the client transaction does not know the
+ value of T1 in use by the server transaction, so an absolute minimum
+ of 32s is used instead of basing Timer D on T1.
+
+ Any retransmissions of the final response that are received while in
+ the "Completed" state MUST cause the ACK to be re-passed to the
+ transport layer for retransmission, but the newly received response
+ MUST NOT be passed up to the TU. A retransmission of the response is
+ defined as any response which would match the same client transaction
+ based on the rules of Section 17.1.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 127]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ |INVITE from TU
+ Timer A fires |INVITE sent
+ Reset A, V Timer B fires
+ INVITE sent +-----------+ or Transport Err.
+ +---------| |---------------+inform TU
+ | | Calling | |
+ +-------->| |-------------->|
+ +-----------+ 2xx |
+ | | 2xx to TU |
+ | |1xx |
+ 300-699 +---------------+ |1xx to TU |
+ ACK sent | | |
+resp. to TU | 1xx V |
+ | 1xx to TU -----------+ |
+ | +---------| | |
+ | | |Proceeding |-------------->|
+ | +-------->| | 2xx |
+ | +-----------+ 2xx to TU |
+ | 300-699 | |
+ | ACK sent, | |
+ | resp. to TU| |
+ | | | NOTE:
+ | 300-699 V |
+ | ACK sent +-----------+Transport Err. | transitions
+ | +---------| |Inform TU | labeled with
+ | | | Completed |-------------->| the event
+ | +-------->| | | over the action
+ | +-----------+ | to take
+ | ^ | |
+ | | | Timer D fires |
+ +--------------+ | - |
+ | |
+ V |
+ +-----------+ |
+ | | |
+ | Terminated|<--------------+
+ | |
+ +-----------+
+
+ Figure 5: INVITE client transaction
+
+ If timer D fires while the client transaction is in the "Completed"
+ state, the client transaction MUST move to the terminated state.
+
+ When in either the "Calling" or "Proceeding" states, reception of a
+ 2xx response MUST cause the client transaction to enter the
+ "Terminated" state, and the response MUST be passed up to the TU.
+ The handling of this response depends on whether the TU is a proxy
+
+
+
+Rosenberg, et. al. Standards Track [Page 128]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ core or a UAC core. A UAC core will handle generation of the ACK for
+ this response, while a proxy core will always forward the 200 (OK)
+ upstream. The differing treatment of 200 (OK) between proxy and UAC
+ is the reason that handling of it does not take place in the
+ transaction layer.
+
+ The client transaction MUST be destroyed the instant it enters the
+ "Terminated" state. This is actually necessary to guarantee correct
+ operation. The reason is that 2xx responses to an INVITE are treated
+ differently; each one is forwarded by proxies, and the ACK handling
+ in a UAC is different. Thus, each 2xx needs to be passed to a proxy
+ core (so that it can be forwarded) and to a UAC core (so it can be
+ acknowledged). No transaction layer processing takes place.
+ Whenever a response is received by the transport, if the transport
+ layer finds no matching client transaction (using the rules of
+ Section 17.1.3), the response is passed directly to the core. Since
+ the matching client transaction is destroyed by the first 2xx,
+ subsequent 2xx will find no match and therefore be passed to the
+ core.
+
+17.1.1.3 Construction of the ACK Request
+
+ This section specifies the construction of ACK requests sent within
+ the client transaction. A UAC core that generates an ACK for 2xx
+ MUST instead follow the rules described in Section 13.
+
+ The ACK request constructed by the client transaction MUST contain
+ values for the Call-ID, From, and Request-URI that are equal to the
+ values of those header fields in the request passed to the transport
+ by the client transaction (call this the "original request"). The To
+ header field in the ACK MUST equal the To header field in the
+ response being acknowledged, and therefore will usually differ from
+ the To header field in the original request by the addition of the
+ tag parameter. The ACK MUST contain a single Via header field, and
+ this MUST be equal to the top Via header field of the original
+ request. The CSeq header field in the ACK MUST contain the same
+ value for the sequence number as was present in the original request,
+ but the method parameter MUST be equal to "ACK".
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 129]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ If the INVITE request whose response is being acknowledged had Route
+ header fields, those header fields MUST appear in the ACK. This is
+ to ensure that the ACK can be routed properly through any downstream
+ stateless proxies.
+
+ Although any request MAY contain a body, a body in an ACK is special
+ since the request cannot be rejected if the body is not understood.
+ Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED,
+ but if done, the body types are restricted to any that appeared in
+ the INVITE, assuming that the response to the INVITE was not 415. If
+ it was, the body in the ACK MAY be any type listed in the Accept
+ header field in the 415.
+
+ For example, consider the following request:
+
+ INVITE sip:bob@biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
+ To: Bob <sip:bob@biloxi.com>
+ From: Alice <sip:alice@atlanta.com>;tag=88sja8x
+ Max-Forwards: 70
+ Call-ID: 987asjd97y7atg
+ CSeq: 986759 INVITE
+
+ The ACK request for a non-2xx final response to this request would
+ look like this:
+
+ ACK sip:bob@biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
+ To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
+ From: Alice <sip:alice@atlanta.com>;tag=88sja8x
+ Max-Forwards: 70
+ Call-ID: 987asjd97y7atg
+ CSeq: 986759 ACK
+
+17.1.2 Non-INVITE Client Transaction
+
+17.1.2.1 Overview of the non-INVITE Transaction
+
+ Non-INVITE transactions do not make use of ACK. They are simple
+ request-response interactions. For unreliable transports, requests
+ are retransmitted at an interval which starts at T1 and doubles until
+ it hits T2. If a provisional response is received, retransmissions
+ continue for unreliable transports, but at an interval of T2. The
+ server transaction retransmits the last response it sent, which can
+ be a provisional or final response, only when a retransmission of the
+ request is received. This is why request retransmissions need to
+ continue even after a provisional response; they are to ensure
+ reliable delivery of the final response.
+
+
+
+Rosenberg, et. al. Standards Track [Page 130]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Unlike an INVITE transaction, a non-INVITE transaction has no special
+ handling for the 2xx response. The result is that only a single 2xx
+ response to a non-INVITE is ever delivered to a UAC.
+
+17.1.2.2 Formal Description
+
+ The state machine for the non-INVITE client transaction is shown in
+ Figure 6. It is very similar to the state machine for INVITE.
+
+ The "Trying" state is entered when the TU initiates a new client
+ transaction with a request. When entering this state, the client
+ transaction SHOULD set timer F to fire in 64*T1 seconds. The request
+ MUST be passed to the transport layer for transmission. If an
+ unreliable transport is in use, the client transaction MUST set timer
+ E to fire in T1 seconds. If timer E fires while still in this state,
+ the timer is reset, but this time with a value of MIN(2*T1, T2).
+ When the timer fires again, it is reset to a MIN(4*T1, T2). This
+ process continues so that retransmissions occur with an exponentially
+ increasing interval that caps at T2. The default value of T2 is 4s,
+ and it represents the amount of time a non-INVITE server transaction
+ will take to respond to a request, if it does not respond
+ immediately. For the default values of T1 and T2, this results in
+ intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.
+
+ If Timer F fires while the client transaction is still in the
+ "Trying" state, the client transaction SHOULD inform the TU about the
+ timeout, and then it SHOULD enter the "Terminated" state. If a
+ provisional response is received while in the "Trying" state, the
+ response MUST be passed to the TU, and then the client transaction
+ SHOULD move to the "Proceeding" state. If a final response (status
+ codes 200-699) is received while in the "Trying" state, the response
+ MUST be passed to the TU, and the client transaction MUST transition
+ to the "Completed" state.
+
+ If Timer E fires while in the "Proceeding" state, the request MUST be
+ passed to the transport layer for retransmission, and Timer E MUST be
+ reset with a value of T2 seconds. If timer F fires while in the
+ "Proceeding" state, the TU MUST be informed of a timeout, and the
+ client transaction MUST transition to the terminated state. If a
+ final response (status codes 200-699) is received while in the
+ "Proceeding" state, the response MUST be passed to the TU, and the
+ client transaction MUST transition to the "Completed" state.
+
+ Once the client transaction enters the "Completed" state, it MUST set
+ Timer K to fire in T4 seconds for unreliable transports, and zero
+ seconds for reliable transports. The "Completed" state exists to
+ buffer any additional response retransmissions that may be received
+ (which is why the client transaction remains there only for
+
+
+
+Rosenberg, et. al. Standards Track [Page 131]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ unreliable transports). T4 represents the amount of time the network
+ will take to clear messages between client and server transactions.
+ The default value of T4 is 5s. A response is a retransmission when
+ it matches the same transaction, using the rules specified in Section
+ 17.1.3. If Timer K fires while in this state, the client transaction
+ MUST transition to the "Terminated" state.
+
+ Once the transaction is in the terminated state, it MUST be destroyed
+ immediately.
+
+17.1.3 Matching Responses to Client Transactions
+
+ When the transport layer in the client receives a response, it has to
+ determine which client transaction will handle the response, so that
+ the processing of Sections 17.1.1 and 17.1.2 can take place. The
+ branch parameter in the top Via header field is used for this
+ purpose. A response matches a client transaction under two
+ conditions:
+
+ 1. If the response has the same value of the branch parameter in
+ the top Via header field as the branch parameter in the top
+ Via header field of the request that created the transaction.
+
+ 2. If the method parameter in the CSeq header field matches the
+ method of the request that created the transaction. The
+ method is needed since a CANCEL request constitutes a
+ different transaction, but shares the same value of the branch
+ parameter.
+
+ If a request is sent via multicast, it is possible that it will
+ generate multiple responses from different servers. These responses
+ will all have the same branch parameter in the topmost Via, but vary
+ in the To tag. The first response received, based on the rules
+ above, will be used, and others will be viewed as retransmissions.
+ That is not an error; multicast SIP provides only a rudimentary
+ "single-hop-discovery-like" service that is limited to processing a
+ single response. See Section 18.1.1 for details.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 132]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+17.1.4 Handling Transport Errors
+
+ |Request from TU
+ |send request
+ Timer E V
+ send request +-----------+
+ +---------| |-------------------+
+ | | Trying | Timer F |
+ +-------->| | or Transport Err.|
+ +-----------+ inform TU |
+ 200-699 | | |
+ resp. to TU | |1xx |
+ +---------------+ |resp. to TU |
+ | | |
+ | Timer E V Timer F |
+ | send req +-----------+ or Transport Err. |
+ | +---------| | inform TU |
+ | | |Proceeding |------------------>|
+ | +-------->| |-----+ |
+ | +-----------+ |1xx |
+ | | ^ |resp to TU |
+ | 200-699 | +--------+ |
+ | resp. to TU | |
+ | | |
+ | V |
+ | +-----------+ |
+ | | | |
+ | | Completed | |
+ | | | |
+ | +-----------+ |
+ | ^ | |
+ | | | Timer K |
+ +--------------+ | - |
+ | |
+ V |
+ NOTE: +-----------+ |
+ | | |
+ transitions | Terminated|<------------------+
+ labeled with | |
+ the event +-----------+
+ over the action
+ to take
+
+ Figure 6: non-INVITE client transaction
+
+ When the client transaction sends a request to the transport layer to
+ be sent, the following procedures are followed if the transport layer
+ indicates a failure.
+
+
+
+Rosenberg, et. al. Standards Track [Page 133]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The client transaction SHOULD inform the TU that a transport failure
+ has occurred, and the client transaction SHOULD transition directly
+ to the "Terminated" state. The TU will handle the failover
+ mechanisms described in [4].
+
+17.2 Server Transaction
+
+ The server transaction is responsible for the delivery of requests to
+ the TU and the reliable transmission of responses. It accomplishes
+ this through a state machine. Server transactions are created by the
+ core when a request is received, and transaction handling is desired
+ for that request (this is not always the case).
+
+ As with the client transactions, the state machine depends on whether
+ the received request is an INVITE request.
+
+17.2.1 INVITE Server Transaction
+
+ The state diagram for the INVITE server transaction is shown in
+ Figure 7.
+
+ When a server transaction is constructed for a request, it enters the
+ "Proceeding" state. The server transaction MUST generate a 100
+ (Trying) response unless it knows that the TU will generate a
+ provisional or final response within 200 ms, in which case it MAY
+ generate a 100 (Trying) response. This provisional response is
+ needed to quench request retransmissions rapidly in order to avoid
+ network congestion. The 100 (Trying) response is constructed
+ according to the procedures in Section 8.2.6, except that the
+ insertion of tags in the To header field of the response (when none
+ was present in the request) is downgraded from MAY to SHOULD NOT.
+ The request MUST be passed to the TU.
+
+ The TU passes any number of provisional responses to the server
+ transaction. So long as the server transaction is in the
+ "Proceeding" state, each of these MUST be passed to the transport
+ layer for transmission. They are not sent reliably by the
+ transaction layer (they are not retransmitted by it) and do not cause
+ a change in the state of the server transaction. If a request
+ retransmission is received while in the "Proceeding" state, the most
+ recent provisional response that was received from the TU MUST be
+ passed to the transport layer for retransmission. A request is a
+ retransmission if it matches the same server transaction based on the
+ rules of Section 17.2.3.
+
+ If, while in the "Proceeding" state, the TU passes a 2xx response to
+ the server transaction, the server transaction MUST pass this
+ response to the transport layer for transmission. It is not
+
+
+
+Rosenberg, et. al. Standards Track [Page 134]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ retransmitted by the server transaction; retransmissions of 2xx
+ responses are handled by the TU. The server transaction MUST then
+ transition to the "Terminated" state.
+
+ While in the "Proceeding" state, if the TU passes a response with
+ status code from 300 to 699 to the server transaction, the response
+ MUST be passed to the transport layer for transmission, and the state
+ machine MUST enter the "Completed" state. For unreliable transports,
+ timer G is set to fire in T1 seconds, and is not set to fire for
+ reliable transports.
+
+ This is a change from RFC 2543, where responses were always
+ retransmitted, even over reliable transports.
+
+ When the "Completed" state is entered, timer H MUST be set to fire in
+ 64*T1 seconds for all transports. Timer H determines when the server
+ transaction abandons retransmitting the response. Its value is
+ chosen to equal Timer B, the amount of time a client transaction will
+ continue to retry sending a request. If timer G fires, the response
+ is passed to the transport layer once more for retransmission, and
+ timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when
+ timer G fires, the response is passed to the transport again for
+ transmission, and timer G is reset with a value that doubles, unless
+ that value exceeds T2, in which case it is reset with the value of
+ T2. This is identical to the retransmit behavior for requests in the
+ "Trying" state of the non-INVITE client transaction. Furthermore,
+ while in the "Completed" state, if a request retransmission is
+ received, the server SHOULD pass the response to the transport for
+ retransmission.
+
+ If an ACK is received while the server transaction is in the
+ "Completed" state, the server transaction MUST transition to the
+ "Confirmed" state. As Timer G is ignored in this state, any
+ retransmissions of the response will cease.
+
+ If timer H fires while in the "Completed" state, it implies that the
+ ACK was never received. In this case, the server transaction MUST
+ transition to the "Terminated" state, and MUST indicate to the TU
+ that a transaction failure has occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 135]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ |INVITE
+ |pass INV to TU
+ INVITE V send 100 if TU won't in 200ms
+ send response+-----------+
+ +--------| |--------+101-199 from TU
+ | | Proceeding| |send response
+ +------->| |<-------+
+ | | Transport Err.
+ | | Inform TU
+ | |--------------->+
+ +-----------+ |
+ 300-699 from TU | |2xx from TU |
+ send response | |send response |
+ | +------------------>+
+ | |
+ INVITE V Timer G fires |
+ send response+-----------+ send response |
+ +--------| |--------+ |
+ | | Completed | | |
+ +------->| |<-------+ |
+ +-----------+ |
+ | | |
+ ACK | | |
+ - | +------------------>+
+ | Timer H fires |
+ V or Transport Err.|
+ +-----------+ Inform TU |
+ | | |
+ | Confirmed | |
+ | | |
+ +-----------+ |
+ | |
+ |Timer I fires |
+ |- |
+ | |
+ V |
+ +-----------+ |
+ | | |
+ | Terminated|<---------------+
+ | |
+ +-----------+
+
+ Figure 7: INVITE server transaction
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 136]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The purpose of the "Confirmed" state is to absorb any additional ACK
+ messages that arrive, triggered from retransmissions of the final
+ response. When this state is entered, timer I is set to fire in T4
+ seconds for unreliable transports, and zero seconds for reliable
+ transports. Once timer I fires, the server MUST transition to the
+ "Terminated" state.
+
+ Once the transaction is in the "Terminated" state, it MUST be
+ destroyed immediately. As with client transactions, this is needed
+ to ensure reliability of the 2xx responses to INVITE.
+
+17.2.2 Non-INVITE Server Transaction
+
+ The state machine for the non-INVITE server transaction is shown in
+ Figure 8.
+
+ The state machine is initialized in the "Trying" state and is passed
+ a request other than INVITE or ACK when initialized. This request is
+ passed up to the TU. Once in the "Trying" state, any further request
+ retransmissions are discarded. A request is a retransmission if it
+ matches the same server transaction, using the rules specified in
+ Section 17.2.3.
+
+ While in the "Trying" state, if the TU passes a provisional response
+ to the server transaction, the server transaction MUST enter the
+ "Proceeding" state. The response MUST be passed to the transport
+ layer for transmission. Any further provisional responses that are
+ received from the TU while in the "Proceeding" state MUST be passed
+ to the transport layer for transmission. If a retransmission of the
+ request is received while in the "Proceeding" state, the most
+ recently sent provisional response MUST be passed to the transport
+ layer for retransmission. If the TU passes a final response (status
+ codes 200-699) to the server while in the "Proceeding" state, the
+ transaction MUST enter the "Completed" state, and the response MUST
+ be passed to the transport layer for transmission.
+
+ When the server transaction enters the "Completed" state, it MUST set
+ Timer J to fire in 64*T1 seconds for unreliable transports, and zero
+ seconds for reliable transports. While in the "Completed" state, the
+ server transaction MUST pass the final response to the transport
+ layer for retransmission whenever a retransmission of the request is
+ received. Any other final responses passed by the TU to the server
+ transaction MUST be discarded while in the "Completed" state. The
+ server transaction remains in this state until Timer J fires, at
+ which point it MUST transition to the "Terminated" state.
+
+ The server transaction MUST be destroyed the instant it enters the
+ "Terminated" state.
+
+
+
+Rosenberg, et. al. Standards Track [Page 137]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+17.2.3 Matching Requests to Server Transactions
+
+ When a request is received from the network by the server, it has to
+ be matched to an existing transaction. This is accomplished in the
+ following manner.
+
+ The branch parameter in the topmost Via header field of the request
+ is examined. If it is present and begins with the magic cookie
+ "z9hG4bK", the request was generated by a client transaction
+ compliant to this specification. Therefore, the branch parameter
+ will be unique across all transactions sent by that client. The
+ request matches a transaction if:
+
+ 1. the branch parameter in the request is equal to the one in the
+ top Via header field of the request that created the
+ transaction, and
+
+ 2. the sent-by value in the top Via of the request is equal to the
+ one in the request that created the transaction, and
+
+ 3. the method of the request matches the one that created the
+ transaction, except for ACK, where the method of the request
+ that created the transaction is INVITE.
+
+ This matching rule applies to both INVITE and non-INVITE transactions
+ alike.
+
+ The sent-by value is used as part of the matching process because
+ there could be accidental or malicious duplication of branch
+ parameters from different clients.
+
+ If the branch parameter in the top Via header field is not present,
+ or does not contain the magic cookie, the following procedures are
+ used. These exist to handle backwards compatibility with RFC 2543
+ compliant implementations.
+
+ The INVITE request matches a transaction if the Request-URI, To tag,
+ From tag, Call-ID, CSeq, and top Via header field match those of the
+ INVITE request which created the transaction. In this case, the
+ INVITE is a retransmission of the original one that created the
+ transaction. The ACK request matches a transaction if the Request-
+ URI, From tag, Call-ID, CSeq number (not the method), and top Via
+ header field match those of the INVITE request which created the
+ transaction, and the To tag of the ACK matches the To tag of the
+ response sent by the server transaction. Matching is done based on
+ the matching rules defined for each of those header fields.
+ Inclusion of the tag in the To header field in the ACK matching
+ process helps disambiguate ACK for 2xx from ACK for other responses
+
+
+
+Rosenberg, et. al. Standards Track [Page 138]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ at a proxy, which may have forwarded both responses (This can occur
+ in unusual conditions. Specifically, when a proxy forked a request,
+ and then crashes, the responses may be delivered to another proxy,
+ which might end up forwarding multiple responses upstream). An ACK
+ request that matches an INVITE transaction matched by a previous ACK
+ is considered a retransmission of that previous ACK.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 139]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ |Request received
+ |pass to TU
+ V
+ +-----------+
+ | |
+ | Trying |-------------+
+ | | |
+ +-----------+ |200-699 from TU
+ | |send response
+ |1xx from TU |
+ |send response |
+ | |
+ Request V 1xx from TU |
+ send response+-----------+send response|
+ +--------| |--------+ |
+ | | Proceeding| | |
+ +------->| |<-------+ |
+ +<--------------| | |
+ |Trnsprt Err +-----------+ |
+ |Inform TU | |
+ | | |
+ | |200-699 from TU |
+ | |send response |
+ | Request V |
+ | send response+-----------+ |
+ | +--------| | |
+ | | | Completed |<------------+
+ | +------->| |
+ +<--------------| |
+ |Trnsprt Err +-----------+
+ |Inform TU |
+ | |Timer J fires
+ | |-
+ | |
+ | V
+ | +-----------+
+ | | |
+ +-------------->| Terminated|
+ | |
+ +-----------+
+
+ Figure 8: non-INVITE server transaction
+
+ For all other request methods, a request is matched to a transaction
+ if the Request-URI, To tag, From tag, Call-ID, CSeq (including the
+ method), and top Via header field match those of the request that
+ created the transaction. Matching is done based on the matching
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 140]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ rules defined for each of those header fields. When a non-INVITE
+ request matches an existing transaction, it is a retransmission of
+ the request that created that transaction.
+
+ Because the matching rules include the Request-URI, the server cannot
+ match a response to a transaction. When the TU passes a response to
+ the server transaction, it must pass it to the specific server
+ transaction for which the response is targeted.
+
+17.2.4 Handling Transport Errors
+
+ When the server transaction sends a response to the transport layer
+ to be sent, the following procedures are followed if the transport
+ layer indicates a failure.
+
+ First, the procedures in [4] are followed, which attempt to deliver
+ the response to a backup. If those should all fail, based on the
+ definition of failure in [4], the server transaction SHOULD inform
+ the TU that a failure has occurred, and SHOULD transition to the
+ terminated state.
+
+18 Transport
+
+ The transport layer is responsible for the actual transmission of
+ requests and responses over network transports. This includes
+ determination of the connection to use for a request or response in
+ the case of connection-oriented transports.
+
+ The transport layer is responsible for managing persistent
+ connections for transport protocols like TCP and SCTP, or TLS over
+ those, including ones opened to the transport layer. This includes
+ connections opened by the client or server transports, so that
+ connections are shared between client and server transport functions.
+ These connections are indexed by the tuple formed from the address,
+ port, and transport protocol at the far end of the connection. When
+ a connection is opened by the transport layer, this index is set to
+ the destination IP, port and transport. When the connection is
+ accepted by the transport layer, this index is set to the source IP
+ address, port number, and transport. Note that, because the source
+ port is often ephemeral, but it cannot be known whether it is
+ ephemeral or selected through procedures in [4], connections accepted
+ by the transport layer will frequently not be reused. The result is
+ that two proxies in a "peering" relationship using a connection-
+ oriented transport frequently will have two connections in use, one
+ for transactions initiated in each direction.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 141]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ It is RECOMMENDED that connections be kept open for some
+ implementation-defined duration after the last message was sent or
+ received over that connection. This duration SHOULD at least equal
+ the longest amount of time the element would need in order to bring a
+ transaction from instantiation to the terminated state. This is to
+ make it likely that transactions are completed over the same
+ connection on which they are initiated (for example, request,
+ response, and in the case of INVITE, ACK for non-2xx responses).
+ This usually means at least 64*T1 (see Section 17.1.1.1 for a
+ definition of T1). However, it could be larger in an element that
+ has a TU using a large value for timer C (bullet 11 of Section 16.6),
+ for example.
+
+ All SIP elements MUST implement UDP and TCP. SIP elements MAY
+ implement other protocols.
+
+ Making TCP mandatory for the UA is a substantial change from RFC
+ 2543. It has arisen out of the need to handle larger messages,
+ which MUST use TCP, as discussed below. Thus, even if an element
+ never sends large messages, it may receive one and needs to be
+ able to handle them.
+
+18.1 Clients
+
+18.1.1 Sending Requests
+
+ The client side of the transport layer is responsible for sending the
+ request and receiving responses. The user of the transport layer
+ passes the client transport the request, an IP address, port,
+ transport, and possibly TTL for multicast destinations.
+
+ If a request is within 200 bytes of the path MTU, or if it is larger
+ than 1300 bytes and the path MTU is unknown, the request MUST be sent
+ using an RFC 2914 [43] congestion controlled transport protocol, such
+ as TCP. If this causes a change in the transport protocol from the
+ one indicated in the top Via, the value in the top Via MUST be
+ changed. This prevents fragmentation of messages over UDP and
+ provides congestion control for larger messages. However,
+ implementations MUST be able to handle messages up to the maximum
+ datagram packet size. For UDP, this size is 65,535 bytes, including
+ IP and UDP headers.
+
+ The 200 byte "buffer" between the message size and the MTU
+ accommodates the fact that the response in SIP can be larger than
+ the request. This happens due to the addition of Record-Route
+ header field values to the responses to INVITE, for example. With
+ the extra buffer, the response can be about 170 bytes larger than
+ the request, and still not be fragmented on IPv4 (about 30 bytes
+
+
+
+Rosenberg, et. al. Standards Track [Page 142]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when
+ path MTU is not known, based on the assumption of a 1500 byte
+ Ethernet MTU.
+
+ If an element sends a request over TCP because of these message size
+ constraints, and that request would have otherwise been sent over
+ UDP, if the attempt to establish the connection generates either an
+ ICMP Protocol Not Supported, or results in a TCP reset, the element
+ SHOULD retry the request, using UDP. This is only to provide
+ backwards compatibility with RFC 2543 compliant implementations that
+ do not support TCP. It is anticipated that this behavior will be
+ deprecated in a future revision of this specification.
+
+ A client that sends a request to a multicast address MUST add the
+ "maddr" parameter to its Via header field value containing the
+ destination multicast address, and for IPv4, SHOULD add the "ttl"
+ parameter with a value of 1. Usage of IPv6 multicast is not defined
+ in this specification, and will be a subject of future
+ standardization when the need arises.
+
+ These rules result in a purposeful limitation of multicast in SIP.
+ Its primary function is to provide a "single-hop-discovery-like"
+ service, delivering a request to a group of homogeneous servers,
+ where it is only required to process the response from any one of
+ them. This functionality is most useful for registrations. In fact,
+ based on the transaction processing rules in Section 17.1.3, the
+ client transaction will accept the first response, and view any
+ others as retransmissions because they all contain the same Via
+ branch identifier.
+
+ Before a request is sent, the client transport MUST insert a value of
+ the "sent-by" field into the Via header field. This field contains
+ an IP address or host name, and port. The usage of an FQDN is
+ RECOMMENDED. This field is used for sending responses under certain
+ conditions, described below. If the port is absent, the default
+ value depends on the transport. It is 5060 for UDP, TCP and SCTP,
+ 5061 for TLS.
+
+ For reliable transports, the response is normally sent on the
+ connection on which the request was received. Therefore, the client
+ transport MUST be prepared to receive the response on the same
+ connection used to send the request. Under error conditions, the
+ server may attempt to open a new connection to send the response. To
+ handle this case, the transport layer MUST also be prepared to
+ receive an incoming connection on the source IP address from which
+ the request was sent and port number in the "sent-by" field. It also
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 143]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ MUST be prepared to receive incoming connections on any address and
+ port that would be selected by a server based on the procedures
+ described in Section 5 of [4].
+
+ For unreliable unicast transports, the client transport MUST be
+ prepared to receive responses on the source IP address from which the
+ request is sent (as responses are sent back to the source address)
+ and the port number in the "sent-by" field. Furthermore, as with
+ reliable transports, in certain cases the response will be sent
+ elsewhere. The client MUST be prepared to receive responses on any
+ address and port that would be selected by a server based on the
+ procedures described in Section 5 of [4].
+
+ For multicast, the client transport MUST be prepared to receive
+ responses on the same multicast group and port to which the request
+ is sent (that is, it needs to be a member of the multicast group it
+ sent the request to.)
+
+ If a request is destined to an IP address, port, and transport to
+ which an existing connection is open, it is RECOMMENDED that this
+ connection be used to send the request, but another connection MAY be
+ opened and used.
+
+ If a request is sent using multicast, it is sent to the group
+ address, port, and TTL provided by the transport user. If a request
+ is sent using unicast unreliable transports, it is sent to the IP
+ address and port provided by the transport user.
+
+18.1.2 Receiving Responses
+
+ When a response is received, the client transport examines the top
+ Via header field value. If the value of the "sent-by" parameter in
+ that header field value does not correspond to a value that the
+ client transport is configured to insert into requests, the response
+ MUST be silently discarded.
+
+ If there are any client transactions in existence, the client
+ transport uses the matching procedures of Section 17.1.3 to attempt
+ to match the response to an existing transaction. If there is a
+ match, the response MUST be passed to that transaction. Otherwise,
+ the response MUST be passed to the core (whether it be stateless
+ proxy, stateful proxy, or UA) for further processing. Handling of
+ these "stray" responses is dependent on the core (a proxy will
+ forward them, while a UA will discard, for example).
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 144]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+18.2 Servers
+
+18.2.1 Receiving Requests
+
+ A server SHOULD be prepared to receive requests on any IP address,
+ port and transport combination that can be the result of a DNS lookup
+ on a SIP or SIPS URI [4] that is handed out for the purposes of
+ communicating with that server. In this context, "handing out"
+ includes placing a URI in a Contact header field in a REGISTER
+ request or a redirect response, or in a Record-Route header field in
+ a request or response. A URI can also be "handed out" by placing it
+ on a web page or business card. It is also RECOMMENDED that a server
+ listen for requests on the default SIP ports (5060 for TCP and UDP,
+ 5061 for TLS over TCP) on all public interfaces. The typical
+ exception would be private networks, or when multiple server
+ instances are running on the same host. For any port and interface
+ that a server listens on for UDP, it MUST listen on that same port
+ and interface for TCP. This is because a message may need to be sent
+ using TCP, rather than UDP, if it is too large. As a result, the
+ converse is not true. A server need not listen for UDP on a
+ particular address and port just because it is listening on that same
+ address and port for TCP. There may, of course, be other reasons why
+ a server needs to listen for UDP on a particular address and port.
+
+ When the server transport receives a request over any transport, it
+ MUST examine the value of the "sent-by" parameter in the top Via
+ header field value. If the host portion of the "sent-by" parameter
+ contains a domain name, or if it contains an IP address that differs
+ from the packet source address, the server MUST add a "received"
+ parameter to that Via header field value. This parameter MUST
+ contain the source address from which the packet was received. This
+ is to assist the server transport layer in sending the response,
+ since it must be sent to the source IP address from which the request
+ came.
+
+ Consider a request received by the server transport which looks like,
+ in part:
+
+ INVITE sip:bob@Biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP bobspc.biloxi.com:5060
+
+ The request is received with a source IP address of 192.0.2.4.
+ Before passing the request up, the transport adds a "received"
+ parameter, so that the request would look like, in part:
+
+ INVITE sip:bob@Biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 145]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Next, the server transport attempts to match the request to a server
+ transaction. It does so using the matching rules described in
+ Section 17.2.3. If a matching server transaction is found, the
+ request is passed to that transaction for processing. If no match is
+ found, the request is passed to the core, which may decide to
+ construct a new server transaction for that request. Note that when
+ a UAS core sends a 2xx response to INVITE, the server transaction is
+ destroyed. This means that when the ACK arrives, there will be no
+ matching server transaction, and based on this rule, the ACK is
+ passed to the UAS core, where it is processed.
+
+18.2.2 Sending Responses
+
+ The server transport uses the value of the top Via header field in
+ order to determine where to send a response. It MUST follow the
+ following process:
+
+ o If the "sent-protocol" is a reliable transport protocol such as
+ TCP or SCTP, or TLS over those, the response MUST be sent using
+ the existing connection to the source of the original request
+ that created the transaction, if that connection is still open.
+ This requires the server transport to maintain an association
+ between server transactions and transport connections. If that
+ connection is no longer open, the server SHOULD open a
+ connection to the IP address in the "received" parameter, if
+ present, using the port in the "sent-by" value, or the default
+ port for that transport, if no port is specified. If that
+ connection attempt fails, the server SHOULD use the procedures
+ in [4] for servers in order to determine the IP address and
+ port to open the connection and send the response to.
+
+ o Otherwise, if the Via header field value contains a "maddr"
+ parameter, the response MUST be forwarded to the address listed
+ there, using the port indicated in "sent-by", or port 5060 if
+ none is present. If the address is a multicast address, the
+ response SHOULD be sent using the TTL indicated in the "ttl"
+ parameter, or with a TTL of 1 if that parameter is not present.
+
+ o Otherwise (for unreliable unicast transports), if the top Via
+ has a "received" parameter, the response MUST be sent to the
+ address in the "received" parameter, using the port indicated
+ in the "sent-by" value, or using port 5060 if none is specified
+ explicitly. If this fails, for example, elicits an ICMP "port
+ unreachable" response, the procedures of Section 5 of [4]
+ SHOULD be used to determine where to send the response.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 146]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o Otherwise, if it is not receiver-tagged, the response MUST be
+ sent to the address indicated by the "sent-by" value, using the
+ procedures in Section 5 of [4].
+
+18.3 Framing
+
+ In the case of message-oriented transports (such as UDP), if the
+ message has a Content-Length header field, the message body is
+ assumed to contain that many bytes. If there are additional bytes in
+ the transport packet beyond the end of the body, they MUST be
+ discarded. If the transport packet ends before the end of the
+ message body, this is considered an error. If the message is a
+ response, it MUST be discarded. If the message is a request, the
+ element SHOULD generate a 400 (Bad Request) response. If the message
+ has no Content-Length header field, the message body is assumed to
+ end at the end of the transport packet.
+
+ In the case of stream-oriented transports such as TCP, the Content-
+ Length header field indicates the size of the body. The Content-
+ Length header field MUST be used with stream oriented transports.
+
+18.4 Error Handling
+
+ Error handling is independent of whether the message was a request or
+ response.
+
+ If the transport user asks for a message to be sent over an
+ unreliable transport, and the result is an ICMP error, the behavior
+ depends on the type of ICMP error. Host, network, port or protocol
+ unreachable errors, or parameter problem errors SHOULD cause the
+ transport layer to inform the transport user of a failure in sending.
+ Source quench and TTL exceeded ICMP errors SHOULD be ignored.
+
+ If the transport user asks for a request to be sent over a reliable
+ transport, and the result is a connection failure, the transport
+ layer SHOULD inform the transport user of a failure in sending.
+
+19 Common Message Components
+
+ There are certain components of SIP messages that appear in various
+ places within SIP messages (and sometimes, outside of them) that
+ merit separate discussion.
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 147]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+19.1 SIP and SIPS Uniform Resource Indicators
+
+ A SIP or SIPS URI identifies a communications resource. Like all
+ URIs, SIP and SIPS URIs may be placed in web pages, email messages,
+ or printed literature. They contain sufficient information to
+ initiate and maintain a communication session with the resource.
+
+ Examples of communications resources include the following:
+
+ o a user of an online service
+
+ o an appearance on a multi-line phone
+
+ o a mailbox on a messaging system
+
+ o a PSTN number at a gateway service
+
+ o a group (such as "sales" or "helpdesk") in an organization
+
+ A SIPS URI specifies that the resource be contacted securely. This
+ means, in particular, that TLS is to be used between the UAC and the
+ domain that owns the URI. From there, secure communications are used
+ to reach the user, where the specific security mechanism depends on
+ the policy of the domain. Any resource described by a SIP URI can be
+ "upgraded" to a SIPS URI by just changing the scheme, if it is
+ desired to communicate with that resource securely.
+
+19.1.1 SIP and SIPS URI Components
+
+ The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5].
+ They use a form similar to the mailto URL, allowing the specification
+ of SIP request-header fields and the SIP message-body. This makes it
+ possible to specify the subject, media type, or urgency of sessions
+ initiated by using a URI on a web page or in an email message. The
+ formal syntax for a SIP or SIPS URI is presented in Section 25. Its
+ general form, in the case of a SIP URI, is:
+
+ sip:user:password@host:port;uri-parameters?headers
+
+ The format for a SIPS URI is the same, except that the scheme is
+ "sips" instead of sip. These tokens, and some of the tokens in their
+ expansions, have the following meanings:
+
+ user: The identifier of a particular resource at the host being
+ addressed. The term "host" in this context frequently refers
+ to a domain. The "userinfo" of a URI consists of this user
+ field, the password field, and the @ sign following them. The
+ userinfo part of a URI is optional and MAY be absent when the
+
+
+
+Rosenberg, et. al. Standards Track [Page 148]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ destination host does not have a notion of users or when the
+ host itself is the resource being identified. If the @ sign is
+ present in a SIP or SIPS URI, the user field MUST NOT be empty.
+
+ If the host being addressed can process telephone numbers, for
+ instance, an Internet telephony gateway, a telephone-
+ subscriber field defined in RFC 2806 [9] MAY be used to
+ populate the user field. There are special escaping rules for
+ encoding telephone-subscriber fields in SIP and SIPS URIs
+ described in Section 19.1.2.
+
+ password: A password associated with the user. While the SIP and
+ SIPS URI syntax allows this field to be present, its use is NOT
+ RECOMMENDED, because the passing of authentication information
+ in clear text (such as URIs) has proven to be a security risk
+ in almost every case where it has been used. For instance,
+ transporting a PIN number in this field exposes the PIN.
+
+ Note that the password field is just an extension of the user
+ portion. Implementations not wishing to give special
+ significance to the password portion of the field MAY simply
+ treat "user:password" as a single string.
+
+ host: The host providing the SIP resource. The host part contains
+ either a fully-qualified domain name or numeric IPv4 or IPv6
+ address. Using the fully-qualified domain name form is
+ RECOMMENDED whenever possible.
+
+ port: The port number where the request is to be sent.
+
+ URI parameters: Parameters affecting a request constructed from
+ the URI.
+
+ URI parameters are added after the hostport component and are
+ separated by semi-colons.
+
+ URI parameters take the form:
+
+ parameter-name "=" parameter-value
+
+ Even though an arbitrary number of URI parameters may be
+ included in a URI, any given parameter-name MUST NOT appear
+ more than once.
+
+ This extensible mechanism includes the transport, maddr, ttl,
+ user, method and lr parameters.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 149]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The transport parameter determines the transport mechanism to
+ be used for sending SIP messages, as specified in [4]. SIP can
+ use any network transport protocol. Parameter names are
+ defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP
+ (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST
+ indicate a reliable transport.
+
+ The maddr parameter indicates the server address to be
+ contacted for this user, overriding any address derived from
+ the host field. When an maddr parameter is present, the port
+ and transport components of the URI apply to the address
+ indicated in the maddr parameter value. [4] describes the
+ proper interpretation of the transport, maddr, and hostport in
+ order to obtain the destination address, port, and transport
+ for sending a request.
+
+ The maddr field has been used as a simple form of loose source
+ routing. It allows a URI to specify a proxy that must be
+ traversed en-route to the destination. Continuing to use the
+ maddr parameter this way is strongly discouraged (the
+ mechanisms that enable it are deprecated). Implementations
+ should instead use the Route mechanism described in this
+ document, establishing a pre-existing route set if necessary
+ (see Section 8.1.1.1). This provides a full URI to describe
+ the node to be traversed.
+
+ The ttl parameter determines the time-to-live value of the UDP
+ multicast packet and MUST only be used if maddr is a multicast
+ address and the transport protocol is UDP. For example, to
+ specify a call to alice@atlanta.com using multicast to
+ 239.255.255.1 with a ttl of 15, the following URI would be
+ used:
+
+ sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
+
+ The set of valid telephone-subscriber strings is a subset of
+ valid user strings. The user URI parameter exists to
+ distinguish telephone numbers from user names that happen to
+ look like telephone numbers. If the user string contains a
+ telephone number formatted as a telephone-subscriber, the user
+ parameter value "phone" SHOULD be present. Even without this
+ parameter, recipients of SIP and SIPS URIs MAY interpret the
+ pre-@ part as a telephone number if local restrictions on the
+ name space for user name allow it.
+
+ The method of the SIP request constructed from the URI can be
+ specified with the method parameter.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 150]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The lr parameter, when present, indicates that the element
+ responsible for this resource implements the routing mechanisms
+ specified in this document. This parameter will be used in the
+ URIs proxies place into Record-Route header field values, and
+ may appear in the URIs in a pre-existing route set.
+
+ This parameter is used to achieve backwards compatibility with
+ systems implementing the strict-routing mechanisms of RFC 2543
+ and the rfc2543bis drafts up to bis-05. An element preparing
+ to send a request based on a URI not containing this parameter
+ can assume the receiving element implements strict-routing and
+ reformat the message to preserve the information in the
+ Request-URI.
+
+ Since the uri-parameter mechanism is extensible, SIP elements
+ MUST silently ignore any uri-parameters that they do not
+ understand.
+
+ Headers: Header fields to be included in a request constructed
+ from the URI.
+
+ Headers fields in the SIP request can be specified with the "?"
+ mechanism within a URI. The header names and values are
+ encoded in ampersand separated hname = hvalue pairs. The
+ special hname "body" indicates that the associated hvalue is
+ the message-body of the SIP request.
+
+ Table 1 summarizes the use of SIP and SIPS URI components based on
+ the context in which the URI appears. The external column describes
+ URIs appearing anywhere outside of a SIP message, for instance on a
+ web page or business card. Entries marked "m" are mandatory, those
+ marked "o" are optional, and those marked "-" are not allowed.
+ Elements processing URIs SHOULD ignore any disallowed components if
+ they are present. The second column indicates the default value of
+ an optional element if it is not present. "--" indicates that the
+ element is either not optional, or has no default value.
+
+ URIs in Contact header fields have different restrictions depending
+ on the context in which the header field appears. One set applies to
+ messages that establish and maintain dialogs (INVITE and its 200 (OK)
+ response). The other applies to registration and redirection
+ messages (REGISTER, its 200 (OK) response, and 3xx class responses to
+ any method).
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 151]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+19.1.2 Character Escaping Requirements
+
+ dialog
+ reg./redir. Contact/
+ default Req.-URI To From Contact R-R/Route external
+user -- o o o o o o
+password -- o o o o o o
+host -- m m m m m m
+port (1) o - - o o o
+user-param ip o o o o o o
+method INVITE - - - - - o
+maddr-param -- o - - o o o
+ttl-param 1 o - - o - o
+transp.-param (2) o - - o o o
+lr-param -- o - - - o o
+other-param -- o o o o o o
+headers -- - - - o - o
+
+ (1): The default port value is transport and scheme dependent. The
+ default is 5060 for sip: using UDP, TCP, or SCTP. The default is
+ 5061 for sip: using TLS over TCP and sips: over TCP.
+
+ (2): The default transport is scheme dependent. For sip:, it is UDP.
+ For sips:, it is TCP.
+
+ Table 1: Use and default values of URI components for SIP header
+ field values, Request-URI and references
+
+ SIP follows the requirements and guidelines of RFC 2396 [5] when
+ defining the set of characters that must be escaped in a SIP URI, and
+ uses its ""%" HEX HEX" mechanism for escaping. From RFC 2396 [5]:
+
+ The set of characters actually reserved within any given URI
+ component is defined by that component. In general, a character
+ is reserved if the semantics of the URI changes if the character
+ is replaced with its escaped US-ASCII encoding [5]. Excluded US-
+ ASCII characters (RFC 2396 [5]), such as space and control
+ characters and characters used as URI delimiters, also MUST be
+ escaped. URIs MUST NOT contain unescaped space and control
+ characters.
+
+ For each component, the set of valid BNF expansions defines exactly
+ which characters may appear unescaped. All other characters MUST be
+ escaped.
+
+ For example, "@" is not in the set of characters in the user
+ component, so the user "j@s0n" must have at least the @ sign encoded,
+ as in "j%40s0n".
+
+
+
+Rosenberg, et. al. Standards Track [Page 152]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Expanding the hname and hvalue tokens in Section 25 show that all URI
+ reserved characters in header field names and values MUST be escaped.
+
+ The telephone-subscriber subset of the user component has special
+ escaping considerations. The set of characters not reserved in the
+ RFC 2806 [9] description of telephone-subscriber contains a number of
+ characters in various syntax elements that need to be escaped when
+ used in SIP URIs. Any characters occurring in a telephone-subscriber
+ that do not appear in an expansion of the BNF for the user rule MUST
+ be escaped.
+
+ Note that character escaping is not allowed in the host component of
+ a SIP or SIPS URI (the % character is not valid in its expansion).
+ This is likely to change in the future as requirements for
+ Internationalized Domain Names are finalized. Current
+ implementations MUST NOT attempt to improve robustness by treating
+ received escaped characters in the host component as literally
+ equivalent to their unescaped counterpart. The behavior required to
+ meet the requirements of IDN may be significantly different.
+
+19.1.3 Example SIP and SIPS URIs
+
+ sip:alice@atlanta.com
+ sip:alice:secretword@atlanta.com;transport=tcp
+ sips:alice@atlanta.com?subject=project%20x&priority=urgent
+ sip:+1-212-555-1212:1234@gateway.com;user=phone
+ sips:1212@gateway.com
+ sip:alice@192.0.2.4
+ sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
+ sip:alice;day=tuesday@atlanta.com
+
+ The last sample URI above has a user field value of
+ "alice;day=tuesday". The escaping rules defined above allow a
+ semicolon to appear unescaped in this field. For the purposes of
+ this protocol, the field is opaque. The structure of that value is
+ only useful to the SIP element responsible for the resource.
+
+19.1.4 URI Comparison
+
+ Some operations in this specification require determining whether two
+ SIP or SIPS URIs are equivalent. In this specification, registrars
+ need to compare bindings in Contact URIs in REGISTER requests (see
+ Section 10.3.). SIP and SIPS URIs are compared for equality
+ according to the following rules:
+
+ o A SIP and SIPS URI are never equivalent.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 153]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o Comparison of the userinfo of SIP and SIPS URIs is case-
+ sensitive. This includes userinfo containing passwords or
+ formatted as telephone-subscribers. Comparison of all other
+ components of the URI is case-insensitive unless explicitly
+ defined otherwise.
+
+ o The ordering of parameters and header fields is not significant
+ in comparing SIP and SIPS URIs.
+
+ o Characters other than those in the "reserved" set (see RFC 2396
+ [5]) are equivalent to their ""%" HEX HEX" encoding.
+
+ o An IP address that is the result of a DNS lookup of a host name
+ does not match that host name.
+
+ o For two URIs to be equal, the user, password, host, and port
+ components must match.
+
+ A URI omitting the user component will not match a URI that
+ includes one. A URI omitting the password component will not
+ match a URI that includes one.
+
+ A URI omitting any component with a default value will not
+ match a URI explicitly containing that component with its
+ default value. For instance, a URI omitting the optional port
+ component will not match a URI explicitly declaring port 5060.
+ The same is true for the transport-parameter, ttl-parameter,
+ user-parameter, and method components.
+
+ Defining sip:user@host to not be equivalent to
+ sip:user@host:5060 is a change from RFC 2543. When deriving
+ addresses from URIs, equivalent addresses are expected from
+ equivalent URIs. The URI sip:user@host:5060 will always
+ resolve to port 5060. The URI sip:user@host may resolve to
+ other ports through the DNS SRV mechanisms detailed in [4].
+
+ o URI uri-parameter components are compared as follows:
+
+ - Any uri-parameter appearing in both URIs must match.
+
+ - A user, ttl, or method uri-parameter appearing in only one
+ URI never matches, even if it contains the default value.
+
+ - A URI that includes an maddr parameter will not match a URI
+ that contains no maddr parameter.
+
+ - All other uri-parameters appearing in only one URI are
+ ignored when comparing the URIs.
+
+
+
+Rosenberg, et. al. Standards Track [Page 154]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o URI header components are never ignored. Any present header
+ component MUST be present in both URIs and match for the URIs
+ to match. The matching rules are defined for each header field
+ in Section 20.
+
+ The URIs within each of the following sets are equivalent:
+
+ sip:%61lice@atlanta.com;transport=TCP
+ sip:alice@AtLanTa.CoM;Transport=tcp
+
+ sip:carol@chicago.com
+ sip:carol@chicago.com;newparam=5
+ sip:carol@chicago.com;security=on
+
+ sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
+ sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
+
+ sip:alice@atlanta.com?subject=project%20x&priority=urgent
+ sip:alice@atlanta.com?priority=urgent&subject=project%20x
+
+ The URIs within each of the following sets are not equivalent:
+
+ SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames)
+ sip:alice@AtLanTa.CoM;Transport=UDP
+
+ sip:bob@biloxi.com (can resolve to different ports)
+ sip:bob@biloxi.com:5060
+
+ sip:bob@biloxi.com (can resolve to different transports)
+ sip:bob@biloxi.com;transport=udp
+
+ sip:bob@biloxi.com (can resolve to different port and transports)
+ sip:bob@biloxi.com:6000;transport=tcp
+
+ sip:carol@chicago.com (different header component)
+ sip:carol@chicago.com?Subject=next%20meeting
+
+ sip:bob@phone21.boxesbybob.com (even though that's what
+ sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to)
+
+ Note that equality is not transitive:
+
+ o sip:carol@chicago.com and sip:carol@chicago.com;security=on are
+ equivalent
+
+ o sip:carol@chicago.com and sip:carol@chicago.com;security=off
+ are equivalent
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 155]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o sip:carol@chicago.com;security=on and
+ sip:carol@chicago.com;security=off are not equivalent
+
+19.1.5 Forming Requests from a URI
+
+ An implementation needs to take care when forming requests directly
+ from a URI. URIs from business cards, web pages, and even from
+ sources inside the protocol such as registered contacts may contain
+ inappropriate header fields or body parts.
+
+ An implementation MUST include any provided transport, maddr, ttl, or
+ user parameter in the Request-URI of the formed request. If the URI
+ contains a method parameter, its value MUST be used as the method of
+ the request. The method parameter MUST NOT be placed in the
+ Request-URI. Unknown URI parameters MUST be placed in the message's
+ Request-URI.
+
+ An implementation SHOULD treat the presence of any headers or body
+ parts in the URI as a desire to include them in the message, and
+ choose to honor the request on a per-component basis.
+
+ An implementation SHOULD NOT honor these obviously dangerous header
+ fields: From, Call-ID, CSeq, Via, and Record-Route.
+
+ An implementation SHOULD NOT honor any requested Route header field
+ values in order to not be used as an unwitting agent in malicious
+ attacks.
+
+ An implementation SHOULD NOT honor requests to include header fields
+ that may cause it to falsely advertise its location or capabilities.
+ These include: Accept, Accept-Encoding, Accept-Language, Allow,
+ Contact (in its dialog usage), Organization, Supported, and User-
+ Agent.
+
+ An implementation SHOULD verify the accuracy of any requested
+ descriptive header fields, including: Content-Disposition, Content-
+ Encoding, Content-Language, Content-Length, Content-Type, Date,
+ Mime-Version, and Timestamp.
+
+ If the request formed from constructing a message from a given URI is
+ not a valid SIP request, the URI is invalid. An implementation MUST
+ NOT proceed with transmitting the request. It should instead pursue
+ the course of action due an invalid URI in the context it occurs.
+
+ The constructed request can be invalid in many ways. These
+ include, but are not limited to, syntax error in header fields,
+ invalid combinations of URI parameters, or an incorrect
+ description of the message body.
+
+
+
+Rosenberg, et. al. Standards Track [Page 156]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Sending a request formed from a given URI may require capabilities
+ unavailable to the implementation. The URI might indicate use of an
+ unimplemented transport or extension, for example. An implementation
+ SHOULD refuse to send these requests rather than modifying them to
+ match their capabilities. An implementation MUST NOT send a request
+ requiring an extension that it does not support.
+
+ For example, such a request can be formed through the presence of
+ a Require header parameter or a method URI parameter with an
+ unknown or explicitly unsupported value.
+
+19.1.6 Relating SIP URIs and tel URLs
+
+ When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the
+ entire telephone-subscriber portion of the tel URL, including any
+ parameters, is placed into the userinfo part of the SIP or SIPS URI.
+
+ Thus, tel:+358-555-1234567;postd=pp22 becomes
+
+ sip:+358-555-1234567;postd=pp22@foo.com;user=phone
+
+ or
+ sips:+358-555-1234567;postd=pp22@foo.com;user=phone
+
+ not
+ sip:+358-555-1234567@foo.com;postd=pp22;user=phone
+
+ or
+
+ sips:+358-555-1234567@foo.com;postd=pp22;user=phone
+
+ In general, equivalent "tel" URLs converted to SIP or SIPS URIs in
+ this fashion may not produce equivalent SIP or SIPS URIs. The
+ userinfo of SIP and SIPS URIs are compared as a case-sensitive
+ string. Variance in case-insensitive portions of tel URLs and
+ reordering of tel URL parameters does not affect tel URL equivalence,
+ but does affect the equivalence of SIP URIs formed from them.
+
+ For example,
+
+ tel:+358-555-1234567;postd=pp22
+ tel:+358-555-1234567;POSTD=PP22
+
+ are equivalent, while
+
+ sip:+358-555-1234567;postd=pp22@foo.com;user=phone
+ sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 157]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ are not.
+
+ Likewise,
+
+ tel:+358-555-1234567;postd=pp22;isub=1411
+ tel:+358-555-1234567;isub=1411;postd=pp22
+
+ are equivalent, while
+
+ sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
+ sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone
+
+ are not.
+
+ To mitigate this problem, elements constructing telephone-subscriber
+ fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold
+ any case-insensitive portion of telephone-subscriber to lower case,
+ and order the telephone-subscriber parameters lexically by parameter
+ name, excepting isdn-subaddress and post-dial, which occur first and
+ in that order. (All components of a tel URL except for future-
+ extension parameters are defined to be compared case-insensitive.)
+
+ Following this suggestion, both
+
+ tel:+358-555-1234567;postd=pp22
+ tel:+358-555-1234567;POSTD=PP22
+
+ become
+
+ sip:+358-555-1234567;postd=pp22@foo.com;user=phone
+
+ and both
+
+ tel:+358-555-1234567;tsp=a.b;phone-context=5
+ tel:+358-555-1234567;phone-context=5;tsp=a.b
+
+ become
+
+ sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone
+
+19.2 Option Tags
+
+ Option tags are unique identifiers used to designate new options
+ (extensions) in SIP. These tags are used in Require (Section 20.32),
+ Proxy-Require (Section 20.29), Supported (Section 20.37) and
+ Unsupported (Section 20.40) header fields. Note that these options
+ appear as parameters in those header fields in an option-tag = token
+ form (see Section 25 for the definition of token).
+
+
+
+Rosenberg, et. al. Standards Track [Page 158]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Option tags are defined in standards track RFCs. This is a change
+ from past practice, and is instituted to ensure continuing multi-
+ vendor interoperability (see discussion in Section 20.32 and Section
+ 20.37). An IANA registry of option tags is used to ensure easy
+ reference.
+
+19.3 Tags
+
+ The "tag" parameter is used in the To and From header fields of SIP
+ messages. It serves as a general mechanism to identify a dialog,
+ which is the combination of the Call-ID along with two tags, one from
+ each participant in the dialog. When a UA sends a request outside of
+ a dialog, it contains a From tag only, providing "half" of the dialog
+ ID. The dialog is completed from the response(s), each of which
+ contributes the second half in the To header field. The forking of
+ SIP requests means that multiple dialogs can be established from a
+ single request. This also explains the need for the two-sided dialog
+ identifier; without a contribution from the recipients, the
+ originator could not disambiguate the multiple dialogs established
+ from a single request.
+
+ When a tag is generated by a UA for insertion into a request or
+ response, it MUST be globally unique and cryptographically random
+ with at least 32 bits of randomness. A property of this selection
+ requirement is that a UA will place a different tag into the From
+ header of an INVITE than it would place into the To header of the
+ response to the same INVITE. This is needed in order for a UA to
+ invite itself to a session, a common case for "hairpinning" of calls
+ in PSTN gateways. Similarly, two INVITEs for different calls will
+ have different From tags, and two responses for different calls will
+ have different To tags.
+
+ Besides the requirement for global uniqueness, the algorithm for
+ generating a tag is implementation-specific. Tags are helpful in
+ fault tolerant systems, where a dialog is to be recovered on an
+ alternate server after a failure. A UAS can select the tag in such a
+ way that a backup can recognize a request as part of a dialog on the
+ failed server, and therefore determine that it should attempt to
+ recover the dialog and any other state associated with it.
+
+20 Header Fields
+
+ The general syntax for header fields is covered in Section 7.3. This
+ section lists the full set of header fields along with notes on
+ syntax, meaning, and usage. Throughout this section, we use [HX.Y]
+ to refer to Section X.Y of the current HTTP/1.1 specification RFC
+ 2616 [8]. Examples of each header field are given.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 159]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Information about header fields in relation to methods and proxy
+ processing is summarized in Tables 2 and 3.
+
+ The "where" column describes the request and response types in which
+ the header field can be used. Values in this column are:
+
+ R: header field may only appear in requests;
+
+ r: header field may only appear in responses;
+
+ 2xx, 4xx, etc.: A numerical value or range indicates response
+ codes with which the header field can be used;
+
+ c: header field is copied from the request to the response.
+
+ An empty entry in the "where" column indicates that the header
+ field may be present in all requests and responses.
+
+ The "proxy" column describes the operations a proxy may perform on a
+ header field:
+
+ a: A proxy can add or concatenate the header field if not present.
+
+ m: A proxy can modify an existing header field value.
+
+ d: A proxy can delete a header field value.
+
+ r: A proxy must be able to read the header field, and thus this
+ header field cannot be encrypted.
+
+ The next six columns relate to the presence of a header field in a
+ method:
+
+ c: Conditional; requirements on the header field depend on the
+ context of the message.
+
+ m: The header field is mandatory.
+
+ m*: The header field SHOULD be sent, but clients/servers need to
+ be prepared to receive messages without that header field.
+
+ o: The header field is optional.
+
+ t: The header field SHOULD be sent, but clients/servers need to be
+ prepared to receive messages without that header field.
+
+ If a stream-based protocol (such as TCP) is used as a
+ transport, then the header field MUST be sent.
+
+
+
+Rosenberg, et. al. Standards Track [Page 160]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ *: The header field is required if the message body is not empty.
+ See Sections 20.14, 20.15 and 7.4 for details.
+
+ -: The header field is not applicable.
+
+ "Optional" means that an element MAY include the header field in a
+ request or response, and a UA MAY ignore the header field if present
+ in the request or response (The exception to this rule is the Require
+ header field discussed in 20.32). A "mandatory" header field MUST be
+ present in a request, and MUST be understood by the UAS receiving the
+ request. A mandatory response header field MUST be present in the
+ response, and the header field MUST be understood by the UAC
+ processing the response. "Not applicable" means that the header
+ field MUST NOT be present in a request. If one is placed in a
+ request by mistake, it MUST be ignored by the UAS receiving the
+ request. Similarly, a header field labeled "not applicable" for a
+ response means that the UAS MUST NOT place the header field in the
+ response, and the UAC MUST ignore the header field in the response.
+
+ A UA SHOULD ignore extension header parameters that are not
+ understood.
+
+ A compact form of some common header field names is also defined for
+ use when overall message size is an issue.
+
+ The Contact, From, and To header fields contain a URI. If the URI
+ contains a comma, question mark or semicolon, the URI MUST be
+ enclosed in angle brackets (< and >). Any URI parameters are
+ contained within these brackets. If the URI is not enclosed in angle
+ brackets, any semicolon-delimited parameters are header-parameters,
+ not URI parameters.
+
+20.1 Accept
+
+ The Accept header field follows the syntax defined in [H14.1]. The
+ semantics are also identical, with the exception that if no Accept
+ header field is present, the server SHOULD assume a default value of
+ application/sdp.
+
+ An empty Accept header field means that no formats are acceptable.
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 161]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Example:
+
+ Header field where proxy ACK BYE CAN INV OPT REG
+ ___________________________________________________________
+ Accept R - o - o m* o
+ Accept 2xx - - - o m* o
+ Accept 415 - c - c c c
+ Accept-Encoding R - o - o o o
+ Accept-Encoding 2xx - - - o m* o
+ Accept-Encoding 415 - c - c c c
+ Accept-Language R - o - o o o
+ Accept-Language 2xx - - - o m* o
+ Accept-Language 415 - c - c c c
+ Alert-Info R ar - - - o - -
+ Alert-Info 180 ar - - - o - -
+ Allow R - o - o o o
+ Allow 2xx - o - m* m* o
+ Allow r - o - o o o
+ Allow 405 - m - m m m
+ Authentication-Info 2xx - o - o o o
+ Authorization R o o o o o o
+ Call-ID c r m m m m m m
+ Call-Info ar - - - o o o
+ Contact R o - - m o o
+ Contact 1xx - - - o - -
+ Contact 2xx - - - m o o
+ Contact 3xx d - o - o o o
+ Contact 485 - o - o o o
+ Content-Disposition o o - o o o
+ Content-Encoding o o - o o o
+ Content-Language o o - o o o
+ Content-Length ar t t t t t t
+ Content-Type * * - * * *
+ CSeq c r m m m m m m
+ Date a o o o o o o
+ Error-Info 300-699 a - o o o o o
+ Expires - - - o - o
+ From c r m m m m m m
+ In-Reply-To R - - - o - -
+ Max-Forwards R amr m m m m m m
+ Min-Expires 423 - - - - - m
+ MIME-Version o o - o o o
+ Organization ar - - - o o o
+
+ Table 2: Summary of header fields, A--O
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 162]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Header field where proxy ACK BYE CAN INV OPT REG
+ ___________________________________________________________________
+ Priority R ar - - - o - -
+ Proxy-Authenticate 407 ar - m - m m m
+ Proxy-Authenticate 401 ar - o o o o o
+ Proxy-Authorization R dr o o - o o o
+ Proxy-Require R ar - o - o o o
+ Record-Route R ar o o o o o -
+ Record-Route 2xx,18x mr - o o o o -
+ Reply-To - - - o - -
+ Require ar - c - c c c
+ Retry-After 404,413,480,486 - o o o o o
+ 500,503 - o o o o o
+ 600,603 - o o o o o
+ Route R adr c c c c c c
+ Server r - o o o o o
+ Subject R - - - o - -
+ Supported R - o o m* o o
+ Supported 2xx - o o m* m* o
+ Timestamp o o o o o o
+ To c(1) r m m m m m m
+ Unsupported 420 - m - m m m
+ User-Agent o o o o o o
+ Via R amr m m m m m m
+ Via rc dr m m m m m m
+ Warning r - o o o o o
+ WWW-Authenticate 401 ar - m - m m m
+ WWW-Authenticate 407 ar - o - o o o
+
+ Table 3: Summary of header fields, P--Z; (1): copied with possible
+ addition of tag
+
+ Accept: application/sdp;level=1, application/x-private, text/html
+
+20.2 Accept-Encoding
+
+ The Accept-Encoding header field is similar to Accept, but restricts
+ the content-codings [H3.5] that are acceptable in the response. See
+ [H14.3]. The semantics in SIP are identical to those defined in
+ [H14.3].
+
+ An empty Accept-Encoding header field is permissible. It is
+ equivalent to Accept-Encoding: identity, that is, only the identity
+ encoding, meaning no encoding, is permissible.
+
+ If no Accept-Encoding header field is present, the server SHOULD
+ assume a default value of identity.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 163]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ This differs slightly from the HTTP definition, which indicates that
+ when not present, any encoding can be used, but the identity encoding
+ is preferred.
+
+ Example:
+
+ Accept-Encoding: gzip
+
+20.3 Accept-Language
+
+ The Accept-Language header field is used in requests to indicate the
+ preferred languages for reason phrases, session descriptions, or
+ status responses carried as message bodies in the response. If no
+ Accept-Language header field is present, the server SHOULD assume all
+ languages are acceptable to the client.
+
+ The Accept-Language header field follows the syntax defined in
+ [H14.4]. The rules for ordering the languages based on the "q"
+ parameter apply to SIP as well.
+
+ Example:
+
+ Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+20.4 Alert-Info
+
+ When present in an INVITE request, the Alert-Info header field
+ specifies an alternative ring tone to the UAS. When present in a 180
+ (Ringing) response, the Alert-Info header field specifies an
+ alternative ringback tone to the UAC. A typical usage is for a proxy
+ to insert this header field to provide a distinctive ring feature.
+
+ The Alert-Info header field can introduce security risks. These
+ risks and the ways to handle them are discussed in Section 20.9,
+ which discusses the Call-Info header field since the risks are
+ identical.
+
+ In addition, a user SHOULD be able to disable this feature
+ selectively.
+
+ This helps prevent disruptions that could result from the use of
+ this header field by untrusted elements.
+
+ Example:
+
+ Alert-Info: <http://www.example.com/sounds/moo.wav>
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 164]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+20.5 Allow
+
+ The Allow header field lists the set of methods supported by the UA
+ generating the message.
+
+ All methods, including ACK and CANCEL, understood by the UA MUST be
+ included in the list of methods in the Allow header field, when
+ present. The absence of an Allow header field MUST NOT be
+ interpreted to mean that the UA sending the message supports no
+ methods. Rather, it implies that the UA is not providing any
+ information on what methods it supports.
+
+ Supplying an Allow header field in responses to methods other than
+ OPTIONS reduces the number of messages needed.
+
+ Example:
+
+ Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
+
+20.6 Authentication-Info
+
+ The Authentication-Info header field provides for mutual
+ authentication with HTTP Digest. A UAS MAY include this header field
+ in a 2xx response to a request that was successfully authenticated
+ using digest based on the Authorization header field.
+
+ Syntax and semantics follow those specified in RFC 2617 [17].
+
+ Example:
+
+ Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
+
+20.7 Authorization
+
+ The Authorization header field contains authentication credentials of
+ a UA. Section 22.2 overviews the use of the Authorization header
+ field, and Section 22.4 describes the syntax and semantics when used
+ with HTTP authentication.
+
+ This header field, along with Proxy-Authorization, breaks the general
+ rules about multiple header field values. Although not a comma-
+ separated list, this header field name may be present multiple times,
+ and MUST NOT be combined into a single header line using the usual
+ rules described in Section 7.3.
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 165]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ In the example below, there are no quotes around the Digest
+ parameter:
+
+ Authorization: Digest username="Alice", realm="atlanta.com",
+ nonce="84a4cc6f3082121f32b42a2187831a9e",
+ response="7587245234b3434cc3412213e5f113a5432"
+
+20.8 Call-ID
+
+ The Call-ID header field uniquely identifies a particular invitation
+ or all registrations of a particular client. A single multimedia
+ conference can give rise to several calls with different Call-IDs,
+ for example, if a user invites a single individual several times to
+ the same (long-running) conference. Call-IDs are case-sensitive and
+ are simply compared byte-by-byte.
+
+ The compact form of the Call-ID header field is i.
+
+ Examples:
+
+ Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
+ i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
+
+20.9 Call-Info
+
+ The Call-Info header field provides additional information about the
+ caller or callee, depending on whether it is found in a request or
+ response. The purpose of the URI is described by the "purpose"
+ parameter. The "icon" parameter designates an image suitable as an
+ iconic representation of the caller or callee. The "info" parameter
+ describes the caller or callee in general, for example, through a web
+ page. The "card" parameter provides a business card, for example, in
+ vCard [36] or LDIF [37] formats. Additional tokens can be registered
+ using IANA and the procedures in Section 27.
+
+ Use of the Call-Info header field can pose a security risk. If a
+ callee fetches the URIs provided by a malicious caller, the callee
+ may be at risk for displaying inappropriate or offensive content,
+ dangerous or illegal content, and so on. Therefore, it is
+ RECOMMENDED that a UA only render the information in the Call-Info
+ header field if it can verify the authenticity of the element that
+ originated the header field and trusts that element. This need not
+ be the peer UA; a proxy can insert this header field into requests.
+
+ Example:
+
+ Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
+ <http://www.example.com/alice/> ;purpose=info
+
+
+
+Rosenberg, et. al. Standards Track [Page 166]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+20.10 Contact
+
+ A Contact header field value provides a URI whose meaning depends on
+ the type of request or response it is in.
+
+ A Contact header field value can contain a display name, a URI with
+ URI parameters, and header parameters.
+
+ This document defines the Contact parameters "q" and "expires".
+ These parameters are only used when the Contact is present in a
+ REGISTER request or response, or in a 3xx response. Additional
+ parameters may be defined in other specifications.
+
+ When the header field value contains a display name, the URI
+ including all URI parameters is enclosed in "<" and ">". If no "<"
+ and ">" are present, all parameters after the URI are header
+ parameters, not URI parameters. The display name can be tokens, or a
+ quoted string, if a larger character set is desired.
+
+ Even if the "display-name" is empty, the "name-addr" form MUST be
+ used if the "addr-spec" contains a comma, semicolon, or question
+ mark. There may or may not be LWS between the display-name and the
+ "<".
+
+ These rules for parsing a display name, URI and URI parameters, and
+ header parameters also apply for the header fields To and From.
+
+ The Contact header field has a role similar to the Location header
+ field in HTTP. However, the HTTP header field only allows one
+ address, unquoted. Since URIs can contain commas and semicolons
+ as reserved characters, they can be mistaken for header or
+ parameter delimiters, respectively.
+
+ The compact form of the Contact header field is m (for "moved").
+
+ Examples:
+
+ Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
+ ;q=0.7; expires=3600,
+ "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
+ m: <sips:bob@192.0.2.4>;expires=60
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 167]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+20.11 Content-Disposition
+
+ The Content-Disposition header field describes how the message body
+ or, for multipart messages, a message body part is to be interpreted
+ by the UAC or UAS. This SIP header field extends the MIME Content-
+ Type (RFC 2183 [18]).
+
+ Several new "disposition-types" of the Content-Disposition header are
+ defined by SIP. The value "session" indicates that the body part
+ describes a session, for either calls or early (pre-call) media. The
+ value "render" indicates that the body part should be displayed or
+ otherwise rendered to the user. Note that the value "render" is used
+ rather than "inline" to avoid the connotation that the MIME body is
+ displayed as a part of the rendering of the entire message (since the
+ MIME bodies of SIP messages oftentimes are not displayed to users).
+ For backward-compatibility, if the Content-Disposition header field
+ is missing, the server SHOULD assume bodies of Content-Type
+ application/sdp are the disposition "session", while other content
+ types are "render".
+
+ The disposition type "icon" indicates that the body part contains an
+ image suitable as an iconic representation of the caller or callee
+ that could be rendered informationally by a user agent when a message
+ has been received, or persistently while a dialog takes place. The
+ value "alert" indicates that the body part contains information, such
+ as an audio clip, that should be rendered by the user agent in an
+ attempt to alert the user to the receipt of a request, generally a
+ request that initiates a dialog; this alerting body could for example
+ be rendered as a ring tone for a phone call after a 180 Ringing
+ provisional response has been sent.
+
+ Any MIME body with a "disposition-type" that renders content to the
+ user should only be processed when a message has been properly
+ authenticated.
+
+ The handling parameter, handling-param, describes how the UAS should
+ react if it receives a message body whose content type or disposition
+ type it does not understand. The parameter has defined values of
+ "optional" and "required". If the handling parameter is missing, the
+ value "required" SHOULD be assumed. The handling parameter is
+ described in RFC 3204 [19].
+
+ If this header field is missing, the MIME type determines the default
+ content disposition. If there is none, "render" is assumed.
+
+ Example:
+
+ Content-Disposition: session
+
+
+
+Rosenberg, et. al. Standards Track [Page 168]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+20.12 Content-Encoding
+
+ The Content-Encoding header field is used as a modifier to the
+ "media-type". When present, its value indicates what additional
+ content codings have been applied to the entity-body, and thus what
+ decoding mechanisms MUST be applied in order to obtain the media-type
+ referenced by the Content-Type header field. Content-Encoding is
+ primarily used to allow a body to be compressed without losing the
+ identity of its underlying media type.
+
+ If multiple encodings have been applied to an entity-body, the
+ content codings MUST be listed in the order in which they were
+ applied.
+
+ All content-coding values are case-insensitive. IANA acts as a
+ registry for content-coding value tokens. See [H3.5] for a
+ definition of the syntax for content-coding.
+
+ Clients MAY apply content encodings to the body in requests. A
+ server MAY apply content encodings to the bodies in responses. The
+ server MUST only use encodings listed in the Accept-Encoding header
+ field in the request.
+
+ The compact form of the Content-Encoding header field is e.
+ Examples:
+
+ Content-Encoding: gzip
+ e: tar
+
+20.13 Content-Language
+
+ See [H14.12]. Example:
+
+ Content-Language: fr
+
+20.14 Content-Length
+
+ The Content-Length header field indicates the size of the message-
+ body, in decimal number of octets, sent to the recipient.
+ Applications SHOULD use this field to indicate the size of the
+ message-body to be transferred, regardless of the media type of the
+ entity. If a stream-based protocol (such as TCP) is used as
+ transport, the header field MUST be used.
+
+ The size of the message-body does not include the CRLF separating
+ header fields and body. Any Content-Length greater than or equal to
+ zero is a valid value. If no body is present in a message, then the
+ Content-Length header field value MUST be set to zero.
+
+
+
+Rosenberg, et. al. Standards Track [Page 169]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The ability to omit Content-Length simplifies the creation of
+ cgi-like scripts that dynamically generate responses.
+
+ The compact form of the header field is l.
+
+ Examples:
+
+ Content-Length: 349
+ l: 173
+
+20.15 Content-Type
+
+ The Content-Type header field indicates the media type of the
+ message-body sent to the recipient. The "media-type" element is
+ defined in [H3.7]. The Content-Type header field MUST be present if
+ the body is not empty. If the body is empty, and a Content-Type
+ header field is present, it indicates that the body of the specific
+ type has zero length (for example, an empty audio file).
+
+ The compact form of the header field is c.
+
+ Examples:
+
+ Content-Type: application/sdp
+ c: text/html; charset=ISO-8859-4
+
+20.16 CSeq
+
+ A CSeq header field in a request contains a single decimal sequence
+ number and the request method. The sequence number MUST be
+ expressible as a 32-bit unsigned integer. The method part of CSeq is
+ case-sensitive. The CSeq header field serves to order transactions
+ within a dialog, to provide a means to uniquely identify
+ transactions, and to differentiate between new requests and request
+ retransmissions. Two CSeq header fields are considered equal if the
+ sequence number and the request method are identical. Example:
+
+ CSeq: 4711 INVITE
+
+20.17 Date
+
+ The Date header field contains the date and time. Unlike HTTP/1.1,
+ SIP only supports the most recent RFC 1123 [20] format for dates. As
+ in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while
+ RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive.
+
+ The Date header field reflects the time when the request or response
+ is first sent.
+
+
+
+Rosenberg, et. al. Standards Track [Page 170]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The Date header field can be used by simple end systems without a
+ battery-backed clock to acquire a notion of current time.
+ However, in its GMT form, it requires clients to know their offset
+ from GMT.
+
+ Example:
+
+ Date: Sat, 13 Nov 2010 23:29:00 GMT
+
+20.18 Error-Info
+
+ The Error-Info header field provides a pointer to additional
+ information about the error status response.
+
+ SIP UACs have user interface capabilities ranging from pop-up
+ windows and audio on PC softclients to audio-only on "black"
+ phones or endpoints connected via gateways. Rather than forcing a
+ server generating an error to choose between sending an error
+ status code with a detailed reason phrase and playing an audio
+ recording, the Error-Info header field allows both to be sent.
+ The UAC then has the choice of which error indicator to render to
+ the caller.
+
+ A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if
+ it were a Contact in a redirect and generate a new INVITE, resulting
+ in a recorded announcement session being established. A non-SIP URI
+ MAY be rendered to the user.
+
+ Examples:
+
+ SIP/2.0 404 The number you have dialed is not in service
+ Error-Info: <sip:not-in-service-recording@atlanta.com>
+
+20.19 Expires
+
+ The Expires header field gives the relative time after which the
+ message (or content) expires.
+
+ The precise meaning of this is method dependent.
+
+ The expiration time in an INVITE does not affect the duration of the
+ actual session that may result from the invitation. Session
+ description protocols may offer the ability to express time limits on
+ the session duration, however.
+
+ The value of this field is an integral number of seconds (in decimal)
+ between 0 and (2**32)-1, measured from the receipt of the request.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 171]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Example:
+
+ Expires: 5
+
+20.20 From
+
+ The From header field indicates the initiator of the request. This
+ may be different from the initiator of the dialog. Requests sent by
+ the callee to the caller use the callee's address in the From header
+ field.
+
+ The optional "display-name" is meant to be rendered by a human user
+ interface. A system SHOULD use the display name "Anonymous" if the
+ identity of the client is to remain hidden. Even if the "display-
+ name" is empty, the "name-addr" form MUST be used if the "addr-spec"
+ contains a comma, question mark, or semicolon. Syntax issues are
+ discussed in Section 7.3.1.
+
+ Two From header fields are equivalent if their URIs match, and their
+ parameters match. Extension parameters in one header field, not
+ present in the other are ignored for the purposes of comparison. This
+ means that the display name and presence or absence of angle brackets
+ do not affect matching.
+
+ See Section 20.10 for the rules for parsing a display name, URI and
+ URI parameters, and header field parameters.
+
+ The compact form of the From header field is f.
+
+ Examples:
+
+ From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
+ From: sip:+12125551212@server.phone2net.com;tag=887s
+ f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
+
+20.21 In-Reply-To
+
+ The In-Reply-To header field enumerates the Call-IDs that this call
+ references or returns. These Call-IDs may have been cached by the
+ client then included in this header field in a return call.
+
+ This allows automatic call distribution systems to route return
+ calls to the originator of the first call. This also allows
+ callees to filter calls, so that only return calls for calls they
+ originated will be accepted. This field is not a substitute for
+ request authentication.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 172]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Example:
+
+ In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
+
+20.22 Max-Forwards
+
+ The Max-Forwards header field must be used with any SIP method to
+ limit the number of proxies or gateways that can forward the request
+ to the next downstream server. This can also be useful when the
+ client is attempting to trace a request chain that appears to be
+ failing or looping in mid-chain.
+
+ The Max-Forwards value is an integer in the range 0-255 indicating
+ the remaining number of times this request message is allowed to be
+ forwarded. This count is decremented by each server that forwards
+ the request. The recommended initial value is 70.
+
+ This header field should be inserted by elements that can not
+ otherwise guarantee loop detection. For example, a B2BUA should
+ insert a Max-Forwards header field.
+
+ Example:
+
+ Max-Forwards: 6
+
+20.23 Min-Expires
+
+ The Min-Expires header field conveys the minimum refresh interval
+ supported for soft-state elements managed by that server. This
+ includes Contact header fields that are stored by a registrar. The
+ header field contains a decimal integer number of seconds from 0 to
+ (2**32)-1. The use of the header field in a 423 (Interval Too Brief)
+ response is described in Sections 10.2.8, 10.3, and 21.4.17.
+
+ Example:
+
+ Min-Expires: 60
+
+20.24 MIME-Version
+
+ See [H19.4.1].
+
+ Example:
+
+ MIME-Version: 1.0
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 173]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+20.25 Organization
+
+ The Organization header field conveys the name of the organization to
+ which the SIP element issuing the request or response belongs.
+
+ The field MAY be used by client software to filter calls.
+
+ Example:
+
+ Organization: Boxes by Bob
+
+20.26 Priority
+
+ The Priority header field indicates the urgency of the request as
+ perceived by the client. The Priority header field describes the
+ priority that the SIP request should have to the receiving human or
+ its agent. For example, it may be factored into decisions about call
+ routing and acceptance. For these decisions, a message containing no
+ Priority header field SHOULD be treated as if it specified a Priority
+ of "normal". The Priority header field does not influence the use of
+ communications resources such as packet forwarding priority in
+ routers or access to circuits in PSTN gateways. The header field can
+ have the values "non-urgent", "normal", "urgent", and "emergency",
+ but additional values can be defined elsewhere. It is RECOMMENDED
+ that the value of "emergency" only be used when life, limb, or
+ property are in imminent danger. Otherwise, there are no semantics
+ defined for this header field.
+
+ These are the values of RFC 2076 [38], with the addition of
+ "emergency".
+
+ Examples:
+
+ Subject: A tornado is heading our way!
+ Priority: emergency
+
+ or
+
+ Subject: Weekend plans
+ Priority: non-urgent
+
+20.27 Proxy-Authenticate
+
+ A Proxy-Authenticate header field value contains an authentication
+ challenge.
+
+ The use of this header field is defined in [H14.33]. See Section
+ 22.3 for further details on its usage.
+
+
+
+Rosenberg, et. al. Standards Track [Page 174]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Example:
+
+ Proxy-Authenticate: Digest realm="atlanta.com",
+ domain="sip:ss1.carrier.com", qop="auth",
+ nonce="f84f1cec41e6cbe5aea9c8e88d359",
+ opaque="", stale=FALSE, algorithm=MD5
+
+20.28 Proxy-Authorization
+
+ The Proxy-Authorization header field allows the client to identify
+ itself (or its user) to a proxy that requires authentication. A
+ Proxy-Authorization field value consists of credentials containing
+ the authentication information of the user agent for the proxy and/or
+ realm of the resource being requested.
+
+ See Section 22.3 for a definition of the usage of this header field.
+
+ This header field, along with Authorization, breaks the general rules
+ about multiple header field names. Although not a comma-separated
+ list, this header field name may be present multiple times, and MUST
+ NOT be combined into a single header line using the usual rules
+ described in Section 7.3.1.
+
+ Example:
+
+ Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
+ nonce="c60f3082ee1212b402a21831ae",
+ response="245f23415f11432b3434341c022"
+
+20.29 Proxy-Require
+
+ The Proxy-Require header field is used to indicate proxy-sensitive
+ features that must be supported by the proxy. See Section 20.32 for
+ more details on the mechanics of this message and a usage example.
+
+ Example:
+
+ Proxy-Require: foo
+
+20.30 Record-Route
+
+ The Record-Route header field is inserted by proxies in a request to
+ force future requests in the dialog to be routed through the proxy.
+
+ Examples of its use with the Route header field are described in
+ Sections 16.12.1.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 175]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Example:
+
+ Record-Route: <sip:server10.biloxi.com;lr>,
+ <sip:bigbox3.site3.atlanta.com;lr>
+
+20.31 Reply-To
+
+ The Reply-To header field contains a logical return URI that may be
+ different from the From header field. For example, the URI MAY be
+ used to return missed calls or unestablished sessions. If the user
+ wished to remain anonymous, the header field SHOULD either be omitted
+ from the request or populated in such a way that does not reveal any
+ private information.
+
+ Even if the "display-name" is empty, the "name-addr" form MUST be
+ used if the "addr-spec" contains a comma, question mark, or
+ semicolon. Syntax issues are discussed in Section 7.3.1.
+
+ Example:
+
+ Reply-To: Bob <sip:bob@biloxi.com>
+
+20.32 Require
+
+ The Require header field is used by UACs to tell UASs about options
+ that the UAC expects the UAS to support in order to process the
+ request. Although an optional header field, the Require MUST NOT be
+ ignored if it is present.
+
+ The Require header field contains a list of option tags, described in
+ Section 19.2. Each option tag defines a SIP extension that MUST be
+ understood to process the request. Frequently, this is used to
+ indicate that a specific set of extension header fields need to be
+ understood. A UAC compliant to this specification MUST only include
+ option tags corresponding to standards-track RFCs.
+
+ Example:
+
+ Require: 100rel
+
+20.33 Retry-After
+
+ The Retry-After header field can be used with a 500 (Server Internal
+ Error) or 503 (Service Unavailable) response to indicate how long the
+ service is expected to be unavailable to the requesting client and
+ with a 404 (Not Found), 413 (Request Entity Too Large), 480
+ (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 176]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ (Decline) response to indicate when the called party anticipates
+ being available again. The value of this field is a positive integer
+ number of seconds (in decimal) after the time of the response.
+
+ An optional comment can be used to indicate additional information
+ about the time of callback. An optional "duration" parameter
+ indicates how long the called party will be reachable starting at the
+ initial time of availability. If no duration parameter is given, the
+ service is assumed to be available indefinitely.
+
+ Examples:
+
+ Retry-After: 18000;duration=3600
+ Retry-After: 120 (I'm in a meeting)
+
+20.34 Route
+
+ The Route header field is used to force routing for a request through
+ the listed set of proxies. Examples of the use of the Route header
+ field are in Section 16.12.1.
+
+ Example:
+
+ Route: <sip:bigbox3.site3.atlanta.com;lr>,
+ <sip:server10.biloxi.com;lr>
+
+20.35 Server
+
+ The Server header field contains information about the software used
+ by the UAS to handle the request.
+
+ Revealing the specific software version of the server might allow the
+ server to become more vulnerable to attacks against software that is
+ known to contain security holes. Implementers SHOULD make the Server
+ header field a configurable option.
+
+ Example:
+
+ Server: HomeServer v2
+
+20.36 Subject
+
+ The Subject header field provides a summary or indicates the nature
+ of the call, allowing call filtering without having to parse the
+ session description. The session description does not have to use
+ the same subject indication as the invitation.
+
+ The compact form of the Subject header field is s.
+
+
+
+Rosenberg, et. al. Standards Track [Page 177]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Example:
+
+ Subject: Need more boxes
+ s: Tech Support
+
+20.37 Supported
+
+ The Supported header field enumerates all the extensions supported by
+ the UAC or UAS.
+
+ The Supported header field contains a list of option tags, described
+ in Section 19.2, that are understood by the UAC or UAS. A UA
+ compliant to this specification MUST only include option tags
+ corresponding to standards-track RFCs. If empty, it means that no
+ extensions are supported.
+
+ The compact form of the Supported header field is k.
+
+ Example:
+
+ Supported: 100rel
+
+20.38 Timestamp
+
+ The Timestamp header field describes when the UAC sent the request to
+ the UAS.
+
+ See Section 8.2.6 for details on how to generate a response to a
+ request that contains the header field. Although there is no
+ normative behavior defined here that makes use of the header, it
+ allows for extensions or SIP applications to obtain RTT estimates.
+
+ Example:
+
+ Timestamp: 54
+
+20.39 To
+
+ The To header field specifies the logical recipient of the request.
+
+ The optional "display-name" is meant to be rendered by a human-user
+ interface. The "tag" parameter serves as a general mechanism for
+ dialog identification.
+
+ See Section 19.3 for details of the "tag" parameter.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 178]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Comparison of To header fields for equality is identical to
+ comparison of From header fields. See Section 20.10 for the rules
+ for parsing a display name, URI and URI parameters, and header field
+ parameters.
+
+ The compact form of the To header field is t.
+
+ The following are examples of valid To header fields:
+
+ To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
+ t: sip:+12125551212@server.phone2net.com
+
+20.40 Unsupported
+
+ The Unsupported header field lists the features not supported by the
+ UAS. See Section 20.32 for motivation.
+
+ Example:
+
+ Unsupported: foo
+
+20.41 User-Agent
+
+ The User-Agent header field contains information about the UAC
+ originating the request. The semantics of this header field are
+ defined in [H14.43].
+
+ Revealing the specific software version of the user agent might allow
+ the user agent to become more vulnerable to attacks against software
+ that is known to contain security holes. Implementers SHOULD make
+ the User-Agent header field a configurable option.
+
+ Example:
+
+ User-Agent: Softphone Beta1.5
+
+20.42 Via
+
+ The Via header field indicates the path taken by the request so far
+ and indicates the path that should be followed in routing responses.
+ The branch ID parameter in the Via header field values serves as a
+ transaction identifier, and is used by proxies to detect loops.
+
+ A Via header field value contains the transport protocol used to send
+ the message, the client's host name or network address, and possibly
+ the port number at which it wishes to receive responses. A Via
+ header field value can also contain parameters such as "maddr",
+ "ttl", "received", and "branch", whose meaning and use are described
+
+
+
+Rosenberg, et. al. Standards Track [Page 179]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ in other sections. For implementations compliant to this
+ specification, the value of the branch parameter MUST start with the
+ magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.
+
+ Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
+ "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the
+ protocol still indicates "SIP", and the transport protocol is TLS.
+
+Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
+Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
+ ;branch=z9hG4bK77asjd
+
+ The compact form of the Via header field is v.
+
+ In this example, the message originated from a multi-homed host with
+ two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong
+ as to which network interface would be used. Erlang.bell-
+ telephone.com noticed the mismatch and added a parameter to the
+ previous hop's Via header field value, containing the address that
+ the packet actually came from.
+
+ The host or network address and port number are not required to
+ follow the SIP URI syntax. Specifically, LWS on either side of the
+ ":" or "/" is allowed, as shown here:
+
+ Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
+ ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
+
+ Even though this specification mandates that the branch parameter be
+ present in all requests, the BNF for the header field indicates that
+ it is optional. This allows interoperation with RFC 2543 elements,
+ which did not have to insert the branch parameter.
+
+ Two Via header fields are equal if their sent-protocol and sent-by
+ fields are equal, both have the same set of parameters, and the
+ values of all parameters are equal.
+
+20.43 Warning
+
+ The Warning header field is used to carry additional information
+ about the status of a response. Warning header field values are sent
+ with responses and contain a three-digit warning code, host name, and
+ warning text.
+
+ The "warn-text" should be in a natural language that is most likely
+ to be intelligible to the human user receiving the response. This
+ decision can be based on any available knowledge, such as the
+ location of the user, the Accept-Language field in a request, or the
+
+
+
+Rosenberg, et. al. Standards Track [Page 180]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Content-Language field in a response. The default language is i-
+ default [21].
+
+ The currently-defined "warn-code"s are listed below, with a
+ recommended warn-text in English and a description of their meaning.
+ These warnings describe failures induced by the session description.
+ The first digit of warning codes beginning with "3" indicates
+ warnings specific to SIP. Warnings 300 through 329 are reserved for
+ indicating problems with keywords in the session description, 330
+ through 339 are warnings related to basic network services requested
+ in the session description, 370 through 379 are warnings related to
+ quantitative QoS parameters requested in the session description, and
+ 390 through 399 are miscellaneous warnings that do not fall into one
+ of the above categories.
+
+ 300 Incompatible network protocol: One or more network protocols
+ contained in the session description are not available.
+
+ 301 Incompatible network address formats: One or more network
+ address formats contained in the session description are not
+ available.
+
+ 302 Incompatible transport protocol: One or more transport
+ protocols described in the session description are not
+ available.
+
+ 303 Incompatible bandwidth units: One or more bandwidth
+ measurement units contained in the session description were
+ not understood.
+
+ 304 Media type not available: One or more media types contained in
+ the session description are not available.
+
+ 305 Incompatible media format: One or more media formats contained
+ in the session description are not available.
+
+ 306 Attribute not understood: One or more of the media attributes
+ in the session description are not supported.
+
+ 307 Session description parameter not understood: A parameter
+ other than those listed above was not understood.
+
+ 330 Multicast not available: The site where the user is located
+ does not support multicast.
+
+ 331 Unicast not available: The site where the user is located does
+ not support unicast communication (usually due to the presence
+ of a firewall).
+
+
+
+Rosenberg, et. al. Standards Track [Page 181]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ 370 Insufficient bandwidth: The bandwidth specified in the session
+ description or defined by the media exceeds that known to be
+ available.
+
+ 399 Miscellaneous warning: The warning text can include arbitrary
+ information to be presented to a human user or logged. A
+ system receiving this warning MUST NOT take any automated
+ action.
+
+ 1xx and 2xx have been taken by HTTP/1.1.
+
+ Additional "warn-code"s can be defined through IANA, as defined in
+ Section 27.2.
+
+ Examples:
+
+ Warning: 307 isi.edu "Session parameter 'foo' not understood"
+ Warning: 301 isi.edu "Incompatible network address type 'E.164'"
+
+20.44 WWW-Authenticate
+
+ A WWW-Authenticate header field value contains an authentication
+ challenge. See Section 22.2 for further details on its usage.
+
+ Example:
+
+ WWW-Authenticate: Digest realm="atlanta.com",
+ domain="sip:boxesbybob.com", qop="auth",
+ nonce="f84f1cec41e6cbe5aea9c8e88d359",
+ opaque="", stale=FALSE, algorithm=MD5
+
+21 Response Codes
+
+ The response codes are consistent with, and extend, HTTP/1.1 response
+ codes. Not all HTTP/1.1 response codes are appropriate, and only
+ those that are appropriate are given here. Other HTTP/1.1 response
+ codes SHOULD NOT be used. Also, SIP defines a new class, 6xx.
+
+21.1 Provisional 1xx
+
+ Provisional responses, also known as informational responses,
+ indicate that the server contacted is performing some further action
+ and does not yet have a definitive response. A server sends a 1xx
+ response if it expects to take more than 200 ms to obtain a final
+ response. Note that 1xx responses are not transmitted reliably.
+ They never cause the client to send an ACK. Provisional (1xx)
+ responses MAY contain message bodies, including session descriptions.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 182]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.1.1 100 Trying
+
+ This response indicates that the request has been received by the
+ next-hop server and that some unspecified action is being taken on
+ behalf of this call (for example, a database is being consulted).
+ This response, like all other provisional responses, stops
+ retransmissions of an INVITE by a UAC. The 100 (Trying) response is
+ different from other provisional responses, in that it is never
+ forwarded upstream by a stateful proxy.
+
+21.1.2 180 Ringing
+
+ The UA receiving the INVITE is trying to alert the user. This
+ response MAY be used to initiate local ringback.
+
+21.1.3 181 Call Is Being Forwarded
+
+ A server MAY use this status code to indicate that the call is being
+ forwarded to a different set of destinations.
+
+21.1.4 182 Queued
+
+ The called party is temporarily unavailable, but the server has
+ decided to queue the call rather than reject it. When the callee
+ becomes available, it will return the appropriate final status
+ response. The reason phrase MAY give further details about the
+ status of the call, for example, "5 calls queued; expected waiting
+ time is 15 minutes". The server MAY issue several 182 (Queued)
+ responses to update the caller about the status of the queued call.
+
+21.1.5 183 Session Progress
+
+ The 183 (Session Progress) response is used to convey information
+ about the progress of the call that is not otherwise classified. The
+ Reason-Phrase, header fields, or message body MAY be used to convey
+ more details about the call progress.
+
+21.2 Successful 2xx
+
+ The request was successful.
+
+21.2.1 200 OK
+
+ The request has succeeded. The information returned with the
+ response depends on the method used in the request.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 183]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.3 Redirection 3xx
+
+ 3xx responses give information about the user's new location, or
+ about alternative services that might be able to satisfy the call.
+
+21.3.1 300 Multiple Choices
+
+ The address in the request resolved to several choices, each with its
+ own specific location, and the user (or UA) can select a preferred
+ communication end point and redirect its request to that location.
+
+ The response MAY include a message body containing a list of resource
+ characteristics and location(s) from which the user or UA can choose
+ the one most appropriate, if allowed by the Accept request header
+ field. However, no MIME types have been defined for this message
+ body.
+
+ The choices SHOULD also be listed as Contact fields (Section 20.10).
+ Unlike HTTP, the SIP response MAY contain several Contact fields or a
+ list of addresses in a Contact field. UAs MAY use the Contact header
+ field value for automatic redirection or MAY ask the user to confirm
+ a choice. However, this specification does not define any standard
+ for such automatic selection.
+
+ This status response is appropriate if the callee can be reached
+ at several different locations and the server cannot or prefers
+ not to proxy the request.
+
+21.3.2 301 Moved Permanently
+
+ The user can no longer be found at the address in the Request-URI,
+ and the requesting client SHOULD retry at the new address given by
+ the Contact header field (Section 20.10). The requestor SHOULD
+ update any local directories, address books, and user location caches
+ with this new value and redirect future requests to the address(es)
+ listed.
+
+21.3.3 302 Moved Temporarily
+
+ The requesting client SHOULD retry the request at the new address(es)
+ given by the Contact header field (Section 20.10). The Request-URI
+ of the new request uses the value of the Contact header field in the
+ response.
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 184]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The duration of the validity of the Contact URI can be indicated
+ through an Expires (Section 20.19) header field or an expires
+ parameter in the Contact header field. Both proxies and UAs MAY
+ cache this URI for the duration of the expiration time. If there is
+ no explicit expiration time, the address is only valid once for
+ recursing, and MUST NOT be cached for future transactions.
+
+ If the URI cached from the Contact header field fails, the Request-
+ URI from the redirected request MAY be tried again a single time.
+
+ The temporary URI may have become out-of-date sooner than the
+ expiration time, and a new temporary URI may be available.
+
+21.3.4 305 Use Proxy
+
+ The requested resource MUST be accessed through the proxy given by
+ the Contact field. The Contact field gives the URI of the proxy.
+ The recipient is expected to repeat this single request via the
+ proxy. 305 (Use Proxy) responses MUST only be generated by UASs.
+
+21.3.5 380 Alternative Service
+
+ The call was not successful, but alternative services are possible.
+
+ The alternative services are described in the message body of the
+ response. Formats for such bodies are not defined here, and may be
+ the subject of future standardization.
+
+21.4 Request Failure 4xx
+
+ 4xx responses are definite failure responses from a particular
+ server. The client SHOULD NOT retry the same request without
+ modification (for example, adding appropriate authorization).
+ However, the same request to a different server might be successful.
+
+21.4.1 400 Bad Request
+
+ The request could not be understood due to malformed syntax. The
+ Reason-Phrase SHOULD identify the syntax problem in more detail, for
+ example, "Missing Call-ID header field".
+
+21.4.2 401 Unauthorized
+
+ The request requires user authentication. This response is issued by
+ UASs and registrars, while 407 (Proxy Authentication Required) is
+ used by proxy servers.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 185]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.4.3 402 Payment Required
+
+ Reserved for future use.
+
+21.4.4 403 Forbidden
+
+ The server understood the request, but is refusing to fulfill it.
+ Authorization will not help, and the request SHOULD NOT be repeated.
+
+21.4.5 404 Not Found
+
+ The server has definitive information that the user does not exist at
+ the domain specified in the Request-URI. This status is also
+ returned if the domain in the Request-URI does not match any of the
+ domains handled by the recipient of the request.
+
+21.4.6 405 Method Not Allowed
+
+ The method specified in the Request-Line is understood, but not
+ allowed for the address identified by the Request-URI.
+
+ The response MUST include an Allow header field containing a list of
+ valid methods for the indicated address.
+
+21.4.7 406 Not Acceptable
+
+ The resource identified by the request is only capable of generating
+ response entities that have content characteristics not acceptable
+ according to the Accept header field sent in the request.
+
+21.4.8 407 Proxy Authentication Required
+
+ This code is similar to 401 (Unauthorized), but indicates that the
+ client MUST first authenticate itself with the proxy. SIP access
+ authentication is explained in Sections 26 and 22.3.
+
+ This status code can be used for applications where access to the
+ communication channel (for example, a telephony gateway) rather than
+ the callee requires authentication.
+
+21.4.9 408 Request Timeout
+
+ The server could not produce a response within a suitable amount of
+ time, for example, if it could not determine the location of the user
+ in time. The client MAY repeat the request without modifications at
+ any later time.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 186]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.4.10 410 Gone
+
+ The requested resource is no longer available at the server and no
+ forwarding address is known. This condition is expected to be
+ considered permanent. If the server does not know, or has no
+ facility to determine, whether or not the condition is permanent, the
+ status code 404 (Not Found) SHOULD be used instead.
+
+21.4.11 413 Request Entity Too Large
+
+ The server is refusing to process a request because the request
+ entity-body is larger than the server is willing or able to process.
+ The server MAY close the connection to prevent the client from
+ continuing the request.
+
+ If the condition is temporary, the server SHOULD include a Retry-
+ After header field to indicate that it is temporary and after what
+ time the client MAY try again.
+
+21.4.12 414 Request-URI Too Long
+
+ The server is refusing to service the request because the Request-URI
+ is longer than the server is willing to interpret.
+
+21.4.13 415 Unsupported Media Type
+
+ The server is refusing to service the request because the message
+ body of the request is in a format not supported by the server for
+ the requested method. The server MUST return a list of acceptable
+ formats using the Accept, Accept-Encoding, or Accept-Language header
+ field, depending on the specific problem with the content. UAC
+ processing of this response is described in Section 8.1.3.5.
+
+21.4.14 416 Unsupported URI Scheme
+
+ The server cannot process the request because the scheme of the URI
+ in the Request-URI is unknown to the server. Client processing of
+ this response is described in Section 8.1.3.5.
+
+21.4.15 420 Bad Extension
+
+ The server did not understand the protocol extension specified in a
+ Proxy-Require (Section 20.29) or Require (Section 20.32) header
+ field. The server MUST include a list of the unsupported extensions
+ in an Unsupported header field in the response. UAC processing of
+ this response is described in Section 8.1.3.5.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 187]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.4.16 421 Extension Required
+
+ The UAS needs a particular extension to process the request, but this
+ extension is not listed in a Supported header field in the request.
+ Responses with this status code MUST contain a Require header field
+ listing the required extensions.
+
+ A UAS SHOULD NOT use this response unless it truly cannot provide any
+ useful service to the client. Instead, if a desirable extension is
+ not listed in the Supported header field, servers SHOULD process the
+ request using baseline SIP capabilities and any extensions supported
+ by the client.
+
+21.4.17 423 Interval Too Brief
+
+ The server is rejecting the request because the expiration time of
+ the resource refreshed by the request is too short. This response
+ can be used by a registrar to reject a registration whose Contact
+ header field expiration time was too small. The use of this response
+ and the related Min-Expires header field are described in Sections
+ 10.2.8, 10.3, and 20.23.
+
+21.4.18 480 Temporarily Unavailable
+
+ The callee's end system was contacted successfully but the callee is
+ currently unavailable (for example, is not logged in, logged in but
+ in a state that precludes communication with the callee, or has
+ activated the "do not disturb" feature). The response MAY indicate a
+ better time to call in the Retry-After header field. The user could
+ also be available elsewhere (unbeknownst to this server). The reason
+ phrase SHOULD indicate a more precise cause as to why the callee is
+ unavailable. This value SHOULD be settable by the UA. Status 486
+ (Busy Here) MAY be used to more precisely indicate a particular
+ reason for the call failure.
+
+ This status is also returned by a redirect or proxy server that
+ recognizes the user identified by the Request-URI, but does not
+ currently have a valid forwarding location for that user.
+
+21.4.19 481 Call/Transaction Does Not Exist
+
+ This status indicates that the UAS received a request that does not
+ match any existing dialog or transaction.
+
+21.4.20 482 Loop Detected
+
+ The server has detected a loop (Section 16.3 Item 4).
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 188]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.4.21 483 Too Many Hops
+
+ The server received a request that contains a Max-Forwards (Section
+ 20.22) header field with the value zero.
+
+21.4.22 484 Address Incomplete
+
+ The server received a request with a Request-URI that was incomplete.
+ Additional information SHOULD be provided in the reason phrase.
+
+ This status code allows overlapped dialing. With overlapped
+ dialing, the client does not know the length of the dialing
+ string. It sends strings of increasing lengths, prompting the
+ user for more input, until it no longer receives a 484 (Address
+ Incomplete) status response.
+
+21.4.23 485 Ambiguous
+
+ The Request-URI was ambiguous. The response MAY contain a listing of
+ possible unambiguous addresses in Contact header fields. Revealing
+ alternatives can infringe on privacy of the user or the organization.
+ It MUST be possible to configure a server to respond with status 404
+ (Not Found) or to suppress the listing of possible choices for
+ ambiguous Request-URIs.
+
+ Example response to a request with the Request-URI
+ sip:lee@example.com:
+
+ SIP/2.0 485 Ambiguous
+ Contact: Carol Lee <sip:carol.lee@example.com>
+ Contact: Ping Lee <sip:p.lee@example.com>
+ Contact: Lee M. Foote <sips:lee.foote@example.com>
+
+ Some email and voice mail systems provide this functionality. A
+ status code separate from 3xx is used since the semantics are
+ different: for 300, it is assumed that the same person or service
+ will be reached by the choices provided. While an automated
+ choice or sequential search makes sense for a 3xx response, user
+ intervention is required for a 485 (Ambiguous) response.
+
+21.4.24 486 Busy Here
+
+ The callee's end system was contacted successfully, but the callee is
+ currently not willing or able to take additional calls at this end
+ system. The response MAY indicate a better time to call in the
+ Retry-After header field. The user could also be available
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 189]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ elsewhere, such as through a voice mail service. Status 600 (Busy
+ Everywhere) SHOULD be used if the client knows that no other end
+ system will be able to accept this call.
+
+21.4.25 487 Request Terminated
+
+ The request was terminated by a BYE or CANCEL request. This response
+ is never returned for a CANCEL request itself.
+
+21.4.26 488 Not Acceptable Here
+
+ The response has the same meaning as 606 (Not Acceptable), but only
+ applies to the specific resource addressed by the Request-URI and the
+ request may succeed elsewhere.
+
+ A message body containing a description of media capabilities MAY be
+ present in the response, which is formatted according to the Accept
+ header field in the INVITE (or application/sdp if not present), the
+ same as a message body in a 200 (OK) response to an OPTIONS request.
+
+21.4.27 491 Request Pending
+
+ The request was received by a UAS that had a pending request within
+ the same dialog. Section 14.2 describes how such "glare" situations
+ are resolved.
+
+21.4.28 493 Undecipherable
+
+ The request was received by a UAS that contained an encrypted MIME
+ body for which the recipient does not possess or will not provide an
+ appropriate decryption key. This response MAY have a single body
+ containing an appropriate public key that should be used to encrypt
+ MIME bodies sent to this UA. Details of the usage of this response
+ code can be found in Section 23.2.
+
+21.5 Server Failure 5xx
+
+ 5xx responses are failure responses given when a server itself has
+ erred.
+
+21.5.1 500 Server Internal Error
+
+ The server encountered an unexpected condition that prevented it from
+ fulfilling the request. The client MAY display the specific error
+ condition and MAY retry the request after several seconds.
+
+ If the condition is temporary, the server MAY indicate when the
+ client may retry the request using the Retry-After header field.
+
+
+
+Rosenberg, et. al. Standards Track [Page 190]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.5.2 501 Not Implemented
+
+ The server does not support the functionality required to fulfill the
+ request. This is the appropriate response when a UAS does not
+ recognize the request method and is not capable of supporting it for
+ any user. (Proxies forward all requests regardless of method.)
+
+ Note that a 405 (Method Not Allowed) is sent when the server
+ recognizes the request method, but that method is not allowed or
+ supported.
+
+21.5.3 502 Bad Gateway
+
+ The server, while acting as a gateway or proxy, received an invalid
+ response from the downstream server it accessed in attempting to
+ fulfill the request.
+
+21.5.4 503 Service Unavailable
+
+ The server is temporarily unable to process the request due to a
+ temporary overloading or maintenance of the server. The server MAY
+ indicate when the client should retry the request in a Retry-After
+ header field. If no Retry-After is given, the client MUST act as if
+ it had received a 500 (Server Internal Error) response.
+
+ A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
+ attempt to forward the request to an alternate server. It SHOULD NOT
+ forward any other requests to that server for the duration specified
+ in the Retry-After header field, if present.
+
+ Servers MAY refuse the connection or drop the request instead of
+ responding with 503 (Service Unavailable).
+
+21.5.5 504 Server Time-out
+
+ The server did not receive a timely response from an external server
+ it accessed in attempting to process the request. 408 (Request
+ Timeout) should be used instead if there was no response within the
+ period specified in the Expires header field from the upstream
+ server.
+
+21.5.6 505 Version Not Supported
+
+ The server does not support, or refuses to support, the SIP protocol
+ version that was used in the request. The server is indicating that
+ it is unable or unwilling to complete the request using the same
+ major version as the client, other than with this error message.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 191]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+21.5.7 513 Message Too Large
+
+ The server was unable to process the request since the message length
+ exceeded its capabilities.
+
+21.6 Global Failures 6xx
+
+ 6xx responses indicate that a server has definitive information about
+ a particular user, not just the particular instance indicated in the
+ Request-URI.
+
+21.6.1 600 Busy Everywhere
+
+ The callee's end system was contacted successfully but the callee is
+ busy and does not wish to take the call at this time. The response
+ MAY indicate a better time to call in the Retry-After header field.
+ If the callee does not wish to reveal the reason for declining the
+ call, the callee uses status code 603 (Decline) instead. This status
+ response is returned only if the client knows that no other end point
+ (such as a voice mail system) will answer the request. Otherwise,
+ 486 (Busy Here) should be returned.
+
+21.6.2 603 Decline
+
+ The callee's machine was successfully contacted but the user
+ explicitly does not wish to or cannot participate. The response MAY
+ indicate a better time to call in the Retry-After header field. This
+ status response is returned only if the client knows that no other
+ end point will answer the request.
+
+21.6.3 604 Does Not Exist Anywhere
+
+ The server has authoritative information that the user indicated in
+ the Request-URI does not exist anywhere.
+
+21.6.4 606 Not Acceptable
+
+ The user's agent was contacted successfully but some aspects of the
+ session description such as the requested media, bandwidth, or
+ addressing style were not acceptable.
+
+ A 606 (Not Acceptable) response means that the user wishes to
+ communicate, but cannot adequately support the session described.
+ The 606 (Not Acceptable) response MAY contain a list of reasons in a
+ Warning header field describing why the session described cannot be
+ supported. Warning reason codes are listed in Section 20.43.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 192]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ A message body containing a description of media capabilities MAY be
+ present in the response, which is formatted according to the Accept
+ header field in the INVITE (or application/sdp if not present), the
+ same as a message body in a 200 (OK) response to an OPTIONS request.
+
+ It is hoped that negotiation will not frequently be needed, and when
+ a new user is being invited to join an already existing conference,
+ negotiation may not be possible. It is up to the invitation
+ initiator to decide whether or not to act on a 606 (Not Acceptable)
+ response.
+
+ This status response is returned only if the client knows that no
+ other end point will answer the request.
+
+22 Usage of HTTP Authentication
+
+ SIP provides a stateless, challenge-based mechanism for
+ authentication that is based on authentication in HTTP. Any time
+ that a proxy server or UA receives a request (with the exceptions
+ given in Section 22.1), it MAY challenge the initiator of the request
+ to provide assurance of its identity. Once the originator has been
+ identified, the recipient of the request SHOULD ascertain whether or
+ not this user is authorized to make the request in question. No
+ authorization systems are recommended or discussed in this document.
+
+ The "Digest" authentication mechanism described in this section
+ provides message authentication and replay protection only, without
+ message integrity or confidentiality. Protective measures above and
+ beyond those provided by Digest need to be taken to prevent active
+ attackers from modifying SIP requests and responses.
+
+ Note that due to its weak security, the usage of "Basic"
+ authentication has been deprecated. Servers MUST NOT accept
+ credentials using the "Basic" authorization scheme, and servers also
+ MUST NOT challenge with "Basic". This is a change from RFC 2543.
+
+22.1 Framework
+
+ The framework for SIP authentication closely parallels that of HTTP
+ (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param,
+ challenge, realm, realm-value, and credentials is identical (although
+ the usage of "Basic" as a scheme is not permitted). In SIP, a UAS
+ uses the 401 (Unauthorized) response to challenge the identity of a
+ UAC. Additionally, registrars and redirect servers MAY make use of
+ 401 (Unauthorized) responses for authentication, but proxies MUST
+ NOT, and instead MAY use the 407 (Proxy Authentication Required)
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 193]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ response. The requirements for inclusion of the Proxy-Authenticate,
+ Proxy-Authorization, WWW-Authenticate, and Authorization in the
+ various messages are identical to those described in RFC 2617 [17].
+
+ Since SIP does not have the concept of a canonical root URL, the
+ notion of protection spaces is interpreted differently in SIP. The
+ realm string alone defines the protection domain. This is a change
+ from RFC 2543, in which the Request-URI and the realm together
+ defined the protection domain.
+
+ This previous definition of protection domain caused some amount
+ of confusion since the Request-URI sent by the UAC and the
+ Request-URI received by the challenging server might be different,
+ and indeed the final form of the Request-URI might not be known to
+ the UAC. Also, the previous definition depended on the presence
+ of a SIP URI in the Request-URI and seemed to rule out alternative
+ URI schemes (for example, the tel URL).
+
+ Operators of user agents or proxy servers that will authenticate
+ received requests MUST adhere to the following guidelines for
+ creation of a realm string for their server:
+
+ o Realm strings MUST be globally unique. It is RECOMMENDED that
+ a realm string contain a hostname or domain name, following the
+ recommendation in Section 3.2.1 of RFC 2617 [17].
+
+ o Realm strings SHOULD present a human-readable identifier that
+ can be rendered to a user.
+
+ For example:
+
+ INVITE sip:bob@biloxi.com SIP/2.0
+ Authorization: Digest realm="biloxi.com", <...>
+
+ Generally, SIP authentication is meaningful for a specific realm, a
+ protection domain. Thus, for Digest authentication, each such
+ protection domain has its own set of usernames and passwords. If a
+ server does not require authentication for a particular request, it
+ MAY accept a default username, "anonymous", which has no password
+ (password of ""). Similarly, UACs representing many users, such as
+ PSTN gateways, MAY have their own device-specific username and
+ password, rather than accounts for particular users, for their realm.
+
+ While a server can legitimately challenge most SIP requests, there
+ are two requests defined by this document that require special
+ handling for authentication: ACK and CANCEL.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 194]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Under an authentication scheme that uses responses to carry values
+ used to compute nonces (such as Digest), some problems come up for
+ any requests that take no response, including ACK. For this reason,
+ any credentials in the INVITE that were accepted by a server MUST be
+ accepted by that server for the ACK. UACs creating an ACK message
+ will duplicate all of the Authorization and Proxy-Authorization
+ header field values that appeared in the INVITE to which the ACK
+ corresponds. Servers MUST NOT attempt to challenge an ACK.
+
+ Although the CANCEL method does take a response (a 2xx), servers MUST
+ NOT attempt to challenge CANCEL requests since these requests cannot
+ be resubmitted. Generally, a CANCEL request SHOULD be accepted by a
+ server if it comes from the same hop that sent the request being
+ canceled (provided that some sort of transport or network layer
+ security association, as described in Section 26.2.1, is in place).
+
+ When a UAC receives a challenge, it SHOULD render to the user the
+ contents of the "realm" parameter in the challenge (which appears in
+ either a WWW-Authenticate header field or Proxy-Authenticate header
+ field) if the UAC device does not already know of a credential for
+ the realm in question. A service provider that pre-configures UAs
+ with credentials for its realm should be aware that users will not
+ have the opportunity to present their own credentials for this realm
+ when challenged at a pre-configured device.
+
+ Finally, note that even if a UAC can locate credentials that are
+ associated with the proper realm, the potential exists that these
+ credentials may no longer be valid or that the challenging server
+ will not accept these credentials for whatever reason (especially
+ when "anonymous" with no password is submitted). In this instance a
+ server may repeat its challenge, or it may respond with a 403
+ Forbidden. A UAC MUST NOT re-attempt requests with the credentials
+ that have just been rejected (though the request may be retried if
+ the nonce was stale).
+
+22.2 User-to-User Authentication
+
+ When a UAS receives a request from a UAC, the UAS MAY authenticate
+ the originator before the request is processed. If no credentials
+ (in the Authorization header field) are provided in the request, the
+ UAS can challenge the originator to provide credentials by rejecting
+ the request with a 401 (Unauthorized) status code.
+
+ The WWW-Authenticate response-header field MUST be included in 401
+ (Unauthorized) response messages. The field value consists of at
+ least one challenge that indicates the authentication scheme(s) and
+ parameters applicable to the realm.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 195]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ An example of the WWW-Authenticate header field in a 401 challenge
+ is:
+
+ WWW-Authenticate: Digest
+ realm="biloxi.com",
+ qop="auth,auth-int",
+ nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+ opaque="5ccc069c403ebaf9f0171e9517f40e41"
+
+ When the originating UAC receives the 401 (Unauthorized), it SHOULD,
+ if it is able, re-originate the request with the proper credentials.
+ The UAC may require input from the originating user before
+ proceeding. Once authentication credentials have been supplied
+ (either directly by the user, or discovered in an internal keyring),
+ UAs SHOULD cache the credentials for a given value of the To header
+ field and "realm" and attempt to re-use these values on the next
+ request for that destination. UAs MAY cache credentials in any way
+ they would like.
+
+ If no credentials for a realm can be located, UACs MAY attempt to
+ retry the request with a username of "anonymous" and no password (a
+ password of "").
+
+ Once credentials have been located, any UA that wishes to
+ authenticate itself with a UAS or registrar -- usually, but not
+ necessarily, after receiving a 401 (Unauthorized) response -- MAY do
+ so by including an Authorization header field with the request. The
+ Authorization field value consists of credentials containing the
+ authentication information of the UA for the realm of the resource
+ being requested as well as parameters required in support of
+ authentication and replay protection.
+
+ An example of the Authorization header field is:
+
+ Authorization: Digest username="bob",
+ realm="biloxi.com",
+ nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+ uri="sip:bob@biloxi.com",
+ qop=auth,
+ nc=00000001,
+ cnonce="0a4f113b",
+ response="6629fae49393a05397450978507c4ef1",
+ opaque="5ccc069c403ebaf9f0171e9517f40e41"
+
+ When a UAC resubmits a request with its credentials after receiving a
+ 401 (Unauthorized) or 407 (Proxy Authentication Required) response,
+ it MUST increment the CSeq header field value as it would normally
+ when sending an updated request.
+
+
+
+Rosenberg, et. al. Standards Track [Page 196]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+22.3 Proxy-to-User Authentication
+
+ Similarly, when a UAC sends a request to a proxy server, the proxy
+ server MAY authenticate the originator before the request is
+ processed. If no credentials (in the Proxy-Authorization header
+ field) are provided in the request, the proxy can challenge the
+ originator to provide credentials by rejecting the request with a 407
+ (Proxy Authentication Required) status code. The proxy MUST populate
+ the 407 (Proxy Authentication Required) message with a Proxy-
+ Authenticate header field value applicable to the proxy for the
+ requested resource.
+
+ The use of Proxy-Authenticate and Proxy-Authorization parallel that
+ described in [17], with one difference. Proxies MUST NOT add values
+ to the Proxy-Authorization header field. All 407 (Proxy
+ Authentication Required) responses MUST be forwarded upstream toward
+ the UAC following the procedures for any other response. It is the
+ UAC's responsibility to add the Proxy-Authorization header field
+ value containing credentials for the realm of the proxy that has
+ asked for authentication.
+
+ If a proxy were to resubmit a request adding a Proxy-Authorization
+ header field value, it would need to increment the CSeq in the new
+ request. However, this would cause the UAC that submitted the
+ original request to discard a response from the UAS, as the CSeq
+ value would be different.
+
+ When the originating UAC receives the 407 (Proxy Authentication
+ Required) it SHOULD, if it is able, re-originate the request with the
+ proper credentials. It should follow the same procedures for the
+ display of the "realm" parameter that are given above for responding
+ to 401.
+
+ If no credentials for a realm can be located, UACs MAY attempt to
+ retry the request with a username of "anonymous" and no password (a
+ password of "").
+
+ The UAC SHOULD also cache the credentials used in the re-originated
+ request.
+
+ The following rule is RECOMMENDED for proxy credential caching:
+
+ If a UA receives a Proxy-Authenticate header field value in a 401/407
+ response to a request with a particular Call-ID, it should
+ incorporate credentials for that realm in all subsequent requests
+ that contain the same Call-ID. These credentials MUST NOT be cached
+ across dialogs; however, if a UA is configured with the realm of its
+ local outbound proxy, when one exists, then the UA MAY cache
+
+
+
+Rosenberg, et. al. Standards Track [Page 197]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ credentials for that realm across dialogs. Note that this does mean
+ a future request in a dialog could contain credentials that are not
+ needed by any proxy along the Route header path.
+
+ Any UA that wishes to authenticate itself to a proxy server --
+ usually, but not necessarily, after receiving a 407 (Proxy
+ Authentication Required) response -- MAY do so by including a Proxy-
+ Authorization header field value with the request. The Proxy-
+ Authorization request-header field allows the client to identify
+ itself (or its user) to a proxy that requires authentication. The
+ Proxy-Authorization header field value consists of credentials
+ containing the authentication information of the UA for the proxy
+ and/or realm of the resource being requested.
+
+ A Proxy-Authorization header field value applies only to the proxy
+ whose realm is identified in the "realm" parameter (this proxy may
+ previously have demanded authentication using the Proxy-Authenticate
+ field). When multiple proxies are used in a chain, a Proxy-
+ Authorization header field value MUST NOT be consumed by any proxy
+ whose realm does not match the "realm" parameter specified in that
+ value.
+
+ Note that if an authentication scheme that does not support realms is
+ used in the Proxy-Authorization header field, a proxy server MUST
+ attempt to parse all Proxy-Authorization header field values to
+ determine whether one of them has what the proxy server considers to
+ be valid credentials. Because this is potentially very time-
+ consuming in large networks, proxy servers SHOULD use an
+ authentication scheme that supports realms in the Proxy-Authorization
+ header field.
+
+ If a request is forked (as described in Section 16.7), various proxy
+ servers and/or UAs may wish to challenge the UAC. In this case, the
+ forking proxy server is responsible for aggregating these challenges
+ into a single response. Each WWW-Authenticate and Proxy-Authenticate
+ value received in responses to the forked request MUST be placed into
+ the single response that is sent by the forking proxy to the UA; the
+ ordering of these header field values is not significant.
+
+ When a proxy server issues a challenge in response to a request,
+ it will not proxy the request until the UAC has retried the
+ request with valid credentials. A forking proxy may forward a
+ request simultaneously to multiple proxy servers that require
+ authentication, each of which in turn will not forward the request
+ until the originating UAC has authenticated itself in their
+ respective realm. If the UAC does not provide credentials for
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 198]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ each challenge, the proxy servers that issued the challenges will
+ not forward requests to the UA where the destination user might be
+ located, and therefore, the virtues of forking are largely lost.
+
+ When resubmitting its request in response to a 401 (Unauthorized) or
+ 407 (Proxy Authentication Required) that contains multiple
+ challenges, a UAC MAY include an Authorization value for each WWW-
+ Authenticate value and a Proxy-Authorization value for each Proxy-
+ Authenticate value for which the UAC wishes to supply a credential.
+ As noted above, multiple credentials in a request SHOULD be
+ differentiated by the "realm" parameter.
+
+ It is possible for multiple challenges associated with the same realm
+ to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication
+ Required). This can occur, for example, when multiple proxies within
+ the same administrative domain, which use a common realm, are reached
+ by a forking request. When it retries a request, a UAC MAY therefore
+ supply multiple credentials in Authorization or Proxy-Authorization
+ header fields with the same "realm" parameter value. The same
+ credentials SHOULD be used for the same realm.
+
+22.4 The Digest Authentication Scheme
+
+ This section describes the modifications and clarifications required
+ to apply the HTTP Digest authentication scheme to SIP. The SIP
+ scheme usage is almost completely identical to that for HTTP [17].
+
+ Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39],
+ SIP servers supporting RFC 2617 MUST ensure they are backwards
+ compatible with RFC 2069. Procedures for this backwards
+ compatibility are specified in RFC 2617. Note, however, that SIP
+ servers MUST NOT accept or request Basic authentication.
+
+ The rules for Digest authentication follow those defined in [17],
+ with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following
+ differences:
+
+ 1. The URI included in the challenge has the following BNF:
+
+ URI = SIP-URI / SIPS-URI
+
+ 2. The BNF in RFC 2617 has an error in that the 'uri' parameter
+ of the Authorization header field for HTTP Digest
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 199]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ authentication is not enclosed in quotation marks. (The
+ example in Section 3.5 of RFC 2617 is correct.) For SIP, the
+ 'uri' MUST be enclosed in quotation marks.
+
+ 3. The BNF for digest-uri-value is:
+
+ digest-uri-value = Request-URI ; as defined in Section 25
+
+ 4. The example procedure for choosing a nonce based on Etag does
+ not work for SIP.
+
+ 5. The text in RFC 2617 [17] regarding cache operation does not
+ apply to SIP.
+
+ 6. RFC 2617 [17] requires that a server check that the URI in the
+ request line and the URI included in the Authorization header
+ field point to the same resource. In a SIP context, these two
+ URIs may refer to different users, due to forwarding at some
+ proxy. Therefore, in SIP, a server MAY check that the
+ Request-URI in the Authorization header field value
+ corresponds to a user for whom the server is willing to accept
+ forwarded or direct requests, but it is not necessarily a
+ failure if the two fields are not equivalent.
+
+ 7. As a clarification to the calculation of the A2 value for
+ message integrity assurance in the Digest authentication
+ scheme, implementers should assume, when the entity-body is
+ empty (that is, when SIP messages have no body) that the hash
+ of the entity-body resolves to the MD5 hash of an empty
+ string, or:
+
+ H(entity-body) = MD5("") =
+ "d41d8cd98f00b204e9800998ecf8427e"
+
+ 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an
+ Authorization (and by extension Proxy-Authorization) header
+ field if no qop directive has been sent. Therefore, any
+ algorithms that have a dependency on the cnonce (including
+ "MD5-Sess") require that the qop directive be sent. Use of
+ the "qop" parameter is optional in RFC 2617 for the purposes
+ of backwards compatibility with RFC 2069; since RFC 2543 was
+ based on RFC 2069, the "qop" parameter must unfortunately
+ remain optional for clients and servers to receive. However,
+ servers MUST always send a "qop" parameter in WWW-Authenticate
+ and Proxy-Authenticate header field values. If a client
+ receives a "qop" parameter in a challenge header field, it
+ MUST send the "qop" parameter in any resulting authorization
+ header field.
+
+
+
+Rosenberg, et. al. Standards Track [Page 200]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ RFC 2543 did not allow usage of the Authentication-Info header field
+ (it effectively used RFC 2069). However, we now allow usage of this
+ header field, since it provides integrity checks over the bodies and
+ provides mutual authentication. RFC 2617 [17] defines mechanisms for
+ backwards compatibility using the qop attribute in the request.
+ These mechanisms MUST be used by a server to determine if the client
+ supports the new mechanisms in RFC 2617 that were not specified in
+ RFC 2069.
+
+23 S/MIME
+
+ SIP messages carry MIME bodies and the MIME standard includes
+ mechanisms for securing MIME contents to ensure both integrity and
+ confidentiality (including the 'multipart/signed' and
+ 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23]
+ and RFC 2633 [24]). Implementers should note, however, that there
+ may be rare network intermediaries (not typical proxy servers) that
+ rely on viewing or modifying the bodies of SIP messages (especially
+ SDP), and that secure MIME may prevent these sorts of intermediaries
+ from functioning.
+
+ This applies particularly to certain types of firewalls.
+
+ The PGP mechanism for encrypting the header fields and bodies of
+ SIP messages described in RFC 2543 has been deprecated.
+
+23.1 S/MIME Certificates
+
+ The certificates that are used to identify an end-user for the
+ purposes of S/MIME differ from those used by servers in one important
+ respect - rather than asserting that the identity of the holder
+ corresponds to a particular hostname, these certificates assert that
+ the holder is identified by an end-user address. This address is
+ composed of the concatenation of the "userinfo" "@" and "domainname"
+ portions of a SIP or SIPS URI (in other words, an email address of
+ the form "bob@biloxi.com"), most commonly corresponding to a user's
+ address-of-record.
+
+ These certificates are also associated with keys that are used to
+ sign or encrypt bodies of SIP messages. Bodies are signed with the
+ private key of the sender (who may include their public key with the
+ message as appropriate), but bodies are encrypted with the public key
+ of the intended recipient. Obviously, senders must have
+ foreknowledge of the public key of recipients in order to encrypt
+ message bodies. Public keys can be stored within a UA on a virtual
+ keyring.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 201]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Each user agent that supports S/MIME MUST contain a keyring
+ specifically for end-users' certificates. This keyring should map
+ between addresses of record and corresponding certificates. Over
+ time, users SHOULD use the same certificate when they populate the
+ originating URI of signaling (the From header field) with the same
+ address-of-record.
+
+ Any mechanisms depending on the existence of end-user certificates
+ are seriously limited in that there is virtually no consolidated
+ authority today that provides certificates for end-user applications.
+ However, users SHOULD acquire certificates from known public
+ certificate authorities. As an alternative, users MAY create self-
+ signed certificates. The implications of self-signed certificates
+ are explored further in Section 26.4.2. Implementations may also use
+ pre-configured certificates in deployments in which a previous trust
+ relationship exists between all SIP entities.
+
+ Above and beyond the problem of acquiring an end-user certificate,
+ there are few well-known centralized directories that distribute
+ end-user certificates. However, the holder of a certificate SHOULD
+ publish their certificate in any public directories as appropriate.
+ Similarly, UACs SHOULD support a mechanism for importing (manually or
+ automatically) certificates discovered in public directories
+ corresponding to the target URIs of SIP requests.
+
+23.2 S/MIME Key Exchange
+
+ SIP itself can also be used as a means to distribute public keys in
+ the following manner.
+
+ Whenever the CMS SignedData message is used in S/MIME for SIP, it
+ MUST contain the certificate bearing the public key necessary to
+ verify the signature.
+
+ When a UAC sends a request containing an S/MIME body that initiates a
+ dialog, or sends a non-INVITE request outside the context of a
+ dialog, the UAC SHOULD structure the body as an S/MIME
+ 'multipart/signed' CMS SignedData body. If the desired CMS service
+ is EnvelopedData (and the public key of the target user is known),
+ the UAC SHOULD send the EnvelopedData message encapsulated within a
+ SignedData message.
+
+ When a UAS receives a request containing an S/MIME CMS body that
+ includes a certificate, the UAS SHOULD first validate the
+ certificate, if possible, with any available root certificates for
+ certificate authorities. The UAS SHOULD also determine the subject
+ of the certificate (for S/MIME, the SubjectAltName will contain the
+ appropriate identity) and compare this value to the From header field
+
+
+
+Rosenberg, et. al. Standards Track [Page 202]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ of the request. If the certificate cannot be verified, because it is
+ self-signed, or signed by no known authority, or if it is verifiable
+ but its subject does not correspond to the From header field of
+ request, the UAS MUST notify its user of the status of the
+ certificate (including the subject of the certificate, its signer,
+ and any key fingerprint information) and request explicit permission
+ before proceeding. If the certificate was successfully verified and
+ the subject of the certificate corresponds to the From header field
+ of the SIP request, or if the user (after notification) explicitly
+ authorizes the use of the certificate, the UAS SHOULD add this
+ certificate to a local keyring, indexed by the address-of-record of
+ the holder of the certificate.
+
+ When a UAS sends a response containing an S/MIME body that answers
+ the first request in a dialog, or a response to a non-INVITE request
+ outside the context of a dialog, the UAS SHOULD structure the body as
+ an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS
+ service is EnvelopedData, the UAS SHOULD send the EnvelopedData
+ message encapsulated within a SignedData message.
+
+ When a UAC receives a response containing an S/MIME CMS body that
+ includes a certificate, the UAC SHOULD first validate the
+ certificate, if possible, with any appropriate root certificate. The
+ UAC SHOULD also determine the subject of the certificate and compare
+ this value to the To field of the response; although the two may very
+ well be different, and this is not necessarily indicative of a
+ security breach. If the certificate cannot be verified because it is
+ self-signed, or signed by no known authority, the UAC MUST notify its
+ user of the status of the certificate (including the subject of the
+ certificate, its signator, and any key fingerprint information) and
+ request explicit permission before proceeding. If the certificate
+ was successfully verified, and the subject of the certificate
+ corresponds to the To header field in the response, or if the user
+ (after notification) explicitly authorizes the use of the
+ certificate, the UAC SHOULD add this certificate to a local keyring,
+ indexed by the address-of-record of the holder of the certificate.
+ If the UAC had not transmitted its own certificate to the UAS in any
+ previous transaction, it SHOULD use a CMS SignedData body for its
+ next request or response.
+
+ On future occasions, when the UA receives requests or responses that
+ contain a From header field corresponding to a value in its keyring,
+ the UA SHOULD compare the certificate offered in these messages with
+ the existing certificate in its keyring. If there is a discrepancy,
+ the UA MUST notify its user of a change of the certificate
+ (preferably in terms that indicate that this is a potential security
+ breach) and acquire the user's permission before continuing to
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 203]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ process the signaling. If the user authorizes this certificate, it
+ SHOULD be added to the keyring alongside any previous value(s) for
+ this address-of-record.
+
+ Note well however, that this key exchange mechanism does not
+ guarantee the secure exchange of keys when self-signed certificates,
+ or certificates signed by an obscure authority, are used - it is
+ vulnerable to well-known attacks. In the opinion of the authors,
+ however, the security it provides is proverbially better than
+ nothing; it is in fact comparable to the widely used SSH application.
+ These limitations are explored in greater detail in Section 26.4.2.
+
+ If a UA receives an S/MIME body that has been encrypted with a public
+ key unknown to the recipient, it MUST reject the request with a 493
+ (Undecipherable) response. This response SHOULD contain a valid
+ certificate for the respondent (corresponding, if possible, to any
+ address of record given in the To header field of the rejected
+ request) within a MIME body with a 'certs-only' "smime-type"
+ parameter.
+
+ A 493 (Undecipherable) sent without any certificate indicates that
+ the respondent cannot or will not utilize S/MIME encrypted messages,
+ though they may still support S/MIME signatures.
+
+ Note that a user agent that receives a request containing an S/MIME
+ body that is not optional (with a Content-Disposition header
+ "handling" parameter of "required") MUST reject the request with a
+ 415 Unsupported Media Type response if the MIME type is not
+ understood. A user agent that receives such a response when S/MIME
+ is sent SHOULD notify its user that the remote device does not
+ support S/MIME, and it MAY subsequently resend the request without
+ S/MIME, if appropriate; however, this 415 response may constitute a
+ downgrade attack.
+
+ If a user agent sends an S/MIME body in a request, but receives a
+ response that contains a MIME body that is not secured, the UAC
+ SHOULD notify its user that the session could not be secured.
+ However, if a user agent that supports S/MIME receives a request with
+ an unsecured body, it SHOULD NOT respond with a secured body, but if
+ it expects S/MIME from the sender (for example, because the sender's
+ From header field value corresponds to an identity on its keychain),
+ the UAS SHOULD notify its user that the session could not be secured.
+
+ A number of conditions that arise in the previous text call for the
+ notification of the user when an anomalous certificate-management
+ event occurs. Users might well ask what they should do under these
+ circumstances. First and foremost, an unexpected change in a
+ certificate, or an absence of security when security is expected, are
+
+
+
+Rosenberg, et. al. Standards Track [Page 204]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ causes for caution but not necessarily indications that an attack is
+ in progress. Users might abort any connection attempt or refuse a
+ connection request they have received; in telephony parlance, they
+ could hang up and call back. Users may wish to find an alternate
+ means to contact the other party and confirm that their key has
+ legitimately changed. Note that users are sometimes compelled to
+ change their certificates, for example when they suspect that the
+ secrecy of their private key has been compromised. When their
+ private key is no longer private, users must legitimately generate a
+ new key and re-establish trust with any users that held their old
+ key.
+
+ Finally, if during the course of a dialog a UA receives a certificate
+ in a CMS SignedData message that does not correspond with the
+ certificates previously exchanged during a dialog, the UA MUST notify
+ its user of the change, preferably in terms that indicate that this
+ is a potential security breach.
+
+23.3 Securing MIME bodies
+
+ There are two types of secure MIME bodies that are of interest to
+ SIP: use of these bodies should follow the S/MIME specification [24]
+ with a few variations.
+
+ o "multipart/signed" MUST be used only with CMS detached
+ signatures.
+
+ This allows backwards compatibility with non-S/MIME-
+ compliant recipients.
+
+ o S/MIME bodies SHOULD have a Content-Disposition header field,
+ and the value of the "handling" parameter SHOULD be "required."
+
+ o If a UAC has no certificate on its keyring associated with the
+ address-of-record to which it wants to send a request, it
+ cannot send an encrypted "application/pkcs7-mime" MIME message.
+ UACs MAY send an initial request such as an OPTIONS message
+ with a CMS detached signature in order to solicit the
+ certificate of the remote side (the signature SHOULD be over a
+ "message/sip" body of the type described in Section 23.4).
+
+ Note that future standardization work on S/MIME may define
+ non-certificate based keys.
+
+ o Senders of S/MIME bodies SHOULD use the "SMIMECapabilities"
+ (see Section 2.5.2 of [24]) attribute to express their
+ capabilities and preferences for further communications. Note
+ especially that senders MAY use the "preferSignedData"
+
+
+
+Rosenberg, et. al. Standards Track [Page 205]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ capability to encourage receivers to respond with CMS
+ SignedData messages (for example, when sending an OPTIONS
+ request as described above).
+
+ o S/MIME implementations MUST at a minimum support SHA1 as a
+ digital signature algorithm, and 3DES as an encryption
+ algorithm. All other signature and encryption algorithms MAY
+ be supported. Implementations can negotiate support for these
+ algorithms with the "SMIMECapabilities" attribute.
+
+ o Each S/MIME body in a SIP message SHOULD be signed with only
+ one certificate. If a UA receives a message with multiple
+ signatures, the outermost signature should be treated as the
+ single certificate for this body. Parallel signatures SHOULD
+ NOT be used.
+
+ The following is an example of an encrypted S/MIME SDP body
+ within a SIP message:
+
+ INVITE sip:bob@biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ To: Bob <sip:bob@biloxi.com>
+ From: Alice <sip:alice@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314159 INVITE
+ Max-Forwards: 70
+ Contact: <sip:alice@pc33.atlanta.com>
+ Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+ name=smime.p7m
+ Content-Disposition: attachment; filename=smime.p7m
+ handling=required
+
+ *******************************************************
+ * Content-Type: application/sdp *
+ * *
+ * v=0 *
+ * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
+ * s=- *
+ * t=0 0 *
+ * c=IN IP4 pc33.atlanta.com *
+ * m=audio 3456 RTP/AVP 0 1 3 99 *
+ * a=rtpmap:0 PCMU/8000 *
+ *******************************************************
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 206]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP
+
+ As a means of providing some degree of end-to-end authentication,
+ integrity or confidentiality for SIP header fields, S/MIME can
+ encapsulate entire SIP messages within MIME bodies of type
+ "message/sip" and then apply MIME security to these bodies in the
+ same manner as typical SIP bodies. These encapsulated SIP requests
+ and responses do not constitute a separate dialog or transaction,
+ they are a copy of the "outer" message that is used to verify
+ integrity or to supply additional information.
+
+ If a UAS receives a request that contains a tunneled "message/sip"
+ S/MIME body, it SHOULD include a tunneled "message/sip" body in the
+ response with the same smime-type.
+
+ Any traditional MIME bodies (such as SDP) SHOULD be attached to the
+ "inner" message so that they can also benefit from S/MIME security.
+ Note that "message/sip" bodies can be sent as a part of a MIME
+ "multipart/mixed" body if any unsecured MIME types should also be
+ transmitted in a request.
+
+23.4.1 Integrity and Confidentiality Properties of SIP Headers
+
+ When the S/MIME integrity or confidentiality mechanisms are used,
+ there may be discrepancies between the values in the "inner" message
+ and values in the "outer" message. The rules for handling any such
+ differences for all of the header fields described in this document
+ are given in this section.
+
+ Note that for the purposes of loose timestamping, all SIP messages
+ that tunnel "message/sip" SHOULD contain a Date header in both the
+ "inner" and "outer" headers.
+
+23.4.1.1 Integrity
+
+ Whenever integrity checks are performed, the integrity of a header
+ field should be determined by matching the value of the header field
+ in the signed body with that in the "outer" messages using the
+ comparison rules of SIP as described in 20.
+
+ Header fields that can be legitimately modified by proxy servers are:
+ Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
+ Authorization. If these header fields are not intact end-to-end,
+ implementations SHOULD NOT consider this a breach of security.
+ Changes to any other header fields defined in this document
+ constitute an integrity violation; users MUST be notified of a
+ discrepancy.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 207]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+23.4.1.2 Confidentiality
+
+ When messages are encrypted, header fields may be included in the
+ encrypted body that are not present in the "outer" message.
+
+ Some header fields must always have a plaintext version because they
+ are required header fields in requests and responses - these include:
+
+ To, From, Call-ID, CSeq, Contact. While it is probably not useful to
+ provide an encrypted alternative for the Call-ID, CSeq, or Contact,
+ providing an alternative to the information in the "outer" To or From
+ is permitted. Note that the values in an encrypted body are not used
+ for the purposes of identifying transactions or dialogs - they are
+ merely informational. If the From header field in an encrypted body
+ differs from the value in the "outer" message, the value within the
+ encrypted body SHOULD be displayed to the user, but MUST NOT be used
+ in the "outer" header fields of any future messages.
+
+ Primarily, a user agent will want to encrypt header fields that have
+ an end-to-end semantic, including: Subject, Reply-To, Organization,
+ Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info,
+ Authentication-Info, Expires, In-Reply-To, Require, Supported,
+ Unsupported, Retry-After, User-Agent, Server, and Warning. If any of
+ these header fields are present in an encrypted body, they should be
+ used instead of any "outer" header fields, whether this entails
+ displaying the header field values to users or setting internal
+ states in the UA. They SHOULD NOT however be used in the "outer"
+ headers of any future messages.
+
+ If present, the Date header field MUST always be the same in the
+ "inner" and "outer" headers.
+
+ Since MIME bodies are attached to the "inner" message,
+ implementations will usually encrypt MIME-specific header fields,
+ including: MIME-Version, Content-Type, Content-Length, Content-
+ Language, Content-Encoding and Content-Disposition. The "outer"
+ message will have the proper MIME header fields for S/MIME bodies.
+ These header fields (and any MIME bodies they preface) should be
+ treated as normal MIME header fields and bodies received in a SIP
+ message.
+
+ It is not particularly useful to encrypt the following header fields:
+ Min-Expires, Timestamp, Authorization, Priority, and WWW-
+ Authenticate. This category also includes those header fields that
+ can be changed by proxy servers (described in the preceding section).
+ UAs SHOULD never include these in an "inner" message if they are not
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 208]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ included in the "outer" message. UAs that receive any of these
+ header fields in an encrypted body SHOULD ignore the encrypted
+ values.
+
+ Note that extensions to SIP may define additional header fields; the
+ authors of these extensions should describe the integrity and
+ confidentiality properties of such header fields. If a SIP UA
+ encounters an unknown header field with an integrity violation, it
+ MUST ignore the header field.
+
+23.4.2 Tunneling Integrity and Authentication
+
+ Tunneling SIP messages within S/MIME bodies can provide integrity for
+ SIP header fields if the header fields that the sender wishes to
+ secure are replicated in a "message/sip" MIME body signed with a CMS
+ detached signature.
+
+ Provided that the "message/sip" body contains at least the
+ fundamental dialog identifiers (To, From, Call-ID, CSeq), then a
+ signed MIME body can provide limited authentication. At the very
+ least, if the certificate used to sign the body is unknown to the
+ recipient and cannot be verified, the signature can be used to
+ ascertain that a later request in a dialog was transmitted by the
+ same certificate-holder that initiated the dialog. If the recipient
+ of the signed MIME body has some stronger incentive to trust the
+ certificate (they were able to validate it, they acquired it from a
+ trusted repository, or they have used it frequently) then the
+ signature can be taken as a stronger assertion of the identity of the
+ subject of the certificate.
+
+ In order to eliminate possible confusions about the addition or
+ subtraction of entire header fields, senders SHOULD replicate all
+ header fields from the request within the signed body. Any message
+ bodies that require integrity protection MUST be attached to the
+ "inner" message.
+
+ If a Date header is present in a message with a signed body, the
+ recipient SHOULD compare the header field value with its own internal
+ clock, if applicable. If a significant time discrepancy is detected
+ (on the order of an hour or more), the user agent SHOULD alert the
+ user to the anomaly, and note that it is a potential security breach.
+
+ If an integrity violation in a message is detected by its recipient,
+ the message MAY be rejected with a 403 (Forbidden) response if it is
+ a request, or any existing dialog MAY be terminated. UAs SHOULD
+ notify users of this circumstance and request explicit guidance on
+ how to proceed.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 209]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The following is an example of the use of a tunneled "message/sip"
+ body:
+
+ INVITE sip:bob@biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ To: Bob <sip:bob@biloxi.com>
+ From: Alice <sip:alice@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314159 INVITE
+ Max-Forwards: 70
+ Date: Thu, 21 Feb 2002 13:02:03 GMT
+ Contact: <sip:alice@pc33.atlanta.com>
+ Content-Type: multipart/signed;
+ protocol="application/pkcs7-signature";
+ micalg=sha1; boundary=boundary42
+ Content-Length: 568
+
+ --boundary42
+ Content-Type: message/sip
+
+ INVITE sip:bob@biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ To: Bob <bob@biloxi.com>
+ From: Alice <alice@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314159 INVITE
+ Max-Forwards: 70
+ Date: Thu, 21 Feb 2002 13:02:03 GMT
+ Contact: <sip:alice@pc33.atlanta.com>
+ Content-Type: application/sdp
+ Content-Length: 147
+
+ v=0
+ o=UserA 2890844526 2890844526 IN IP4 here.com
+ s=Session SDP
+ c=IN IP4 pc33.atlanta.com
+ t=0 0
+ m=audio 49172 RTP/AVP 0
+ a=rtpmap:0 PCMU/8000
+
+ --boundary42
+ Content-Type: application/pkcs7-signature; name=smime.p7s
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7s;
+ handling=required
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 210]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+ 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+ n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 7GhIGfHfYT64VQbnj756
+
+ --boundary42-
+
+23.4.3 Tunneling Encryption
+
+ It may also be desirable to use this mechanism to encrypt a
+ "message/sip" MIME body within a CMS EnvelopedData message S/MIME
+ body, but in practice, most header fields are of at least some use to
+ the network; the general use of encryption with S/MIME is to secure
+ message bodies like SDP rather than message headers. Some
+ informational header fields, such as the Subject or Organization
+ could perhaps warrant end-to-end security. Headers defined by future
+ SIP applications might also require obfuscation.
+
+ Another possible application of encrypting header fields is selective
+ anonymity. A request could be constructed with a From header field
+ that contains no personal information (for example,
+ sip:anonymous@anonymizer.invalid). However, a second From header
+ field containing the genuine address-of-record of the originator
+ could be encrypted within a "message/sip" MIME body where it will
+ only be visible to the endpoints of a dialog.
+
+ Note that if this mechanism is used for anonymity, the From header
+ field will no longer be usable by the recipient of a message as an
+ index to their certificate keychain for retrieving the proper
+ S/MIME key to associated with the sender. The message must first
+ be decrypted, and the "inner" From header field MUST be used as an
+ index.
+
+ In order to provide end-to-end integrity, encrypted "message/sip"
+ MIME bodies SHOULD be signed by the sender. This creates a
+ "multipart/signed" MIME body that contains an encrypted body and a
+ signature, both of type "application/pkcs7-mime".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 211]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ In the following example, of an encrypted and signed message, the
+ text boxed in asterisks ("*") is encrypted:
+
+ INVITE sip:bob@biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ To: Bob <sip:bob@biloxi.com>
+ From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
+ Call-ID: a84b4c76e66710
+ CSeq: 314159 INVITE
+ Max-Forwards: 70
+ Date: Thu, 21 Feb 2002 13:02:03 GMT
+ Contact: <sip:pc33.atlanta.com>
+ Content-Type: multipart/signed;
+ protocol="application/pkcs7-signature";
+ micalg=sha1; boundary=boundary42
+ Content-Length: 568
+
+ --boundary42
+ Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+ name=smime.p7m
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7m
+ handling=required
+ Content-Length: 231
+
+ ***********************************************************
+ * Content-Type: message/sip *
+ * *
+ * INVITE sip:bob@biloxi.com SIP/2.0 *
+ * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
+ * To: Bob <bob@biloxi.com> *
+ * From: Alice <alice@atlanta.com>;tag=1928301774 *
+ * Call-ID: a84b4c76e66710 *
+ * CSeq: 314159 INVITE *
+ * Max-Forwards: 70 *
+ * Date: Thu, 21 Feb 2002 13:02:03 GMT *
+ * Contact: <sip:alice@pc33.atlanta.com> *
+ * *
+ * Content-Type: application/sdp *
+ * *
+ * v=0 *
+ * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
+ * s=Session SDP *
+ * t=0 0 *
+ * c=IN IP4 pc33.atlanta.com *
+ * m=audio 3456 RTP/AVP 0 1 3 99 *
+ * a=rtpmap:0 PCMU/8000 *
+ ***********************************************************
+
+
+
+Rosenberg, et. al. Standards Track [Page 212]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ --boundary42
+ Content-Type: application/pkcs7-signature; name=smime.p7s
+ Content-Transfer-Encoding: base64
+ Content-Disposition: attachment; filename=smime.p7s;
+ handling=required
+
+ ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+ 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+ n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+ 7GhIGfHfYT64VQbnj756
+
+ --boundary42-
+
+24 Examples
+
+ In the following examples, we often omit the message body and the
+ corresponding Content-Length and Content-Type header fields for
+ brevity.
+
+24.1 Registration
+
+ Bob registers on start-up. The message flow is shown in Figure 9.
+ Note that the authentication usually required for registration is not
+ shown for simplicity.
+
+ biloxi.com Bob's
+ registrar softphone
+ | |
+ | REGISTER F1 |
+ |<---------------|
+ | 200 OK F2 |
+ |--------------->|
+
+ Figure 9: SIP Registration Example
+
+ F1 REGISTER Bob -> Registrar
+
+ REGISTER sip:registrar.biloxi.com SIP/2.0
+ Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
+ Max-Forwards: 70
+ To: Bob <sip:bob@biloxi.com>
+ From: Bob <sip:bob@biloxi.com>;tag=456248
+ Call-ID: 843817637684230@998sdasdh09
+ CSeq: 1826 REGISTER
+ Contact: <sip:bob@192.0.2.4>
+ Expires: 7200
+ Content-Length: 0
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 213]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The registration expires after two hours. The registrar responds
+ with a 200 OK:
+
+ F2 200 OK Registrar -> Bob
+
+ SIP/2.0 200 OK
+ Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
+ ;received=192.0.2.4
+ To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
+ From: Bob <sip:bob@biloxi.com>;tag=456248
+ Call-ID: 843817637684230@998sdasdh09
+ CSeq: 1826 REGISTER
+ Contact: <sip:bob@192.0.2.4>
+ Expires: 7200
+ Content-Length: 0
+
+24.2 Session Setup
+
+ This example contains the full details of the example session setup
+ in Section 4. The message flow is shown in Figure 1. Note that
+ these flows show the minimum required set of header fields - some
+ other header fields such as Allow and Supported would normally be
+ present.
+
+F1 INVITE Alice -> atlanta.com proxy
+
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+Max-Forwards: 70
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 142
+
+(Alice's SDP not shown)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 214]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+F2 100 Trying atlanta.com proxy -> Alice
+
+SIP/2.0 100 Trying
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Content-Length: 0
+
+F3 INVITE atlanta.com proxy -> biloxi.com proxy
+
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+Max-Forwards: 69
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 142
+
+(Alice's SDP not shown)
+
+F4 100 Trying biloxi.com proxy -> atlanta.com proxy
+
+SIP/2.0 100 Trying
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+ ;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 215]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+F5 INVITE biloxi.com proxy -> Bob
+
+INVITE sip:bob@192.0.2.4 SIP/2.0
+Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+ ;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+Max-Forwards: 68
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 142
+
+(Alice's SDP not shown)
+
+F6 180 Ringing Bob -> biloxi.com proxy
+
+SIP/2.0 180 Ringing
+Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
+ ;received=192.0.2.3
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+ ;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+Contact: <sip:bob@192.0.2.4>
+CSeq: 314159 INVITE
+Content-Length: 0
+
+F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
+
+SIP/2.0 180 Ringing
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+ ;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+Contact: <sip:bob@192.0.2.4>
+CSeq: 314159 INVITE
+Content-Length: 0
+
+
+
+Rosenberg, et. al. Standards Track [Page 216]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+F8 180 Ringing atlanta.com proxy -> Alice
+
+SIP/2.0 180 Ringing
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+Contact: <sip:bob@192.0.2.4>
+CSeq: 314159 INVITE
+Content-Length: 0
+
+F9 200 OK Bob -> biloxi.com proxy
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
+ ;received=192.0.2.3
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+ ;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:bob@192.0.2.4>
+Content-Type: application/sdp
+Content-Length: 131
+
+(Bob's SDP not shown)
+
+F10 200 OK biloxi.com proxy -> atlanta.com proxy
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+ ;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:bob@192.0.2.4>
+Content-Type: application/sdp
+Content-Length: 131
+
+(Bob's SDP not shown)
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 217]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+F11 200 OK atlanta.com proxy -> Alice
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+ ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:bob@192.0.2.4>
+Content-Type: application/sdp
+Content-Length: 131
+
+(Bob's SDP not shown)
+
+F12 ACK Alice -> Bob
+
+ACK sip:bob@192.0.2.4 SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
+Max-Forwards: 70
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 ACK
+Content-Length: 0
+
+ The media session between Alice and Bob is now established.
+
+ Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq
+ numbering space, which, in this example, begins with 231. Since Bob
+ is making the request, the To and From URIs and tags have been
+ swapped.
+
+F13 BYE Bob -> Alice
+
+BYE sip:alice@pc33.atlanta.com SIP/2.0
+Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
+Max-Forwards: 70
+From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+To: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 231 BYE
+Content-Length: 0
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 218]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+F14 200 OK Alice -> Bob
+
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
+From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+To: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 231 BYE
+Content-Length: 0
+
+ The SIP Call Flows document [40] contains further examples of SIP
+ messages.
+
+25 Augmented BNF for the SIP Protocol
+
+ All of the mechanisms specified in this document are described in
+ both prose and an augmented Backus-Naur Form (BNF) defined in RFC
+ 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that
+ are used by this specification, and not repeated here. Implementers
+ need to be familiar with the notation and content of RFC 2234 in
+ order to understand this specification. Certain basic rules are in
+ uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle
+ brackets are used within definitions to clarify the use of rule
+ names.
+
+ The use of square brackets is redundant syntactically. It is used as
+ a semantic hint that the specific parameter is optional to use.
+
+25.1 Basic Rules
+
+ The following rules are used throughout this specification to
+ describe basic parsing constructs. The US-ASCII coded character set
+ is defined by ANSI X3.4-1986.
+
+ alphanum = ALPHA / DIGIT
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 219]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Several rules are incorporated from RFC 2396 [5] but are updated to
+ make them compliant with RFC 2234 [10]. These include:
+
+ reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
+ / "$" / ","
+ unreserved = alphanum / mark
+ mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
+ / "(" / ")"
+ escaped = "%" HEXDIG HEXDIG
+
+ SIP header field values can be folded onto multiple lines if the
+ continuation line begins with a space or horizontal tab. All linear
+ white space, including folding, has the same semantics as SP. A
+ recipient MAY replace any linear white space with a single SP before
+ interpreting the field value or forwarding the message downstream.
+ This is intended to behave exactly as HTTP/1.1 as described in RFC
+ 2616 [8]. The SWS construct is used when linear white space is
+ optional, generally between tokens and separators.
+
+ LWS = [*WSP CRLF] 1*WSP ; linear whitespace
+ SWS = [LWS] ; sep whitespace
+
+ To separate the header name from the rest of value, a colon is used,
+ which, by the above rule, allows whitespace before, but no line
+ break, and whitespace after, including a linebreak. The HCOLON
+ defines this construct.
+
+ HCOLON = *( SP / HTAB ) ":" SWS
+
+ The TEXT-UTF8 rule is only used for descriptive field contents and
+ values that are not intended to be interpreted by the message parser.
+ Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC
+ 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field
+ contents that are n t quoted strings, where leading and trailing LWS
+ is not meaningful. In this regard, SIP differs from HTTP, which uses
+ the ISO 8859-1 character set.
+
+ TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
+ TEXT-UTF8char = %x21-7E / UTF8-NONASCII
+ UTF8-NONASCII = %xC0-DF 1UTF8-CONT
+ / %xE0-EF 2UTF8-CONT
+ / %xF0-F7 3UTF8-CONT
+ / %xF8-Fb 4UTF8-CONT
+ / %xFC-FD 5UTF8-CONT
+ UTF8-CONT = %x80-BF
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 220]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of
+ a header field continuation. It is expected that the folding LWS
+ will be replaced with a single SP before interpretation of the TEXT-
+ UTF8-TRIM value.
+
+ Hexadecimal numeric characters are used in several protocol elements.
+ Some elements (authentication) force hex alphas to be lower case.
+
+ LHEX = DIGIT / %x61-66 ;lowercase a-f
+
+ Many SIP header field values consist of words separated by LWS or
+ special characters. Unless otherwise stated, tokens are case-
+ insensitive. These special characters MUST be in a quoted string to
+ be used within a parameter value. The word construct is used in
+ Call-ID to allow most separators to be used.
+
+ token = 1*(alphanum / "-" / "." / "!" / "%" / "*"
+ / "_" / "+" / "`" / "'" / "~" )
+ separators = "(" / ")" / "<" / ">" / "@" /
+ "," / ";" / ":" / "\" / DQUOTE /
+ "/" / "[" / "]" / "?" / "=" /
+ "{" / "}" / SP / HTAB
+ word = 1*(alphanum / "-" / "." / "!" / "%" / "*" /
+ "_" / "+" / "`" / "'" / "~" /
+ "(" / ")" / "<" / ">" /
+ ":" / "\" / DQUOTE /
+ "/" / "[" / "]" / "?" /
+ "{" / "}" )
+
+ When tokens are used or separators are used between elements,
+ whitespace is often allowed before or after these characters:
+
+ STAR = SWS "*" SWS ; asterisk
+ SLASH = SWS "/" SWS ; slash
+ EQUAL = SWS "=" SWS ; equal
+ LPAREN = SWS "(" SWS ; left parenthesis
+ RPAREN = SWS ")" SWS ; right parenthesis
+ RAQUOT = ">" SWS ; right angle quote
+ LAQUOT = SWS "<"; left angle quote
+ COMMA = SWS "," SWS ; comma
+ SEMI = SWS ";" SWS ; semicolon
+ COLON = SWS ":" SWS ; colon
+ LDQUOT = SWS DQUOTE; open double quotation mark
+ RDQUOT = DQUOTE SWS ; close double quotation mark
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 221]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Comments can be included in some SIP header fields by surrounding the
+ comment text with parentheses. Comments are only allowed in fields
+ containing "comment" as part of their field value definition. In all
+ other fields, parentheses are considered part of the field value.
+
+ comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
+ ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII
+ / LWS
+
+ ctext includes all chars except left and right parens and backslash.
+ A string of text is parsed as a single word if it is quoted using
+ double-quote marks. In quoted strings, quotation marks (") and
+ backslashes (\) need to be escaped.
+
+ quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
+ qdtext = LWS / %x21 / %x23-5B / %x5D-7E
+ / UTF8-NONASCII
+
+ The backslash character ("\") MAY be used as a single-character
+ quoting mechanism only within quoted-string and comment constructs.
+ Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this
+ mechanism to avoid conflict with line folding and header separation.
+
+quoted-pair = "\" (%x00-09 / %x0B-0C
+ / %x0E-7F)
+
+SIP-URI = "sip:" [ userinfo ] hostport
+ uri-parameters [ headers ]
+SIPS-URI = "sips:" [ userinfo ] hostport
+ uri-parameters [ headers ]
+userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
+user = 1*( unreserved / escaped / user-unreserved )
+user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
+password = *( unreserved / escaped /
+ "&" / "=" / "+" / "$" / "," )
+hostport = host [ ":" port ]
+host = hostname / IPv4address / IPv6reference
+hostname = *( domainlabel "." ) toplabel [ "." ]
+domainlabel = alphanum
+ / alphanum *( alphanum / "-" ) alphanum
+toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 222]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
+IPv6reference = "[" IPv6address "]"
+IPv6address = hexpart [ ":" IPv4address ]
+hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
+hexseq = hex4 *( ":" hex4)
+hex4 = 1*4HEXDIG
+port = 1*DIGIT
+
+ The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note,
+ however, that any characters allowed there that are not allowed in
+ the user part of the SIP URI MUST be escaped.
+
+uri-parameters = *( ";" uri-parameter)
+uri-parameter = transport-param / user-param / method-param
+ / ttl-param / maddr-param / lr-param / other-param
+transport-param = "transport="
+ ( "udp" / "tcp" / "sctp" / "tls"
+ / other-transport)
+other-transport = token
+user-param = "user=" ( "phone" / "ip" / other-user)
+other-user = token
+method-param = "method=" Method
+ttl-param = "ttl=" ttl
+maddr-param = "maddr=" host
+lr-param = "lr"
+other-param = pname [ "=" pvalue ]
+pname = 1*paramchar
+pvalue = 1*paramchar
+paramchar = param-unreserved / unreserved / escaped
+param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
+
+headers = "?" header *( "&" header )
+header = hname "=" hvalue
+hname = 1*( hnv-unreserved / unreserved / escaped )
+hvalue = *( hnv-unreserved / unreserved / escaped )
+hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$"
+
+SIP-message = Request / Response
+Request = Request-Line
+ *( message-header )
+ CRLF
+ [ message-body ]
+Request-Line = Method SP Request-URI SP SIP-Version CRLF
+Request-URI = SIP-URI / SIPS-URI / absoluteURI
+absoluteURI = scheme ":" ( hier-part / opaque-part )
+hier-part = ( net-path / abs-path ) [ "?" query ]
+net-path = "//" authority [ abs-path ]
+abs-path = "/" path-segments
+
+
+
+Rosenberg, et. al. Standards Track [Page 223]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+opaque-part = uric-no-slash *uric
+uric = reserved / unreserved / escaped
+uric-no-slash = unreserved / escaped / ";" / "?" / ":" / "@"
+ / "&" / "=" / "+" / "$" / ","
+path-segments = segment *( "/" segment )
+segment = *pchar *( ";" param )
+param = *pchar
+pchar = unreserved / escaped /
+ ":" / "@" / "&" / "=" / "+" / "$" / ","
+scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
+authority = srvr / reg-name
+srvr = [ [ userinfo "@" ] hostport ]
+reg-name = 1*( unreserved / escaped / "$" / ","
+ / ";" / ":" / "@" / "&" / "=" / "+" )
+query = *uric
+SIP-Version = "SIP" "/" 1*DIGIT "." 1*DIGIT
+
+message-header = (Accept
+ / Accept-Encoding
+ / Accept-Language
+ / Alert-Info
+ / Allow
+ / Authentication-Info
+ / Authorization
+ / Call-ID
+ / Call-Info
+ / Contact
+ / Content-Disposition
+ / Content-Encoding
+ / Content-Language
+ / Content-Length
+ / Content-Type
+ / CSeq
+ / Date
+ / Error-Info
+ / Expires
+ / From
+ / In-Reply-To
+ / Max-Forwards
+ / MIME-Version
+ / Min-Expires
+ / Organization
+ / Priority
+ / Proxy-Authenticate
+ / Proxy-Authorization
+ / Proxy-Require
+ / Record-Route
+ / Reply-To
+
+
+
+Rosenberg, et. al. Standards Track [Page 224]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ / Require
+ / Retry-After
+ / Route
+ / Server
+ / Subject
+ / Supported
+ / Timestamp
+ / To
+ / Unsupported
+ / User-Agent
+ / Via
+ / Warning
+ / WWW-Authenticate
+ / extension-header) CRLF
+
+INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps
+ACKm = %x41.43.4B ; ACK in caps
+OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
+BYEm = %x42.59.45 ; BYE in caps
+CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps
+REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps
+Method = INVITEm / ACKm / OPTIONSm / BYEm
+ / CANCELm / REGISTERm
+ / extension-method
+extension-method = token
+Response = Status-Line
+ *( message-header )
+ CRLF
+ [ message-body ]
+
+Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
+Status-Code = Informational
+ / Redirection
+ / Success
+ / Client-Error
+ / Server-Error
+ / Global-Failure
+ / extension-code
+extension-code = 3DIGIT
+Reason-Phrase = *(reserved / unreserved / escaped
+ / UTF8-NONASCII / UTF8-CONT / SP / HTAB)
+
+Informational = "100" ; Trying
+ / "180" ; Ringing
+ / "181" ; Call Is Being Forwarded
+ / "182" ; Queued
+ / "183" ; Session Progress
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 225]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Success = "200" ; OK
+
+Redirection = "300" ; Multiple Choices
+ / "301" ; Moved Permanently
+ / "302" ; Moved Temporarily
+ / "305" ; Use Proxy
+ / "380" ; Alternative Service
+
+Client-Error = "400" ; Bad Request
+ / "401" ; Unauthorized
+ / "402" ; Payment Required
+ / "403" ; Forbidden
+ / "404" ; Not Found
+ / "405" ; Method Not Allowed
+ / "406" ; Not Acceptable
+ / "407" ; Proxy Authentication Required
+ / "408" ; Request Timeout
+ / "410" ; Gone
+ / "413" ; Request Entity Too Large
+ / "414" ; Request-URI Too Large
+ / "415" ; Unsupported Media Type
+ / "416" ; Unsupported URI Scheme
+ / "420" ; Bad Extension
+ / "421" ; Extension Required
+ / "423" ; Interval Too Brief
+ / "480" ; Temporarily not available
+ / "481" ; Call Leg/Transaction Does Not Exist
+ / "482" ; Loop Detected
+ / "483" ; Too Many Hops
+ / "484" ; Address Incomplete
+ / "485" ; Ambiguous
+ / "486" ; Busy Here
+ / "487" ; Request Terminated
+ / "488" ; Not Acceptable Here
+ / "491" ; Request Pending
+ / "493" ; Undecipherable
+
+Server-Error = "500" ; Internal Server Error
+ / "501" ; Not Implemented
+ / "502" ; Bad Gateway
+ / "503" ; Service Unavailable
+ / "504" ; Server Time-out
+ / "505" ; SIP Version not supported
+ / "513" ; Message Too Large
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 226]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Global-Failure = "600" ; Busy Everywhere
+ / "603" ; Decline
+ / "604" ; Does not exist anywhere
+ / "606" ; Not Acceptable
+
+Accept = "Accept" HCOLON
+ [ accept-range *(COMMA accept-range) ]
+accept-range = media-range *(SEMI accept-param)
+media-range = ( "*/*"
+ / ( m-type SLASH "*" )
+ / ( m-type SLASH m-subtype )
+ ) *( SEMI m-parameter )
+accept-param = ("q" EQUAL qvalue) / generic-param
+qvalue = ( "0" [ "." 0*3DIGIT ] )
+ / ( "1" [ "." 0*3("0") ] )
+generic-param = token [ EQUAL gen-value ]
+gen-value = token / host / quoted-string
+
+Accept-Encoding = "Accept-Encoding" HCOLON
+ [ encoding *(COMMA encoding) ]
+encoding = codings *(SEMI accept-param)
+codings = content-coding / "*"
+content-coding = token
+
+Accept-Language = "Accept-Language" HCOLON
+ [ language *(COMMA language) ]
+language = language-range *(SEMI accept-param)
+language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
+
+Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)
+alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
+
+Allow = "Allow" HCOLON [Method *(COMMA Method)]
+
+Authorization = "Authorization" HCOLON credentials
+credentials = ("Digest" LWS digest-response)
+ / other-response
+digest-response = dig-resp *(COMMA dig-resp)
+dig-resp = username / realm / nonce / digest-uri
+ / dresponse / algorithm / cnonce
+ / opaque / message-qop
+ / nonce-count / auth-param
+username = "username" EQUAL username-value
+username-value = quoted-string
+digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
+digest-uri-value = rquest-uri ; Equal to request-uri as specified
+ by HTTP/1.1
+message-qop = "qop" EQUAL qop-value
+
+
+
+Rosenberg, et. al. Standards Track [Page 227]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+cnonce = "cnonce" EQUAL cnonce-value
+cnonce-value = nonce-value
+nonce-count = "nc" EQUAL nc-value
+nc-value = 8LHEX
+dresponse = "response" EQUAL request-digest
+request-digest = LDQUOT 32LHEX RDQUOT
+auth-param = auth-param-name EQUAL
+ ( token / quoted-string )
+auth-param-name = token
+other-response = auth-scheme LWS auth-param
+ *(COMMA auth-param)
+auth-scheme = token
+
+Authentication-Info = "Authentication-Info" HCOLON ainfo
+ *(COMMA ainfo)
+ainfo = nextnonce / message-qop
+ / response-auth / cnonce
+ / nonce-count
+nextnonce = "nextnonce" EQUAL nonce-value
+response-auth = "rspauth" EQUAL response-digest
+response-digest = LDQUOT *LHEX RDQUOT
+
+Call-ID = ( "Call-ID" / "i" ) HCOLON callid
+callid = word [ "@" word ]
+
+Call-Info = "Call-Info" HCOLON info *(COMMA info)
+info = LAQUOT absoluteURI RAQUOT *( SEMI info-param)
+info-param = ( "purpose" EQUAL ( "icon" / "info"
+ / "card" / token ) ) / generic-param
+
+Contact = ("Contact" / "m" ) HCOLON
+ ( STAR / (contact-param *(COMMA contact-param)))
+contact-param = (name-addr / addr-spec) *(SEMI contact-params)
+name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
+addr-spec = SIP-URI / SIPS-URI / absoluteURI
+display-name = *(token LWS)/ quoted-string
+
+contact-params = c-p-q / c-p-expires
+ / contact-extension
+c-p-q = "q" EQUAL qvalue
+c-p-expires = "expires" EQUAL delta-seconds
+contact-extension = generic-param
+delta-seconds = 1*DIGIT
+
+Content-Disposition = "Content-Disposition" HCOLON
+ disp-type *( SEMI disp-param )
+disp-type = "render" / "session" / "icon" / "alert"
+ / disp-extension-token
+
+
+
+Rosenberg, et. al. Standards Track [Page 228]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+disp-param = handling-param / generic-param
+handling-param = "handling" EQUAL
+ ( "optional" / "required"
+ / other-handling )
+other-handling = token
+disp-extension-token = token
+
+Content-Encoding = ( "Content-Encoding" / "e" ) HCOLON
+ content-coding *(COMMA content-coding)
+
+Content-Language = "Content-Language" HCOLON
+ language-tag *(COMMA language-tag)
+language-tag = primary-tag *( "-" subtag )
+primary-tag = 1*8ALPHA
+subtag = 1*8ALPHA
+
+Content-Length = ( "Content-Length" / "l" ) HCOLON 1*DIGIT
+Content-Type = ( "Content-Type" / "c" ) HCOLON media-type
+media-type = m-type SLASH m-subtype *(SEMI m-parameter)
+m-type = discrete-type / composite-type
+discrete-type = "text" / "image" / "audio" / "video"
+ / "application" / extension-token
+composite-type = "message" / "multipart" / extension-token
+extension-token = ietf-token / x-token
+ietf-token = token
+x-token = "x-" token
+m-subtype = extension-token / iana-token
+iana-token = token
+m-parameter = m-attribute EQUAL m-value
+m-attribute = token
+m-value = token / quoted-string
+
+CSeq = "CSeq" HCOLON 1*DIGIT LWS Method
+
+Date = "Date" HCOLON SIP-date
+SIP-date = rfc1123-date
+rfc1123-date = wkday "," SP date1 SP time SP "GMT"
+date1 = 2DIGIT SP month SP 4DIGIT
+ ; day month year (e.g., 02 Jun 1982)
+time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+ ; 00:00:00 - 23:59:59
+wkday = "Mon" / "Tue" / "Wed"
+ / "Thu" / "Fri" / "Sat" / "Sun"
+month = "Jan" / "Feb" / "Mar" / "Apr"
+ / "May" / "Jun" / "Jul" / "Aug"
+ / "Sep" / "Oct" / "Nov" / "Dec"
+
+Error-Info = "Error-Info" HCOLON error-uri *(COMMA error-uri)
+
+
+
+Rosenberg, et. al. Standards Track [Page 229]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
+
+Expires = "Expires" HCOLON delta-seconds
+From = ( "From" / "f" ) HCOLON from-spec
+from-spec = ( name-addr / addr-spec )
+ *( SEMI from-param )
+from-param = tag-param / generic-param
+tag-param = "tag" EQUAL token
+
+In-Reply-To = "In-Reply-To" HCOLON callid *(COMMA callid)
+
+Max-Forwards = "Max-Forwards" HCOLON 1*DIGIT
+
+MIME-Version = "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
+
+Min-Expires = "Min-Expires" HCOLON delta-seconds
+
+Organization = "Organization" HCOLON [TEXT-UTF8-TRIM]
+
+Priority = "Priority" HCOLON priority-value
+priority-value = "emergency" / "urgent" / "normal"
+ / "non-urgent" / other-priority
+other-priority = token
+
+Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge
+challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
+ / other-challenge
+other-challenge = auth-scheme LWS auth-param
+ *(COMMA auth-param)
+digest-cln = realm / domain / nonce
+ / opaque / stale / algorithm
+ / qop-options / auth-param
+realm = "realm" EQUAL realm-value
+realm-value = quoted-string
+domain = "domain" EQUAL LDQUOT URI
+ *( 1*SP URI ) RDQUOT
+URI = absoluteURI / abs-path
+nonce = "nonce" EQUAL nonce-value
+nonce-value = quoted-string
+opaque = "opaque" EQUAL quoted-string
+stale = "stale" EQUAL ( "true" / "false" )
+algorithm = "algorithm" EQUAL ( "MD5" / "MD5-sess"
+ / token )
+qop-options = "qop" EQUAL LDQUOT qop-value
+ *("," qop-value) RDQUOT
+qop-value = "auth" / "auth-int" / token
+
+Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
+
+
+
+Rosenberg, et. al. Standards Track [Page 230]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Proxy-Require = "Proxy-Require" HCOLON option-tag
+ *(COMMA option-tag)
+option-tag = token
+
+Record-Route = "Record-Route" HCOLON rec-route *(COMMA rec-route)
+rec-route = name-addr *( SEMI rr-param )
+rr-param = generic-param
+
+Reply-To = "Reply-To" HCOLON rplyto-spec
+rplyto-spec = ( name-addr / addr-spec )
+ *( SEMI rplyto-param )
+rplyto-param = generic-param
+Require = "Require" HCOLON option-tag *(COMMA option-tag)
+
+Retry-After = "Retry-After" HCOLON delta-seconds
+ [ comment ] *( SEMI retry-param )
+
+retry-param = ("duration" EQUAL delta-seconds)
+ / generic-param
+
+Route = "Route" HCOLON route-param *(COMMA route-param)
+route-param = name-addr *( SEMI rr-param )
+
+Server = "Server" HCOLON server-val *(LWS server-val)
+server-val = product / comment
+product = token [SLASH product-version]
+product-version = token
+
+Subject = ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
+
+Supported = ( "Supported" / "k" ) HCOLON
+ [option-tag *(COMMA option-tag)]
+
+Timestamp = "Timestamp" HCOLON 1*(DIGIT)
+ [ "." *(DIGIT) ] [ LWS delay ]
+delay = *(DIGIT) [ "." *(DIGIT) ]
+
+To = ( "To" / "t" ) HCOLON ( name-addr
+ / addr-spec ) *( SEMI to-param )
+to-param = tag-param / generic-param
+
+Unsupported = "Unsupported" HCOLON option-tag *(COMMA option-tag)
+User-Agent = "User-Agent" HCOLON server-val *(LWS server-val)
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 231]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Via = ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
+via-parm = sent-protocol LWS sent-by *( SEMI via-params )
+via-params = via-ttl / via-maddr
+ / via-received / via-branch
+ / via-extension
+via-ttl = "ttl" EQUAL ttl
+via-maddr = "maddr" EQUAL host
+via-received = "received" EQUAL (IPv4address / IPv6address)
+via-branch = "branch" EQUAL token
+via-extension = generic-param
+sent-protocol = protocol-name SLASH protocol-version
+ SLASH transport
+protocol-name = "SIP" / token
+protocol-version = token
+transport = "UDP" / "TCP" / "TLS" / "SCTP"
+ / other-transport
+sent-by = host [ COLON port ]
+ttl = 1*3DIGIT ; 0 to 255
+
+Warning = "Warning" HCOLON warning-value *(COMMA warning-value)
+warning-value = warn-code SP warn-agent SP warn-text
+warn-code = 3DIGIT
+warn-agent = hostport / pseudonym
+ ; the name or pseudonym of the server adding
+ ; the Warning header, for use in debugging
+warn-text = quoted-string
+pseudonym = token
+
+WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
+
+extension-header = header-name HCOLON header-value
+header-name = token
+header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
+message-body = *OCTET
+
+26 Security Considerations: Threat Model and Security Usage
+ Recommendations
+
+ SIP is not an easy protocol to secure. Its use of intermediaries,
+ its multi-faceted trust relationships, its expected usage between
+ elements with no trust at all, and its user-to-user operation make
+ security far from trivial. Security solutions are needed that are
+ deployable today, without extensive coordination, in a wide variety
+ of environments and usages. In order to meet these diverse needs,
+ several distinct mechanisms applicable to different aspects and
+ usages of SIP will be required.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 232]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Note that the security of SIP signaling itself has no bearing on the
+ security of protocols used in concert with SIP such as RTP, or with
+ the security implications of any specific bodies SIP might carry
+ (although MIME security plays a substantial role in securing SIP).
+ Any media associated with a session can be encrypted end-to-end
+ independently of any associated SIP signaling. Media encryption is
+ outside the scope of this document.
+
+ The considerations that follow first examine a set of classic threat
+ models that broadly identify the security needs of SIP. The set of
+ security services required to address these threats is then detailed,
+ followed by an explanation of several security mechanisms that can be
+ used to provide these services. Next, the requirements for
+ implementers of SIP are enumerated, along with exemplary deployments
+ in which these security mechanisms could be used to improve the
+ security of SIP. Some notes on privacy conclude this section.
+
+26.1 Attacks and Threat Models
+
+ This section details some threats that should be common to most
+ deployments of SIP. These threats have been chosen specifically to
+ illustrate each of the security services that SIP requires.
+
+ The following examples by no means provide an exhaustive list of the
+ threats against SIP; rather, these are "classic" threats that
+ demonstrate the need for particular security services that can
+ potentially prevent whole categories of threats.
+
+ These attacks assume an environment in which attackers can
+ potentially read any packet on the network - it is anticipated that
+ SIP will frequently be used on the public Internet. Attackers on the
+ network may be able to modify packets (perhaps at some compromised
+ intermediary). Attackers may wish to steal services, eavesdrop on
+ communications, or disrupt sessions.
+
+26.1.1 Registration Hijacking
+
+ The SIP registration mechanism allows a user agent to identify itself
+ to a registrar as a device at which a user (designated by an address
+ of record) is located. A registrar assesses the identity asserted in
+ the From header field of a REGISTER message to determine whether this
+ request can modify the contact addresses associated with the
+ address-of-record in the To header field. While these two fields are
+ frequently the same, there are many valid deployments in which a
+ third-party may register contacts on a user's behalf.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 233]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The From header field of a SIP request, however, can be modified
+ arbitrarily by the owner of a UA, and this opens the door to
+ malicious registrations. An attacker that successfully impersonates
+ a party authorized to change contacts associated with an address-of-
+ record could, for example, de-register all existing contacts for a
+ URI and then register their own device as the appropriate contact
+ address, thereby directing all requests for the affected user to the
+ attacker's device.
+
+ This threat belongs to a family of threats that rely on the absence
+ of cryptographic assurance of a request's originator. Any SIP UAS
+ that represents a valuable service (a gateway that interworks SIP
+ requests with traditional telephone calls, for example) might want to
+ control access to its resources by authenticating requests that it
+ receives. Even end-user UAs, for example SIP phones, have an
+ interest in ascertaining the identities of originators of requests.
+
+ This threat demonstrates the need for security services that enable
+ SIP entities to authenticate the originators of requests.
+
+26.1.2 Impersonating a Server
+
+ The domain to which a request is destined is generally specified in
+ the Request-URI. UAs commonly contact a server in this domain
+ directly in order to deliver a request. However, there is always a
+ possibility that an attacker could impersonate the remote server, and
+ that the UA's request could be intercepted by some other party.
+
+ For example, consider a case in which a redirect server at one
+ domain, chicago.com, impersonates a redirect server at another
+ domain, biloxi.com. A user agent sends a request to biloxi.com, but
+ the redirect server at chicago.com answers with a forged response
+ that has appropriate SIP header fields for a response from
+ biloxi.com. The forged contact addresses in the redirection response
+ could direct the originating UA to inappropriate or insecure
+ resources, or simply prevent requests for biloxi.com from succeeding.
+
+ This family of threats has a vast membership, many of which are
+ critical. As a converse to the registration hijacking threat,
+ consider the case in which a registration sent to biloxi.com is
+ intercepted by chicago.com, which replies to the intercepted
+ registration with a forged 301 (Moved Permanently) response. This
+ response might seem to come from biloxi.com yet designate chicago.com
+ as the appropriate registrar. All future REGISTER requests from the
+ originating UA would then go to chicago.com.
+
+ Prevention of this threat requires a means by which UAs can
+ authenticate the servers to whom they send requests.
+
+
+
+Rosenberg, et. al. Standards Track [Page 234]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+26.1.3 Tampering with Message Bodies
+
+ As a matter of course, SIP UAs route requests through trusted proxy
+ servers. Regardless of how that trust is established (authentication
+ of proxies is discussed elsewhere in this section), a UA may trust a
+ proxy server to route a request, but not to inspect or possibly
+ modify the bodies contained in that request.
+
+ Consider a UA that is using SIP message bodies to communicate session
+ encryption keys for a media session. Although it trusts the proxy
+ server of the domain it is contacting to deliver signaling properly,
+ it may not want the administrators of that domain to be capable of
+ decrypting any subsequent media session. Worse yet, if the proxy
+ server were actively malicious, it could modify the session key,
+ either acting as a man-in-the-middle, or perhaps changing the
+ security characteristics requested by the originating UA.
+
+ This family of threats applies not only to session keys, but to most
+ conceivable forms of content carried end-to-end in SIP. These might
+ include MIME bodies that should be rendered to the user, SDP, or
+ encapsulated telephony signals, among others. Attackers might
+ attempt to modify SDP bodies, for example, in order to point RTP
+ media streams to a wiretapping device in order to eavesdrop on
+ subsequent voice communications.
+
+ Also note that some header fields in SIP are meaningful end-to-end,
+ for example, Subject. UAs might be protective of these header fields
+ as well as bodies (a malicious intermediary changing the Subject
+ header field might make an important request appear to be spam, for
+ example). However, since many header fields are legitimately
+ inspected or altered by proxy servers as a request is routed, not all
+ header fields should be secured end-to-end.
+
+ For these reasons, the UA might want to secure SIP message bodies,
+ and in some limited cases header fields, end-to-end. The security
+ services required for bodies include confidentiality, integrity, and
+ authentication. These end-to-end services should be independent of
+ the means used to secure interactions with intermediaries such as
+ proxy servers.
+
+26.1.4 Tearing Down Sessions
+
+ Once a dialog has been established by initial messaging, subsequent
+ requests can be sent that modify the state of the dialog and/or
+ session. It is critical that principals in a session can be certain
+ that such requests are not forged by attackers.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 235]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Consider a case in which a third-party attacker captures some initial
+ messages in a dialog shared by two parties in order to learn the
+ parameters of the session (To tag, From tag, and so forth) and then
+ inserts a BYE request into the session. The attacker could opt to
+ forge the request such that it seemed to come from either
+ participant. Once the BYE is received by its target, the session
+ will be torn down prematurely.
+
+ Similar mid-session threats include the transmission of forged re-
+ INVITEs that alter the session (possibly to reduce session security
+ or redirect media streams as part of a wiretapping attack).
+
+ The most effective countermeasure to this threat is the
+ authentication of the sender of the BYE. In this instance, the
+ recipient needs only know that the BYE came from the same party with
+ whom the corresponding dialog was established (as opposed to
+ ascertaining the absolute identity of the sender). Also, if the
+ attacker is unable to learn the parameters of the session due to
+ confidentiality, it would not be possible to forge the BYE. However,
+ some intermediaries (like proxy servers) will need to inspect those
+ parameters as the session is established.
+
+26.1.5 Denial of Service and Amplification
+
+ Denial-of-service attacks focus on rendering a particular network
+ element unavailable, usually by directing an excessive amount of
+ network traffic at its interfaces. A distributed denial-of-service
+ attack allows one network user to cause multiple network hosts to
+ flood a target host with a large amount of network traffic.
+
+ In many architectures, SIP proxy servers face the public Internet in
+ order to accept requests from worldwide IP endpoints. SIP creates a
+ number of potential opportunities for distributed denial-of-service
+ attacks that must be recognized and addressed by the implementers and
+ operators of SIP systems.
+
+ Attackers can create bogus requests that contain a falsified source
+ IP address and a corresponding Via header field that identify a
+ targeted host as the originator of the request and then send this
+ request to a large number of SIP network elements, thereby using
+ hapless SIP UAs or proxies to generate denial-of-service traffic
+ aimed at the target.
+
+ Similarly, attackers might use falsified Route header field values in
+ a request that identify the target host and then send such messages
+ to forking proxies that will amplify messaging sent to the target.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 236]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Record-Route could be used to similar effect when the attacker is
+ certain that the SIP dialog initiated by the request will result in
+ numerous transactions originating in the backwards direction.
+
+ A number of denial-of-service attacks open up if REGISTER requests
+ are not properly authenticated and authorized by registrars.
+ Attackers could de-register some or all users in an administrative
+ domain, thereby preventing these users from being invited to new
+ sessions. An attacker could also register a large number of contacts
+ designating the same host for a given address-of-record in order to
+ use the registrar and any associated proxy servers as amplifiers in a
+ denial-of-service attack. Attackers might also attempt to deplete
+ available memory and disk resources of a registrar by registering
+ huge numbers of bindings.
+
+ The use of multicast to transmit SIP requests can greatly increase
+ the potential for denial-of-service attacks.
+
+ These problems demonstrate a general need to define architectures
+ that minimize the risks of denial-of-service, and the need to be
+ mindful in recommendations for security mechanisms of this class of
+ attacks.
+
+26.2 Security Mechanisms
+
+ From the threats described above, we gather that the fundamental
+ security services required for the SIP protocol are: preserving the
+ confidentiality and integrity of messaging, preventing replay attacks
+ or message spoofing, providing for the authentication and privacy of
+ the participants in a session, and preventing denial-of-service
+ attacks. Bodies within SIP messages separately require the security
+ services of confidentiality, integrity, and authentication.
+
+ Rather than defining new security mechanisms specific to SIP, SIP
+ reuses wherever possible existing security models derived from the
+ HTTP and SMTP space.
+
+ Full encryption of messages provides the best means to preserve the
+ confidentiality of signaling - it can also guarantee that messages
+ are not modified by any malicious intermediaries. However, SIP
+ requests and responses cannot be naively encrypted end-to-end in
+ their entirety because message fields such as the Request-URI, Route,
+ and Via need to be visible to proxies in most network architectures
+ so that SIP requests are routed correctly. Note that proxy servers
+ need to modify some features of messages as well (such as adding Via
+ header field values) in order for SIP to function. Proxy servers
+ must therefore be trusted, to some degree, by SIP UAs. To this
+ purpose, low-layer security mechanisms for SIP are recommended, which
+
+
+
+Rosenberg, et. al. Standards Track [Page 237]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ encrypt the entire SIP requests or responses on the wire on a hop-
+ by-hop basis, and that allow endpoints to verify the identity of
+ proxy servers to whom they send requests.
+
+ SIP entities also have a need to identify one another in a secure
+ fashion. When a SIP endpoint asserts the identity of its user to a
+ peer UA or to a proxy server, that identity should in some way be
+ verifiable. A cryptographic authentication mechanism is provided in
+ SIP to address this requirement.
+
+ An independent security mechanism for SIP message bodies supplies an
+ alternative means of end-to-end mutual authentication, as well as
+ providing a limit on the degree to which user agents must trust
+ intermediaries.
+
+26.2.1 Transport and Network Layer Security
+
+ Transport or network layer security encrypts signaling traffic,
+ guaranteeing message confidentiality and integrity.
+
+ Oftentimes, certificates are used in the establishment of lower-layer
+ security, and these certificates can also be used to provide a means
+ of authentication in many architectures.
+
+ Two popular alternatives for providing security at the transport and
+ network layer are, respectively, TLS [25] and IPSec [26].
+
+ IPSec is a set of network-layer protocol tools that collectively can
+ be used as a secure replacement for traditional IP (Internet
+ Protocol). IPSec is most commonly used in architectures in which a
+ set of hosts or administrative domains have an existing trust
+ relationship with one another. IPSec is usually implemented at the
+ operating system level in a host, or on a security gateway that
+ provides confidentiality and integrity for all traffic it receives
+ from a particular interface (as in a VPN architecture). IPSec can
+ also be used on a hop-by-hop basis.
+
+ In many architectures IPSec does not require integration with SIP
+ applications; IPSec is perhaps best suited to deployments in which
+ adding security directly to SIP hosts would be arduous. UAs that
+ have a pre-shared keying relationship with their first-hop proxy
+ server are also good candidates to use IPSec. Any deployment of
+ IPSec for SIP would require an IPSec profile describing the protocol
+ tools that would be required to secure SIP. No such profile is given
+ in this document.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 238]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ TLS provides transport-layer security over connection-oriented
+ protocols (for the purposes of this document, TCP); "tls" (signifying
+ TLS over TCP) can be specified as the desired transport protocol
+ within a Via header field value or a SIP-URI. TLS is most suited to
+ architectures in which hop-by-hop security is required between hosts
+ with no pre-existing trust association. For example, Alice trusts
+ her local proxy server, which after a certificate exchange decides to
+ trust Bob's local proxy server, which Bob trusts, hence Bob and Alice
+ can communicate securely.
+
+ TLS must be tightly coupled with a SIP application. Note that
+ transport mechanisms are specified on a hop-by-hop basis in SIP, thus
+ a UA that sends requests over TLS to a proxy server has no assurance
+ that TLS will be used end-to-end.
+
+ The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at
+ a minimum by implementers when TLS is used in a SIP application. For
+ purposes of backwards compatibility, proxy servers, redirect servers,
+ and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
+ Implementers MAY also support any other ciphersuite.
+
+26.2.2 SIPS URI Scheme
+
+ The SIPS URI scheme adheres to the syntax of the SIP URI (described
+ in 19), although the scheme string is "sips" rather than "sip". The
+ semantics of SIPS are very different from the SIP URI, however. SIPS
+ allows resources to specify that they should be reached securely.
+
+ A SIPS URI can be used as an address-of-record for a particular user
+ - the URI by which the user is canonically known (on their business
+ cards, in the From header field of their requests, in the To header
+ field of REGISTER requests). When used as the Request-URI of a
+ request, the SIPS scheme signifies that each hop over which the
+ request is forwarded, until the request reaches the SIP entity
+ responsible for the domain portion of the Request-URI, must be
+ secured with TLS; once it reaches the domain in question it is
+ handled in accordance with local security and routing policy, quite
+ possibly using TLS for any last hop to a UAS. When used by the
+ originator of a request (as would be the case if they employed a SIPS
+ URI as the address-of-record of the target), SIPS dictates that the
+ entire request path to the target domain be so secured.
+
+ The SIPS scheme is applicable to many of the other ways in which SIP
+ URIs are used in SIP today in addition to the Request-URI, including
+ in addresses-of-record, contact addresses (the contents of Contact
+ headers, including those of REGISTER methods), and Route headers. In
+ each instance, the SIPS URI scheme allows these existing fields to
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 239]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ designate secure resources. The manner in which a SIPS URI is
+ dereferenced in any of these contexts has its own security properties
+ which are detailed in [4].
+
+ The use of SIPS in particular entails that mutual TLS authentication
+ SHOULD be employed, as SHOULD the ciphersuite
+ TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the
+ authentication process SHOULD be validated with root certificates
+ held by the client; failure to validate a certificate SHOULD result
+ in the failure of the request.
+
+ Note that in the SIPS URI scheme, transport is independent of TLS,
+ and thus "sips:alice@atlanta.com;transport=tcp" and
+ "sips:alice@atlanta.com;transport=sctp" are both valid (although
+ note that UDP is not a valid transport for SIPS). The use of
+ "transport=tls" has consequently been deprecated, partly because
+ it was specific to a single hop of the request. This is a change
+ since RFC 2543.
+
+ Users that distribute a SIPS URI as an address-of-record may elect to
+ operate devices that refuse requests over insecure transports.
+
+26.2.3 HTTP Authentication
+
+ SIP provides a challenge capability, based on HTTP authentication,
+ that relies on the 401 and 407 response codes as well as header
+ fields for carrying challenges and credentials. Without significant
+ modification, the reuse of the HTTP Digest authentication scheme in
+ SIP allows for replay protection and one-way authentication.
+
+ The usage of Digest authentication in SIP is detailed in Section 22.
+
+26.2.4 S/MIME
+
+ As is discussed above, encrypting entire SIP messages end-to-end for
+ the purpose of confidentiality is not appropriate because network
+ intermediaries (like proxy servers) need to view certain header
+ fields in order to route messages correctly, and if these
+ intermediaries are excluded from security associations, then SIP
+ messages will essentially be non-routable.
+
+ However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP,
+ securing these bodies end-to-end without affecting message headers.
+ S/MIME can provide end-to-end confidentiality and integrity for
+ message bodies, as well as mutual authentication. It is also
+ possible to use S/MIME to provide a form of integrity and
+ confidentiality for SIP header fields through SIP message tunneling.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 240]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The usage of S/MIME in SIP is detailed in Section 23.
+
+26.3 Implementing Security Mechanisms
+
+26.3.1 Requirements for Implementers of SIP
+
+ Proxy servers, redirect servers, and registrars MUST implement TLS,
+ and MUST support both mutual and one-way authentication. It is
+ strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also
+ be capable of acting as a TLS server. Proxy servers, redirect
+ servers, and registrars SHOULD possess a site certificate whose
+ subject corresponds to their canonical hostname. UAs MAY have
+ certificates of their own for mutual authentication with TLS, but no
+ provisions are set forth in this document for their use. All SIP
+ elements that support TLS MUST have a mechanism for validating
+ certificates received during TLS negotiation; this entails possession
+ of one or more root certificates issued by certificate authorities
+ (preferably well-known distributors of site certificates comparable
+ to those that issue root certificates for web browsers).
+
+ All SIP elements that support TLS MUST also support the SIPS URI
+ scheme.
+
+ Proxy servers, redirect servers, registrars, and UAs MAY also
+ implement IPSec or other lower-layer security protocols.
+
+ When a UA attempts to contact a proxy server, redirect server, or
+ registrar, the UAC SHOULD initiate a TLS connection over which it
+ will send SIP messages. In some architectures, UASs MAY receive
+ requests over such TLS connections as well.
+
+ Proxy servers, redirect servers, registrars, and UAs MUST implement
+ Digest Authorization, encompassing all of the aspects required in 22.
+ Proxy servers, redirect servers, and registrars SHOULD be configured
+ with at least one Digest realm, and at least one "realm" string
+ supported by a given server SHOULD correspond to the server's
+ hostname or domainname.
+
+ UAs MAY support the signing and encrypting of MIME bodies, and
+ transference of credentials with S/MIME as described in Section 23.
+ If a UA holds one or more root certificates of certificate
+ authorities in order to validate certificates for TLS or IPSec, it
+ SHOULD be capable of reusing these to verify S/MIME certificates, as
+ appropriate. A UA MAY hold root certificates specifically for
+ validating S/MIME certificates.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 241]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Note that is it anticipated that future security extensions may
+ upgrade the normative strength associated with S/MIME as S/MIME
+ implementations appear and the problem space becomes better
+ understood.
+
+26.3.2 Security Solutions
+
+ The operation of these security mechanisms in concert can follow the
+ existing web and email security models to some degree. At a high
+ level, UAs authenticate themselves to servers (proxy servers,
+ redirect servers, and registrars) with a Digest username and
+ password; servers authenticate themselves to UAs one hop away, or to
+ another server one hop away (and vice versa), with a site certificate
+ delivered by TLS.
+
+ On a peer-to-peer level, UAs trust the network to authenticate one
+ another ordinarily; however, S/MIME can also be used to provide
+ direct authentication when the network does not, or if the network
+ itself is not trusted.
+
+ The following is an illustrative example in which these security
+ mechanisms are used by various UAs and servers to prevent the sorts
+ of threats described in Section 26.1. While implementers and network
+ administrators MAY follow the normative guidelines given in the
+ remainder of this section, these are provided only as example
+ implementations.
+
+26.3.2.1 Registration
+
+ When a UA comes online and registers with its local administrative
+ domain, it SHOULD establish a TLS connection with its registrar
+ (Section 10 describes how the UA reaches its registrar). The
+ registrar SHOULD offer a certificate to the UA, and the site
+ identified by the certificate MUST correspond with the domain in
+ which the UA intends to register; for example, if the UA intends to
+ register the address-of-record 'alice@atlanta.com', the site
+ certificate must identify a host within the atlanta.com domain (such
+ as sip.atlanta.com). When it receives the TLS Certificate message,
+ the UA SHOULD verify the certificate and inspect the site identified
+ by the certificate. If the certificate is invalid, revoked, or if it
+ does not identify the appropriate party, the UA MUST NOT send the
+ REGISTER message and otherwise proceed with the registration.
+
+ When a valid certificate has been provided by the registrar, the
+ UA knows that the registrar is not an attacker who might redirect
+ the UA, steal passwords, or attempt any similar attacks.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 242]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The UA then creates a REGISTER request that SHOULD be addressed to a
+ Request-URI corresponding to the site certificate received from the
+ registrar. When the UA sends the REGISTER request over the existing
+ TLS connection, the registrar SHOULD challenge the request with a 401
+ (Proxy Authentication Required) response. The "realm" parameter
+ within the Proxy-Authenticate header field of the response SHOULD
+ correspond to the domain previously given by the site certificate.
+ When the UAC receives the challenge, it SHOULD either prompt the user
+ for credentials or take an appropriate credential from a keyring
+ corresponding to the "realm" parameter in the challenge. The
+ username of this credential SHOULD correspond with the "userinfo"
+ portion of the URI in the To header field of the REGISTER request.
+ Once the Digest credentials have been inserted into an appropriate
+ Proxy-Authorization header field, the REGISTER should be resubmitted
+ to the registrar.
+
+ Since the registrar requires the user agent to authenticate
+ itself, it would be difficult for an attacker to forge REGISTER
+ requests for the user's address-of-record. Also note that since
+ the REGISTER is sent over a confidential TLS connection, attackers
+ will not be able to intercept the REGISTER to record credentials
+ for any possible replay attack.
+
+ Once the registration has been accepted by the registrar, the UA
+ SHOULD leave this TLS connection open provided that the registrar
+ also acts as the proxy server to which requests are sent for users in
+ this administrative domain. The existing TLS connection will be
+ reused to deliver incoming requests to the UA that has just completed
+ registration.
+
+ Because the UA has already authenticated the server on the other
+ side of the TLS connection, all requests that come over this
+ connection are known to have passed through the proxy server -
+ attackers cannot create spoofed requests that appear to have been
+ sent through that proxy server.
+
+26.3.2.2 Interdomain Requests
+
+ Now let's say that Alice's UA would like to initiate a session with a
+ user in a remote administrative domain, namely "bob@biloxi.com". We
+ will also say that the local administrative domain (atlanta.com) has
+ a local outbound proxy.
+
+ The proxy server that handles inbound requests for an administrative
+ domain MAY also act as a local outbound proxy; for simplicity's sake
+ we'll assume this to be the case for atlanta.com (otherwise the user
+ agent would initiate a new TLS connection to a separate server at
+ this point). Assuming that the client has completed the registration
+
+
+
+Rosenberg, et. al. Standards Track [Page 243]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ process described in the preceding section, it SHOULD reuse the TLS
+ connection to the local proxy server when it sends an INVITE request
+ to another user. The UA SHOULD reuse cached credentials in the
+ INVITE to avoid prompting the user unnecessarily.
+
+ When the local outbound proxy server has validated the credentials
+ presented by the UA in the INVITE, it SHOULD inspect the Request-URI
+ to determine how the message should be routed (see [4]). If the
+ "domainname" portion of the Request-URI had corresponded to the local
+ domain (atlanta.com) rather than biloxi.com, then the proxy server
+ would have consulted its location service to determine how best to
+ reach the requested user.
+
+ Had "alice@atlanta.com" been attempting to contact, say,
+ "alex@atlanta.com", the local proxy would have proxied to the
+ request to the TLS connection Alex had established with the
+ registrar when he registered. Since Alex would receive this
+ request over his authenticated channel, he would be assured that
+ Alice's request had been authorized by the proxy server of the
+ local administrative domain.
+
+ However, in this instance the Request-URI designates a remote domain.
+ The local outbound proxy server at atlanta.com SHOULD therefore
+ establish a TLS connection with the remote proxy server at
+ biloxi.com. Since both of the participants in this TLS connection
+ are servers that possess site certificates, mutual TLS authentication
+ SHOULD occur. Each side of the connection SHOULD verify and inspect
+ the certificate of the other, noting the domain name that appears in
+ the certificate for comparison with the header fields of SIP
+ messages. The atlanta.com proxy server, for example, SHOULD verify
+ at this stage that the certificate received from the remote side
+ corresponds with the biloxi.com domain. Once it has done so, and TLS
+ negotiation has completed, resulting in a secure channel between the
+ two proxies, the atlanta.com proxy can forward the INVITE request to
+ biloxi.com.
+
+ The proxy server at biloxi.com SHOULD inspect the certificate of the
+ proxy server at atlanta.com in turn and compare the domain asserted
+ by the certificate with the "domainname" portion of the From header
+ field in the INVITE request. The biloxi proxy MAY have a strict
+ security policy that requires it to reject requests that do not match
+ the administrative domain from which they have been proxied.
+
+ Such security policies could be instituted to prevent the SIP
+ equivalent of SMTP 'open relays' that are frequently exploited to
+ generate spam.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 244]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ This policy, however, only guarantees that the request came from the
+ domain it ascribes to itself; it does not allow biloxi.com to
+ ascertain how atlanta.com authenticated Alice. Only if biloxi.com
+ has some other way of knowing atlanta.com's authentication policies
+ could it possibly ascertain how Alice proved her identity.
+ biloxi.com might then institute an even stricter policy that forbids
+ requests that come from domains that are not known administratively
+ to share a common authentication policy with biloxi.com.
+
+ Once the INVITE has been approved by the biloxi proxy, the proxy
+ server SHOULD identify the existing TLS channel, if any, associated
+ with the user targeted by this request (in this case
+ "bob@biloxi.com"). The INVITE should be proxied through this channel
+ to Bob. Since the request is received over a TLS connection that had
+ previously been authenticated as the biloxi proxy, Bob knows that the
+ From header field was not tampered with and that atlanta.com has
+ validated Alice, although not necessarily whether or not to trust
+ Alice's identity.
+
+ Before they forward the request, both proxy servers SHOULD add a
+ Record-Route header field to the request so that all future requests
+ in this dialog will pass through the proxy servers. The proxy
+ servers can thereby continue to provide security services for the
+ lifetime of this dialog. If the proxy servers do not add themselves
+ to the Record-Route, future messages will pass directly end-to-end
+ between Alice and Bob without any security services (unless the two
+ parties agree on some independent end-to-end security such as
+ S/MIME). In this respect the SIP trapezoid model can provide a nice
+ structure where conventions of agreement between the site proxies can
+ provide a reasonably secure channel between Alice and Bob.
+
+ An attacker preying on this architecture would, for example, be
+ unable to forge a BYE request and insert it into the signaling
+ stream between Bob and Alice because the attacker has no way of
+ ascertaining the parameters of the session and also because the
+ integrity mechanism transitively protects the traffic between
+ Alice and Bob.
+
+26.3.2.3 Peer-to-Peer Requests
+
+ Alternatively, consider a UA asserting the identity
+ "carol@chicago.com" that has no local outbound proxy. When Carol
+ wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate
+ a TLS connection with the biloxi proxy directly (using the mechanism
+ described in [4] to determine how to best to reach the given
+ Request-URI). When her UA receives a certificate from the biloxi
+ proxy, it SHOULD be verified normally before she passes her INVITE
+ across the TLS connection. However, Carol has no means of proving
+
+
+
+Rosenberg, et. al. Standards Track [Page 245]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ her identity to the biloxi proxy, but she does have a CMS-detached
+ signature over a "message/sip" body in the INVITE. It is unlikely in
+ this instance that Carol would have any credentials in the biloxi.com
+ realm, since she has no formal association with biloxi.com. The
+ biloxi proxy MAY also have a strict policy that precludes it from
+ even bothering to challenge requests that do not have biloxi.com in
+ the "domainname" portion of the From header field - it treats these
+ users as unauthenticated.
+
+ The biloxi proxy has a policy for Bob that all non-authenticated
+ requests should be redirected to the appropriate contact address
+ registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>.
+ Carol receives the redirection response over the TLS connection she
+ established with the biloxi proxy, so she trusts the veracity of the
+ contact address.
+
+ Carol SHOULD then establish a TCP connection with the designated
+ address and send a new INVITE with a Request-URI containing the
+ received contact address (recomputing the signature in the body as
+ the request is readied). Bob receives this INVITE on an insecure
+ interface, but his UA inspects and, in this instance, recognizes the
+ From header field of the request and subsequently matches a locally
+ cached certificate with the one presented in the signature of the
+ body of the INVITE. He replies in similar fashion, authenticating
+ himself to Carol, and a secure dialog begins.
+
+ Sometimes firewalls or NATs in an administrative domain could
+ preclude the establishment of a direct TCP connection to a UA. In
+ these cases, proxy servers could also potentially relay requests
+ to UAs in a way that has no trust implications (for example,
+ forgoing an existing TLS connection and forwarding the request
+ over cleartext TCP) as local policy dictates.
+
+26.3.2.4 DoS Protection
+
+ In order to minimize the risk of a denial-of-service attack against
+ architectures using these security solutions, implementers should
+ take note of the following guidelines.
+
+ When the host on which a SIP proxy server is operating is routable
+ from the public Internet, it SHOULD be deployed in an administrative
+ domain with defensive operational policies (blocking source-routed
+ traffic, preferably filtering ping traffic). Both TLS and IPSec can
+ also make use of bastion hosts at the edges of administrative domains
+ that participate in the security associations to aggregate secure
+ tunnels and sockets. These bastion hosts can also take the brunt of
+ denial-of-service attacks, ensuring that SIP hosts within the
+ administrative domain are not encumbered with superfluous messaging.
+
+
+
+Rosenberg, et. al. Standards Track [Page 246]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ No matter what security solutions are deployed, floods of messages
+ directed at proxy servers can lock up proxy server resources and
+ prevent desirable traffic from reaching its destination. There is a
+ computational expense associated with processing a SIP transaction at
+ a proxy server, and that expense is greater for stateful proxy
+ servers than it is for stateless proxy servers. Therefore, stateful
+ proxies are more susceptible to flooding than stateless proxy
+ servers.
+
+ UAs and proxy servers SHOULD challenge questionable requests with
+ only a single 401 (Unauthorized) or 407 (Proxy Authentication
+ Required), forgoing the normal response retransmission algorithm, and
+ thus behaving statelessly towards unauthenticated requests.
+
+ Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication
+ Required) status response amplifies the problem of an attacker
+ using a falsified header field value (such as Via) to direct
+ traffic to a third party.
+
+ In summary, the mutual authentication of proxy servers through
+ mechanisms such as TLS significantly reduces the potential for rogue
+ intermediaries to introduce falsified requests or responses that can
+ deny service. This commensurately makes it harder for attackers to
+ make innocent SIP nodes into agents of amplification.
+
+26.4 Limitations
+
+ Although these security mechanisms, when applied in a judicious
+ manner, can thwart many threats, there are limitations in the scope
+ of the mechanisms that must be understood by implementers and network
+ operators.
+
+26.4.1 HTTP Digest
+
+ One of the primary limitations of using HTTP Digest in SIP is that
+ the integrity mechanisms in Digest do not work very well for SIP.
+ Specifically, they offer protection of the Request-URI and the method
+ of a message, but not for any of the header fields that UAs would
+ most likely wish to secure.
+
+ The existing replay protection mechanisms described in RFC 2617 also
+ have some limitations for SIP. The next-nonce mechanism, for
+ example, does not support pipelined requests. The nonce-count
+ mechanism should be used for replay protection.
+
+ Another limitation of HTTP Digest is the scope of realms. Digest is
+ valuable when a user wants to authenticate themselves to a resource
+ with which they have a pre-existing association, like a service
+
+
+
+Rosenberg, et. al. Standards Track [Page 247]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ provider of which the user is a customer (which is quite a common
+ scenario and thus Digest provides an extremely useful function). By
+ way of contrast, the scope of TLS is interdomain or multirealm, since
+ certificates are often globally verifiable, so that the UA can
+ authenticate the server with no pre-existing association.
+
+26.4.2 S/MIME
+
+ The largest outstanding defect with the S/MIME mechanism is the lack
+ of a prevalent public key infrastructure for end users. If self-
+ signed certificates (or certificates that cannot be verified by one
+ of the participants in a dialog) are used, the SIP-based key exchange
+ mechanism described in Section 23.2 is susceptible to a man-in-the-
+ middle attack with which an attacker can potentially inspect and
+ modify S/MIME bodies. The attacker needs to intercept the first
+ exchange of keys between the two parties in a dialog, remove the
+ existing CMS-detached signatures from the request and response, and
+ insert a different CMS-detached signature containing a certificate
+ supplied by the attacker (but which seems to be a certificate for the
+ proper address-of-record). Each party will think they have exchanged
+ keys with the other, when in fact each has the public key of the
+ attacker.
+
+ It is important to note that the attacker can only leverage this
+ vulnerability on the first exchange of keys between two parties - on
+ subsequent occasions, the alteration of the key would be noticeable
+ to the UAs. It would also be difficult for the attacker to remain in
+ the path of all future dialogs between the two parties over time (as
+ potentially days, weeks, or years pass).
+
+ SSH is susceptible to the same man-in-the-middle attack on the first
+ exchange of keys; however, it is widely acknowledged that while SSH
+ is not perfect, it does improve the security of connections. The use
+ of key fingerprints could provide some assistance to SIP, just as it
+ does for SSH. For example, if two parties use SIP to establish a
+ voice communications session, each could read off the fingerprint of
+ the key they received from the other, which could be compared against
+ the original. It would certainly be more difficult for the man-in-
+ the-middle to emulate the voices of the participants than their
+ signaling (a practice that was used with the Clipper chip-based
+ secure telephone).
+
+ The S/MIME mechanism allows UAs to send encrypted requests without
+ preamble if they possess a certificate for the destination address-
+ of-record on their keyring. However, it is possible that any
+ particular device registered for an address-of-record will not hold
+ the certificate that has been previously employed by the device's
+ current user, and that it will therefore be unable to process an
+
+
+
+Rosenberg, et. al. Standards Track [Page 248]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ encrypted request properly, which could lead to some avoidable error
+ signaling. This is especially likely when an encrypted request is
+ forked.
+
+ The keys associated with S/MIME are most useful when associated with
+ a particular user (an address-of-record) rather than a device (a UA).
+ When users move between devices, it may be difficult to transport
+ private keys securely between UAs; how such keys might be acquired by
+ a device is outside the scope of this document.
+
+ Another, more prosaic difficulty with the S/MIME mechanism is that it
+ can result in very large messages, especially when the SIP tunneling
+ mechanism described in Section 23.4 is used. For that reason, it is
+ RECOMMENDED that TCP should be used as a transport protocol when
+ S/MIME tunneling is employed.
+
+26.4.3 TLS
+
+ The most commonly voiced concern about TLS is that it cannot run over
+ UDP; TLS requires a connection-oriented underlying transport
+ protocol, which for the purposes of this document means TCP.
+
+ It may also be arduous for a local outbound proxy server and/or
+ registrar to maintain many simultaneous long-lived TLS connections
+ with numerous UAs. This introduces some valid scalability concerns,
+ especially for intensive ciphersuites. Maintaining redundancy of
+ long-lived TLS connections, especially when a UA is solely
+ responsible for their establishment, could also be cumbersome.
+
+ TLS only allows SIP entities to authenticate servers to which they
+ are adjacent; TLS offers strictly hop-by-hop security. Neither TLS,
+ nor any other mechanism specified in this document, allows clients to
+ authenticate proxy servers to whom they cannot form a direct TCP
+ connection.
+
+26.4.4 SIPS URIs
+
+ Actually using TLS on every segment of a request path entails that
+ the terminating UAS must be reachable over TLS (perhaps registering
+ with a SIPS URI as a contact address). This is the preferred use of
+ SIPS. Many valid architectures, however, use TLS to secure part of
+ the request path, but rely on some other mechanism for the final hop
+ to a UAS, for example. Thus SIPS cannot guarantee that TLS usage
+ will be truly end-to-end. Note that since many UAs will not accept
+ incoming TLS connections, even those UAs that do support TLS may be
+ required to maintain persistent TLS connections as described in the
+ TLS limitations section above in order to receive requests over TLS
+ as a UAS.
+
+
+
+Rosenberg, et. al. Standards Track [Page 249]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Location services are not required to provide a SIPS binding for a
+ SIPS Request-URI. Although location services are commonly populated
+ by user registrations (as described in Section 10.2.1), various other
+ protocols and interfaces could conceivably supply contact addresses
+ for an AOR, and these tools are free to map SIPS URIs to SIP URIs as
+ appropriate. When queried for bindings, a location service returns
+ its contact addresses without regard for whether it received a
+ request with a SIPS Request-URI. If a redirect server is accessing
+ the location service, it is up to the entity that processes the
+ Contact header field of a redirection to determine the propriety of
+ the contact addresses.
+
+ Ensuring that TLS will be used for all of the request segments up to
+ the target domain is somewhat complex. It is possible that
+ cryptographically authenticated proxy servers along the way that are
+ non-compliant or compromised may choose to disregard the forwarding
+ rules associated with SIPS (and the general forwarding rules in
+ Section 16.6). Such malicious intermediaries could, for example,
+ retarget a request from a SIPS URI to a SIP URI in an attempt to
+ downgrade security.
+
+ Alternatively, an intermediary might legitimately retarget a request
+ from a SIP to a SIPS URI. Recipients of a request whose Request-URI
+ uses the SIPS URI scheme thus cannot assume on the basis of the
+ Request-URI alone that SIPS was used for the entire request path
+ (from the client onwards).
+
+ To address these concerns, it is RECOMMENDED that recipients of a
+ request whose Request-URI contains a SIP or SIPS URI inspect the To
+ header field value to see if it contains a SIPS URI (though note that
+ it does not constitute a breach of security if this URI has the same
+ scheme but is not equivalent to the URI in the To header field).
+ Although clients may choose to populate the Request-URI and To header
+ field of a request differently, when SIPS is used this disparity
+ could be interpreted as a possible security violation, and the
+ request could consequently be rejected by its recipient. Recipients
+ MAY also inspect the Via header chain in order to double-check
+ whether or not TLS was used for the entire request path until the
+ local administrative domain was reached. S/MIME may also be used by
+ the originating UAC to help ensure that the original form of the To
+ header field is carried end-to-end.
+
+ If the UAS has reason to believe that the scheme of the Request-URI
+ has been improperly modified in transit, the UA SHOULD notify its
+ user of a potential security breach.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 250]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ As a further measure to prevent downgrade attacks, entities that
+ accept only SIPS requests MAY also refuse connections on insecure
+ ports.
+
+ End users will undoubtedly discern the difference between SIPS and
+ SIP URIs, and they may manually edit them in response to stimuli.
+ This can either benefit or degrade security. For example, if an
+ attacker corrupts a DNS cache, inserting a fake record set that
+ effectively removes all SIPS records for a proxy server, then any
+ SIPS requests that traverse this proxy server may fail. When a user,
+ however, sees that repeated calls to a SIPS AOR are failing, they
+ could on some devices manually convert the scheme from SIPS to SIP
+ and retry. Of course, there are some safeguards against this (if the
+ destination UA is truly paranoid it could refuse all non-SIPS
+ requests), but it is a limitation worth noting. On the bright side,
+ users might also divine that 'SIPS' would be valid even when they are
+ presented only with a SIP URI.
+
+26.5 Privacy
+
+ SIP messages frequently contain sensitive information about their
+ senders - not just what they have to say, but with whom they
+ communicate, when they communicate and for how long, and from where
+ they participate in sessions. Many applications and their users
+ require that this sort of private information be hidden from any
+ parties that do not need to know it.
+
+ Note that there are also less direct ways in which private
+ information can be divulged. If a user or service chooses to be
+ reachable at an address that is guessable from the person's name and
+ organizational affiliation (which describes most addresses-of-
+ record), the traditional method of ensuring privacy by having an
+ unlisted "phone number" is compromised. A user location service can
+ infringe on the privacy of the recipient of a session invitation by
+ divulging their specific whereabouts to the caller; an implementation
+ consequently SHOULD be able to restrict, on a per-user basis, what
+ kind of location and availability information is given out to certain
+ classes of callers. This is a whole class of problem that is
+ expected to be studied further in ongoing SIP work.
+
+ In some cases, users may want to conceal personal information in
+ header fields that convey identity. This can apply not only to the
+ From and related headers representing the originator of the request,
+ but also the To - it may not be appropriate to convey to the final
+ destination a speed-dialing nickname, or an unexpanded identifier for
+ a group of targets, either of which would be removed from the
+ Request-URI as the request is routed, but not changed in the To
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 251]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ header field if the two were initially identical. Thus it MAY be
+ desirable for privacy reasons to create a To header field that
+ differs from the Request-URI.
+
+27 IANA Considerations
+
+ All method names, header field names, status codes, and option tags
+ used in SIP applications are registered with IANA through
+ instructions in an IANA Considerations section in an RFC.
+
+ The specification instructs the IANA to create four new sub-
+ registries under http://www.iana.org/assignments/sip-parameters:
+ Option Tags, Warning Codes (warn-codes), Methods and Response Codes,
+ added to the sub-registry of Header Fields that is already present
+ there.
+
+27.1 Option Tags
+
+ This specification establishes the Option Tags sub-registry under
+ http://www.iana.org/assignments/sip-parameters.
+
+ Option tags are used in header fields such as Require, Supported,
+ Proxy-Require, and Unsupported in support of SIP compatibility
+ mechanisms for extensions (Section 19.2). The option tag itself is a
+ string that is associated with a particular SIP option (that is, an
+ extension). It identifies the option to SIP endpoints.
+
+ Option tags are registered by the IANA when they are published in
+ standards track RFCs. The IANA Considerations section of the RFC
+ must include the following information, which appears in the IANA
+ registry along with the RFC number of the publication.
+
+ o Name of the option tag. The name MAY be of any length, but
+ SHOULD be no more than twenty characters long. The name MUST
+ consist of alphanum (Section 25) characters only.
+
+ o Descriptive text that describes the extension.
+
+27.2 Warn-Codes
+
+ This specification establishes the Warn-codes sub-registry under
+ http://www.iana.org/assignments/sip-parameters and initiates its
+ population with the warn-codes listed in Section 20.43. Additional
+ warn-codes are registered by RFC publication.
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 252]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ The descriptive text for the table of warn-codes is:
+
+ Warning codes provide information supplemental to the status code in
+ SIP response messages when the failure of the transaction results
+ from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.
+
+ The "warn-code" consists of three digits. A first digit of "3"
+ indicates warnings specific to SIP. Until a future specification
+ describes uses of warn-codes other than 3xx, only 3xx warn-codes may
+ be registered.
+
+ Warnings 300 through 329 are reserved for indicating problems with
+ keywords in the session description, 330 through 339 are warnings
+ related to basic network services requested in the session
+ description, 370 through 379 are warnings related to quantitative QoS
+ parameters requested in the session description, and 390 through 399
+ are miscellaneous warnings that do not fall into one of the above
+ categories.
+
+27.3 Header Field Names
+
+ This obsoletes the IANA instructions about the header sub-registry
+ under http://www.iana.org/assignments/sip-parameters.
+
+ The following information needs to be provided in an RFC publication
+ in order to register a new header field name:
+
+ o The RFC number in which the header is registered;
+
+ o the name of the header field being registered;
+
+ o a compact form version for that header field, if one is
+ defined;
+
+ Some common and widely used header fields MAY be assigned one-letter
+ compact forms (Section 7.3.3). Compact forms can only be assigned
+ after SIP working group review, followed by RFC publication.
+
+27.4 Method and Response Codes
+
+ This specification establishes the Method and Response-Code sub-
+ registries under http://www.iana.org/assignments/sip-parameters and
+ initiates their population as follows. The initial Methods table is:
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 253]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ INVITE [RFC3261]
+ ACK [RFC3261]
+ BYE [RFC3261]
+ CANCEL [RFC3261]
+ REGISTER [RFC3261]
+ OPTIONS [RFC3261]
+ INFO [RFC2976]
+
+ The response code table is initially populated from Section 21, the
+ portions labeled Informational, Success, Redirection, Client-Error,
+ Server-Error, and Global-Failure. The table has the following
+ format:
+
+ Type (e.g., Informational)
+ Number Default Reason Phrase [RFC3261]
+
+ The following information needs to be provided in an RFC publication
+ in order to register a new response code or method:
+
+ o The RFC number in which the method or response code is
+ registered;
+
+ o the number of the response code or name of the method being
+ registered;
+
+ o the default reason phrase for that response code, if
+ applicable;
+
+27.5 The "message/sip" MIME type.
+
+ This document registers the "message/sip" MIME media type in order to
+ allow SIP messages to be tunneled as bodies within SIP, primarily for
+ end-to-end security purposes. This media type is defined by the
+ following information:
+
+ Media type name: message
+ Media subtype name: sip
+ Required parameters: none
+
+ Optional parameters: version
+ version: The SIP-Version number of the enclosed message (e.g.,
+ "2.0"). If not present, the version defaults to "2.0".
+ Encoding scheme: SIP messages consist of an 8-bit header
+ optionally followed by a binary MIME data object. As such, SIP
+ messages must be treated as binary. Under normal circumstances
+ SIP messages are transported over binary-capable transports, no
+ special encodings are needed.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 254]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Security considerations: see below
+ Motivation and examples of this usage as a security mechanism
+ in concert with S/MIME are given in 23.4.
+
+27.6 New Content-Disposition Parameter Registrations
+
+ This document also registers four new Content-Disposition header
+ "disposition-types": alert, icon, session and render. The authors
+ request that these values be recorded in the IANA registry for
+ Content-Dispositions.
+
+ Descriptions of these "disposition-types", including motivation and
+ examples, are given in Section 20.11.
+
+ Short descriptions suitable for the IANA registry are:
+
+ alert the body is a custom ring tone to alert the user
+ icon the body is displayed as an icon to the user
+ render the body should be displayed to the user
+ session the body describes a communications session, for
+ example, as RFC 2327 SDP body
+
+28 Changes From RFC 2543
+
+ This RFC revises RFC 2543. It is mostly backwards compatible with
+ RFC 2543. The changes described here fix many errors discovered in
+ RFC 2543 and provide information on scenarios not detailed in RFC
+ 2543. The protocol has been presented in a more cleanly layered
+ model here.
+
+ We break the differences into functional behavior that is a
+ substantial change from RFC 2543, which has impact on
+ interoperability or correct operation in some cases, and functional
+ behavior that is different from RFC 2543 but not a potential source
+ of interoperability problems. There have been countless
+ clarifications as well, which are not documented here.
+
+28.1 Major Functional Changes
+
+ o When a UAC wishes to terminate a call before it has been answered,
+ it sends CANCEL. If the original INVITE still returns a 2xx, the
+ UAC then sends BYE. BYE can only be sent on an existing call leg
+ (now called a dialog in this RFC), whereas it could be sent at any
+ time in RFC 2543.
+
+ o The SIP BNF was converted to be RFC 2234 compliant.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 255]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o SIP URL BNF was made more general, allowing a greater set of
+ characters in the user part. Furthermore, comparison rules were
+ simplified to be primarily case-insensitive, and detailed handling
+ of comparison in the presence of parameters was described. The
+ most substantial change is that a URI with a parameter with the
+ default value does not match a URI without that parameter.
+
+ o Removed Via hiding. It had serious trust issues, since it relied
+ on the next hop to perform the obfuscation process. Instead, Via
+ hiding can be done as a local implementation choice in stateful
+ proxies, and thus is no longer documented.
+
+ o In RFC 2543, CANCEL and INVITE transactions were intermingled.
+ They are separated now. When a user sends an INVITE and then a
+ CANCEL, the INVITE transaction still terminates normally. A UAS
+ needs to respond to the original INVITE request with a 487
+ response.
+
+ o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543
+ allowed the UAS not to send a response to INVITE when a BYE was
+ received. That is disallowed here. The original INVITE needs a
+ response.
+
+ o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs
+ need to support both UDP and TCP.
+
+ o In RFC 2543, a forking proxy only passed up one challenge from
+ downstream elements in the event of multiple challenges. In this
+ RFC, proxies are supposed to collect all challenges and place them
+ into the forwarded response.
+
+ o In Digest credentials, the URI needs to be quoted; this is unclear
+ from RFC 2617 and RFC 2069 which are both inconsistent on it.
+
+ o SDP processing has been split off into a separate specification
+ [13], and more fully specified as a formal offer/answer exchange
+ process that is effectively tunneled through SIP. SDP is allowed
+ in INVITE/200 or 200/ACK for baseline SIP implementations; RFC
+ 2543 alluded to the ability to use it in INVITE, 200, and ACK in a
+ single transaction, but this was not well specified. More complex
+ SDP usages are allowed in extensions.
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 256]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o Added full support for IPv6 in URIs and in the Via header field.
+ Support for IPv6 in Via has required that its header field
+ parameters allow the square bracket and colon characters. These
+ characters were previously not permitted. In theory, this could
+ cause interop problems with older implementations. However, we
+ have observed that most implementations accept any non-control
+ ASCII character in these parameters.
+
+ o DNS SRV procedure is now documented in a separate specification
+ [4]. This procedure uses both SRV and NAPTR resource records and
+ no longer combines data from across SRV records as described in
+ RFC 2543.
+
+ o Loop detection has been made optional, supplanted by a mandatory
+ usage of Max-Forwards. The loop detection procedure in RFC 2543
+ had a serious bug which would report "spirals" as an error
+ condition when it was not. The optional loop detection procedure
+ is more fully and correctly specified here.
+
+ o Usage of tags is now mandatory (they were optional in RFC 2543),
+ as they are now the fundamental building blocks of dialog
+ identification.
+
+ o Added the Supported header field, allowing for clients to indicate
+ what extensions are supported to a server, which can apply those
+ extensions to the response, and indicate their usage with a
+ Require in the response.
+
+ o Extension parameters were missing from the BNF for several header
+ fields, and they have been added.
+
+ o Handling of Route and Record-Route construction was very
+ underspecified in RFC 2543, and also not the right approach. It
+ has been substantially reworked in this specification (and made
+ vastly simpler), and this is arguably the largest change.
+ Backwards compatibility is still provided for deployments that do
+ not use "pre-loaded routes", where the initial request has a set
+ of Route header field values obtained in some way outside of
+ Record-Route. In those situations, the new mechanism is not
+ interoperable.
+
+ o In RFC 2543, lines in a message could be terminated with CR, LF,
+ or CRLF. This specification only allows CRLF.
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 257]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o Usage of Route in CANCEL and ACK was not well defined in RFC 2543.
+ It is now well specified; if a request had a Route header field,
+ its CANCEL or ACK for a non-2xx response to the request need to
+ carry the same Route header field values. ACKs for 2xx responses
+ use the Route values learned from the Record-Route of the 2xx
+ responses.
+
+ o RFC 2543 allowed multiple requests in a single UDP packet. This
+ usage has been removed.
+
+ o Usage of absolute time in the Expires header field and parameter
+ has been removed. It caused interoperability problems in elements
+ that were not time synchronized, a common occurrence. Relative
+ times are used instead.
+
+ o The branch parameter of the Via header field value is now
+ mandatory for all elements to use. It now plays the role of a
+ unique transaction identifier. This avoids the complex and bug-
+ laden transaction identification rules from RFC 2543. A magic
+ cookie is used in the parameter value to determine if the previous
+ hop has made the parameter globally unique, and comparison falls
+ back to the old rules when it is not present. Thus,
+ interoperability is assured.
+
+ o In RFC 2543, closure of a TCP connection was made equivalent to a
+ CANCEL. This was nearly impossible to implement (and wrong) for
+ TCP connections between proxies. This has been eliminated, so
+ that there is no coupling between TCP connection state and SIP
+ processing.
+
+ o RFC 2543 was silent on whether a UA could initiate a new
+ transaction to a peer while another was in progress. That is now
+ specified here. It is allowed for non-INVITE requests, disallowed
+ for INVITE.
+
+ o PGP was removed. It was not sufficiently specified, and not
+ compatible with the more complete PGP MIME. It was replaced with
+ S/MIME.
+
+ o Added the "sips" URI scheme for end-to-end TLS. This scheme is
+ not backwards compatible with RFC 2543. Existing elements that
+ receive a request with a SIPS URI scheme in the Request-URI will
+ likely reject the request. This is actually a feature; it ensures
+ that a call to a SIPS URI is only delivered if all path hops can
+ be secured.
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 258]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o Additional security features were added with TLS, and these are
+ described in a much larger and complete security considerations
+ section.
+
+ o In RFC 2543, a proxy was not required to forward provisional
+ responses from 101 to 199 upstream. This was changed to MUST.
+ This is important, since many subsequent features depend on
+ delivery of all provisional responses from 101 to 199.
+
+ o Little was said about the 503 response code in RFC 2543. It has
+ since found substantial use in indicating failure or overload
+ conditions in proxies. This requires somewhat special treatment.
+ Specifically, receipt of a 503 should trigger an attempt to
+ contact the next element in the result of a DNS SRV lookup. Also,
+ 503 response is only forwarded upstream by a proxy under certain
+ conditions.
+
+ o RFC 2543 defined, but did no sufficiently specify, a mechanism for
+ UA authentication of a server. That has been removed. Instead,
+ the mutual authentication procedures of RFC 2617 are allowed.
+
+ o A UA cannot send a BYE for a call until it has received an ACK for
+ the initial INVITE. This was allowed in RFC 2543 but leads to a
+ potential race condition.
+
+ o A UA or proxy cannot send CANCEL for a transaction until it gets a
+ provisional response for the request. This was allowed in RFC
+ 2543 but leads to potential race conditions.
+
+ o The action parameter in registrations has been deprecated. It was
+ insufficient for any useful services, and caused conflicts when
+ application processing was applied in proxies.
+
+ o RFC 2543 had a number of special cases for multicast. For
+ example, certain responses were suppressed, timers were adjusted,
+ and so on. Multicast now plays a more limited role, and the
+ protocol operation is unaffected by usage of multicast as opposed
+ to unicast. The limitations as a result of that are documented.
+
+ o Basic authentication has been removed entirely and its usage
+ forbidden.
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 259]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ o Proxies no longer forward a 6xx immediately on receiving it.
+ Instead, they CANCEL pending branches immediately. This avoids a
+ potential race condition that would result in a UAC getting a 6xx
+ followed by a 2xx. In all cases except this race condition, the
+ result will be the same - the 6xx is forwarded upstream.
+
+ o RFC 2543 did not address the problem of request merging. This
+ occurs when a request forks at a proxy and later rejoins at an
+ element. Handling of merging is done only at a UA, and procedures
+ are defined for rejecting all but the first request.
+
+28.2 Minor Functional Changes
+
+ o Added the Alert-Info, Error-Info, and Call-Info header fields for
+ optional content presentation to users.
+
+ o Added the Content-Language, Content-Disposition and MIME-Version
+ header fields.
+
+ o Added a "glare handling" mechanism to deal with the case where
+ both parties send each other a re-INVITE simultaneously. It uses
+ the new 491 (Request Pending) error code.
+
+ o Added the In-Reply-To and Reply-To header fields for supporting
+ the return of missed calls or messages at a later time.
+
+ o Added TLS and SCTP as valid SIP transports.
+
+ o There were a variety of mechanisms described for handling failures
+ at any time during a call; those are now generally unified. BYE
+ is sent to terminate.
+
+ o RFC 2543 mandated retransmission of INVITE responses over TCP, but
+ noted it was really only needed for 2xx. That was an artifact of
+ insufficient protocol layering. With a more coherent transaction
+ layer defined here, that is no longer needed. Only 2xx responses
+ to INVITEs are retransmitted over TCP.
+
+ o Client and server transaction machines are now driven based on
+ timeouts rather than retransmit counts. This allows the state
+ machines to be properly specified for TCP and UDP.
+
+ o The Date header field is used in REGISTER responses to provide a
+ simple means for auto-configuration of dates in user agents.
+
+ o Allowed a registrar to reject registrations with expirations that
+ are too short in duration. Defined the 423 response code and the
+ Min-Expires for this purpose.
+
+
+
+Rosenberg, et. al. Standards Track [Page 260]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+29 Normative References
+
+ [1] Handley, M. and V. Jacobson, "SDP: Session Description
+ Protocol", RFC 2327, April 1998.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+ [4] Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers",
+ RFC 3263, June 2002.
+
+ [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+ [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+ Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+ [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+ Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
+ 2000.
+
+ [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046, November
+ 1996.
+
+ [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+ Recommendations for Security", RFC 1750, December 1994.
+
+ [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ SDP", RFC 3264, June 2002.
+
+ [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+ 1980.
+
+ [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC
+ 761, January 1980.
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 261]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
+ H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
+ "Stream Control Transmission Protocol", RFC 2960, October 2000.
+
+ [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+ Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:
+ Basic and Digest Access Authentication", RFC 2617, June 1999.
+
+ [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
+ Information in Internet Messages: The Content-Disposition Header
+ Field", RFC 2183, August 1997.
+
+ [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
+ Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
+ Objects", RFC 3204, December 2001.
+
+ [20] Braden, R., "Requirements for Internet Hosts - Application and
+ Support", STD 3, RFC 1123, October 1989.
+
+ [21] Alvestrand, H., "IETF Policy on Character Sets and Languages",
+ BCP 18, RFC 2277, January 1998.
+
+ [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
+ Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+ RFC 1847, October 1995.
+
+ [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
+ 1999.
+
+ [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633,
+ June 1999.
+
+ [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [26] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+30 Informative References
+
+ [27] R. Pandya, "Emerging mobile and personal communication systems,"
+ IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.
+
+ [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+ "RTP: A Transport Protocol for Real-Time Applications", RFC
+ 1889, January 1996.
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 262]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming
+ Protocol (RTSP)", RFC 2326, April 1998.
+
+ [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and
+ J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November
+ 2000.
+
+ [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
+ "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+ [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
+ scheme", RFC 2368, July 1998.
+
+ [33] E. M. Schooler, "A multicast user directory service for
+ synchronous rendezvous," Master's Thesis CS-TR-96-18, Department
+ of Computer Science, California Institute of Technology,
+ Pasadena, California, Aug. 1996.
+
+ [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
+
+ [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+ 1992.
+
+ [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC
+ 2426, September 1998.
+
+ [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
+ Specification", RFC 2849, June 2000.
+
+ [38] Palme, J., "Common Internet Message Headers", RFC 2076,
+ February 1997.
+
+ [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+ Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
+ Digest Access Authentication", RFC 2069, January 1997.
+
+ [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis,
+ D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call
+ Flow Examples", Work in Progress.
+
+ [41] E. M. Schooler, "Case study: multimedia conference control in a
+ packet-switched teleconferencing system," Journal of
+ Internetworking: Research and Experience, Vol. 4, pp. 99--120,
+ June 1993. ISI reprint series ISI/RS-93-359.
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 263]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ [42] H. Schulzrinne, "Personal mobility for multimedia services in
+ the Internet," in European Workshop on Interactive Distributed
+ Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar.
+ 1996.
+
+ [43] Floyd, S., "Congestion Control Principles", RFC 2914, September
+ 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 264]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+A Table of Timer Values
+
+ Table 4 summarizes the meaning and defaults of the various timers
+ used by this specification.
+
+Timer Value Section Meaning
+----------------------------------------------------------------------
+T1 500ms default Section 17.1.1.1 RTT Estimate
+T2 4s Section 17.1.2.2 The maximum retransmit
+ interval for non-INVITE
+ requests and INVITE
+ responses
+T4 5s Section 17.1.2.2 Maximum duration a
+ message will
+ remain in the network
+Timer A initially T1 Section 17.1.1.2 INVITE request retransmit
+ interval, for UDP only
+Timer B 64*T1 Section 17.1.1.2 INVITE transaction
+ timeout timer
+Timer C > 3min Section 16.6 proxy INVITE transaction
+ bullet 11 timeout
+Timer D > 32s for UDP Section 17.1.1.2 Wait time for response
+ 0s for TCP/SCTP retransmits
+Timer E initially T1 Section 17.1.2.2 non-INVITE request
+ retransmit interval,
+ UDP only
+Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction
+ timeout timer
+Timer G initially T1 Section 17.2.1 INVITE response
+ retransmit interval
+Timer H 64*T1 Section 17.2.1 Wait time for
+ ACK receipt
+Timer I T4 for UDP Section 17.2.1 Wait time for
+ 0s for TCP/SCTP ACK retransmits
+Timer J 64*T1 for UDP Section 17.2.2 Wait time for
+ 0s for TCP/SCTP non-INVITE request
+ retransmits
+Timer K T4 for UDP Section 17.1.2.2 Wait time for
+ 0s for TCP/SCTP response retransmits
+
+ Table 4: Summary of timers
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 265]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Acknowledgments
+
+ We wish to thank the members of the IETF MMUSIC and SIP WGs for their
+ comments and suggestions. Detailed comments were provided by Ofir
+ Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan,
+ Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John
+ Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema,
+ Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders
+ Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William
+ Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe
+ J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick
+ Workman.
+
+ Brian Rosen provided the compiled BNF.
+
+ Jean Mahoney provided technical writing assistance.
+
+ This work is based, inter alia, on [41,42].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 266]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Authors' Addresses
+
+ Authors addresses are listed alphabetically for the editors, the
+ writers, and then the original authors of RFC 2543. All listed
+ authors actively contributed large amounts of text to this document.
+
+ Jonathan Rosenberg
+ dynamicsoft
+ 72 Eagle Rock Ave
+ East Hanover, NJ 07936
+ USA
+
+ EMail: jdrosen@dynamicsoft.com
+
+
+ Henning Schulzrinne
+ Dept. of Computer Science
+ Columbia University
+ 1214 Amsterdam Avenue
+ New York, NY 10027
+ USA
+
+ EMail: schulzrinne@cs.columbia.edu
+
+
+ Gonzalo Camarillo
+ Ericsson
+ Advanced Signalling Research Lab.
+ FIN-02420 Jorvas
+ Finland
+
+ EMail: Gonzalo.Camarillo@ericsson.com
+
+
+ Alan Johnston
+ WorldCom
+ 100 South 4th Street
+ St. Louis, MO 63102
+ USA
+
+ EMail: alan.johnston@wcom.com
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 267]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+ Jon Peterson
+ NeuStar, Inc
+ 1800 Sutter Street, Suite 570
+ Concord, CA 94520
+ USA
+
+ EMail: jon.peterson@neustar.com
+
+
+ Robert Sparks
+ dynamicsoft, Inc.
+ 5100 Tennyson Parkway
+ Suite 1200
+ Plano, Texas 75024
+ USA
+
+ EMail: rsparks@dynamicsoft.com
+
+
+ Mark Handley
+ International Computer Science Institute
+ 1947 Center St, Suite 600
+ Berkeley, CA 94704
+ USA
+
+ EMail: mjh@icir.org
+
+
+ Eve Schooler
+ AT&T Labs-Research
+ 75 Willow Road
+ Menlo Park, CA 94025
+ USA
+
+ EMail: schooler@research.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 268]
+
+RFC 3261 SIP: Session Initiation Protocol June 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg, et. al. Standards Track [Page 269]
+