view Side-By-Side changes
Internet Engineering Task Force SIP WG
Internet Draft Jonathan Rosenberg
dynamicsoft
Henning Schulzrinne
Columbia U.
Gonzalo Camarillo
Ericsson
Alan Johnston
Worldcom
Jon Peterson
Neustar
Robert Sparks
dynamicsoft
Mark Handley
ACIRI
Eve Schooler
AT&T
draft-ietf-sip-rfc2543bis-06.txt
January 28,
draft-ietf-sip-rfc2543bis-07.txt
February 4, 2002
Expires: July Aug 2002
SIP: Session Initiation Protocol
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The Session Initiation Protocol (SIP) is 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
which 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 users 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 them to upload their current location for use by proxy
servers. SIP runs ontop of several different transport protocols.
Various Authors [Page a]
Internet Draft SIP January 28, February 4, 2002
Table of Contents
1 Introduction ........................................ 2
2 Overview of SIP Functionality ....................... 2
3 Terminology ......................................... 3
4 Overview of Operation ............................... 4
5 Structure of the Protocol ........................... 11
6 Definitions ......................................... 13
7 SIP Messages ........................................ 19
7.1 Requests ............................................ 20
7.2 Responses ........................................... 20 21
7.3 Header Fields ....................................... 21 22
7.3.1 Header Field Format ................................. 22
7.3.2 Header Field Classification ......................... 24 25
7.3.3 Compact Form ........................................ 25
7.4 Bodies .............................................. 25 26
7.4.1 Message Body Type ................................... 25 26
7.4.2 Message Body Length ................................. 25 26
7.5 Framing SIP messages ................................ 26 27
8 General User Agent Behavior ......................... 26 27
8.1 UAC Behavior ........................................ 27
8.1.1 Generating the Request .............................. 27
8.1.1.1 Request-URI ......................................... 27 28
8.1.1.2 To .................................................. 27 28
8.1.1.3 From ................................................ 28 29
8.1.1.4 Call-ID ............................................. 29 30
8.1.1.5 CSeq ................................................ 30 31
8.1.1.6 Max-Forwards ........................................ 30 31
8.1.1.7 Via ................................................. 31 32
8.1.1.8 Contact ............................................. 31 32
8.1.1.9 Supported and Require ............................... 32 33
8.1.1.10 Additional Message Components ....................... 32 33
8.1.2 Sending the Request ................................. 33
8.1.3 Loose Routing Policies .............................. 33
8.1.3.1 Modifying the Route header field .................... 33
8.1.3.2 Modifying the Request-URI ........................... 34
8.1.3.3 Destination Choice .................................. 34
8.1.3.4 Loop Avoidance ...................................... 34
8.1.4
8.1.3 Processing Responses ................................ 35
8.1.4.1 34
8.1.3.1 Transaction Layer Errors ............................ 35
8.1.4.2 34
8.1.3.2 Unrecognized Responses .............................. 35
8.1.4.3
8.1.3.3 Vias ................................................ 36
8.1.4.4 35
8.1.3.4 Processing Reliable 1xx Responses ................... 36
Various Authors [Page b]
Internet Draft SIP January 28, 2002
8.1.4.5 35
8.1.3.5 Processing 3xx responses ............................ 36
8.1.4.6 35
8.1.3.6 Processing 4xx responses ............................ 38 37
8.2 UAS Behavior ........................................ 39 38
8.2.1 Method Inspection ................................... 39 38
8.2.2 Header Inspection ................................... 39 38
Various Authors [Page b]
Internet Draft SIP February 4, 2002
8.2.2.1 To and Request-URI .................................. 39 38
8.2.2.2 Merged Requests ..................................... 40 39
8.2.2.3 Require ............................................. 40 39
8.2.3 Content Processing .................................. 41 40
8.2.4 Applying Extensions ................................. 42 41
8.2.5 Processing the Request .............................. 42 41
8.2.6 Generating the Response ............................. 42 41
8.2.6.1 Sending a Provisional Response ...................... 42 41
8.2.6.2 Headers and Tags .................................... 43 42
8.2.7 Stateless UAS Behavior .............................. 43 42
8.3 Redirect Servers .................................... 44 43
9 Canceling a Request ................................. 45
9.1 Client Behavior ..................................... 46 45
9.2 Server Behavior ..................................... 47 46
10 Registrations ....................................... 48 47
10.1 Overview ............................................ 48 47
10.2 Constructing the REGISTER Request ................... 49 48
10.2.1 Adding Bindings ..................................... 52 51
10.2.1.1 Setting the Expiration Interval of Contact
Addresses ...................................................... 52 51
10.2.1.2 Preferences among Contact Addresses ................. 53 52
10.2.2 Removing Bindings ................................... 53 52
10.2.3 Fetching Bindings ................................... 53 52
10.2.4 Refreshing Bindings ................................. 53
10.2.5 Setting the Internal Clock .......................... 54 53
10.2.6 Discovering a Registrar ............................. 54 53
10.2.7 Transmitting a Request .............................. 55 54
10.2.8 Error Responses ..................................... 55 54
10.3 Processing REGISTER Requests ........................ 55 54
11 Querying for Capabilities ........................... 58 57
11.1 Construction of OPTIONS Request ..................... 59 58
11.2 Processing of OPTIONS Request ....................... 59
12 Dialogs ............................................. 61 60
12.1 Creation of a Dialog ................................ 62 61
12.1.1 UAS behavior ........................................ 62 61
12.1.2 UAC behavior ........................................ 63 62
12.2 Requests within a Dialog ............................ 64 63
12.2.1 UAC Behavior ........................................ 65 63
12.2.1.1 Generating the Request .............................. 65 63
12.2.1.2 Processing the Responses ............................ 66 65
12.2.2 UAS behavior ........................................ 67 66
12.3 Termination of a Dialog ............................. 69 67
13 Initiating a Session ................................ 69
Various Authors [Page c]
Internet Draft SIP January 28, 2002 68
13.1 Overview ............................................ 69 68
13.2 Caller Processing ................................... 70 68
13.2.1 Creating the Initial INVITE ......................... 70 68
13.2.2 Processing INVITE Responses ......................... 72 71
13.2.2.1 1xx responses ....................................... 72 71
Various Authors [Page c]
Internet Draft SIP February 4, 2002
13.2.2.2 3xx responses ....................................... 72
13.2.2.3 4xx, 5xx and 6xx responses .......................... 72
13.2.2.4 2xx responses ....................................... 73 72
13.3 Callee Processing ................................... 74 73
13.3.1 Processing of the INVITE ............................ 74 73
13.3.1.1 Progress ............................................ 75 74
13.3.1.2 The INVITE is redirected ............................ 75
13.3.1.3 The INVITE is rejected .............................. 76 75
13.3.1.4 The INVITE is accepted .............................. 76
14 Modifying an Existing Session ....................... 77
14.1 UAC Behavior ........................................ 77
14.2 UAS Behavior ........................................ 79 78
15 Terminating a Session ............................... 80
15.1 Terminating a Dialog with a BYE Request ............. 81
15.1.1 UAC Behavior ........................................ 81
15.1.2 UAS Behavior ........................................ 82
16 Proxy Behavior ...................................... 82
16.1 Overview ............................................ 82
16.2 Stateful Proxy ...................................... 83
16.3 Request Validation .................................. 84
16.4 Making a Routing Decision ........................... 87
16.5 Request Processing .................................. 90
16.6 Response Processing ................................. 97
16.7 Processing Timer C .................................. 105
16.8 Handling Transport Errors ........................... 105
16.9 CANCEL Processing ................................... 105
16.10 Stateless Proxy ..................................... 106
16.11 Record-Route Example ................................ Summary of Proxy Route Processing ................... 108
16.11.1 Examples ............................................ 108
16.11.1.1 Basic SIP Trapezoid ................................. 108
16.11.1.2 Traversing a strict-routing proxy ................... 110
16.11.1.3 Rewriting Record-Route header field values .......... 112
17 Transactions ........................................ 109 113
17.1 Client Transaction .................................. 111 116
17.1.1 INVITE Client Transaction ........................... 112 116
17.1.1.1 Overview of INVITE Transaction ...................... 112 116
17.1.1.2 Formal Description .................................. 113 117
17.1.1.3 Construction of the ACK Request ..................... 116 120
17.1.2 non-INVITE Client Transaction ....................... 117 121
17.1.2.1 Overview of the non-INVITE Transaction .............. 117 121
17.1.2.2 Formal Description .................................. 117 122
17.1.3 Matching Responses to Client Transactions ........... 118 123
17.1.4 Handling Transport Errors ........................... 120 123
17.2 Server Transaction .................................. 120 123
17.2.1 INVITE Server Transaction ........................... 120 125
17.2.2 non-INVITE Server Transaction ....................... 123 126
17.2.3 Matching Requests to Server Transactions ............ 124 129
17.2.4 Handling Transport Errors ........................... 131
Various Authors [Page d]
Internet Draft SIP January 28, February 4, 2002
17.2.4 Handling Transport Errors ........................... 126
17.3 RTT Estimation ...................................... 126 131
18 Reliability of Provisional Responses ................ 127 132
18.1 UAS Behavior ........................................ 128 132
18.2 UAC Behavior ........................................ 130 135
19 Transport ........................................... 131 136
19.1 Clients ............................................. 132 137
19.1.1 Sending Requests .................................... 132 137
19.1.2 Receiving Responses ................................. 134 138
19.2 Servers ............................................. 134 139
19.2.1 Receiving Requests .................................. 134 139
19.2.2 Sending Responses ................................... 135 140
19.3 Framing ............................................. 136 141
19.4 Error Handling ...................................... 136 141
20 Usage of HTTP Authentication ........................ 137 141
20.1 Framework ........................................... 137 142
20.2 User-to-User Authentication ......................... 139 144
20.3 Proxy to User Proxy-to-User Authentication ........................ 141 145
20.4 The Digest Authentication Scheme .................... 143 148
20.4.1 HTTP Digest ......................................... 143 148
21 S/MIME .............................................. 145 150
21.1 S/MIME Certificates ................................. 145 150
21.2 S/MIME Key Exchange ................................. 146 151
21.3 Securing MIME bodies ................................ 148 153
21.4 Tunneling SIP in MIME ............................... 149 154
21.4.1 Integrity and Confidentiality Properties of SIP
Headers ........................................................ 155
21.4.1.1 Integrity ........................................... 155
21.4.1.2 Confidentiality ..................................... 155
21.4.2 Tunneling Integrity and Authentication .............. 149
21.4.2 156
21.4.3 Tunneling Encryption ................................ 151 158
22 Security Considerations ............................. 152 159
22.1 Attacks and Threat Models ....................................... 153 ........................... 159
22.1.1 Registration Hijacking .............................. 153 160
22.1.2 Impersonating a Server .............................. 154 160
22.1.3 Tampering with Message Bodies ....................... 154 161
22.1.4 Tearing Down Sessions ............................... 155 162
22.1.5 Denial of Service and Amplification ................. 156 162
22.2 Security Mechanisms ................................. 156 163
22.2.1 Transport and Network Layer Security ................ 157 164
22.2.2 HTTP Authentication ................................. 158 165
22.2.3 S/MIME .............................................. 158 165
22.3 Implementing Security Mechanisms .................... 159 166
22.3.1 Requirements for Implementers of SIP ................ 159 166
22.3.2 Security Solutions .................................. 160 167
22.3.2.1 Registration ........................................ 160 167
22.3.2.2 Requests and Transitive Trust ....................... 161 168
22.3.2.3 Peer to Peer Requests ............................... 163 170
22.3.2.4 DoS Protection ...................................... 164 171
Various Authors [Page e]
Internet Draft SIP February 4, 2002
22.4 Limitations ......................................... 165 172
22.4.1 HTTP Digest ......................................... 165 172
22.4.2 S/MIME .............................................. 166
Various Authors [Page e]
Internet Draft SIP January 28, 2002 173
22.4.3 TLS ................................................. 167 174
22.5 Privacy ............................................. 167 174
23 Common Message Components ........................... 168 175
23.1 SIP Uniform Resource Indicators ..................... 168 175
23.1.1 SIP URI Components .................................. 168 175
23.1.2 Character Escaping Requirements ..................... 172 179
23.1.3 Example SIP URIs .................................... 172 180
23.1.4 SIP URI Comparison .................................. 173 180
23.1.5 Forming Requests from a SIP URI ..................... 175 183
23.1.6 Relating SIP URIs and tel URLs ...................... 176 184
23.2 Option Tags ......................................... 178 186
23.3 Tags ................................................ 179 186
24 Header Fields ....................................... 179 187
24.1 Accept .............................................. 181 189
24.2 Accept-Encoding ..................................... 181 189
24.3 Accept-Language ..................................... 184 192
24.4 Alert-Info .......................................... 184 192
24.5 Allow ............................................... 184 192
24.6 Authentication-Info ................................. 185 193
24.7 Authorization ....................................... 185 193
24.8 Call-ID ............................................. 186 194
24.9 Call-Info ........................................... 186 194
24.10 Contact ............................................. 186 195
24.11 Content-Disposition ................................. 187 196
24.12 Content-Encoding .................................... 188 196
24.13 Content-Language .................................... 189 197
24.14 Content-Length ...................................... 189 197
24.15 Content-Type ........................................ 189 198
24.16 CSeq ................................................ 190 198
24.17 Date ................................................ 190 198
24.18 Error-Info .......................................... 191 199
24.19 Expires ............................................. 191 199
24.20 From ................................................ 191 200
24.21 In-Reply-To ......................................... 192 200
24.22 Max-Forwards ........................................ 192 201
24.23 Min-Expires ......................................... 193 201
24.24 MIME-Version ........................................ 193 201
24.25 Organization ........................................ 193 202
24.26 Priority ............................................ 194 202
24.27 Proxy-Authenticate .................................. 194 203
24.28 Proxy-Authorization ................................. 195 203
24.29 Proxy-Require ....................................... 195 204
24.30 RAck ................................................ 195 204
24.31 Record-Route ........................................ 196 204
24.32 Reply-To ............................................ 196 204
Various Authors [Page f]
Internet Draft SIP February 4, 2002
24.33 Require ............................................. 196 205
24.34 Retry-After ......................................... 197 205
24.35 Route ............................................... 197
Various Authors [Page f]
Internet Draft SIP January 28, 2002 206
24.36 RSeq ................................................ 198 206
24.37 Server .............................................. 198 206
24.38 Subject ............................................. 198 207
24.39 Supported ........................................... 199 207
24.40 Timestamp ........................................... 199 207
24.41 To .................................................. 199 208
24.42 Unsupported ......................................... 200 208
24.43 User-Agent .......................................... 200 208
24.44 Via ................................................. 200 209
24.45 Warning ............................................. 201 210
24.46 WWW-Authenticate .................................... 203 211
25 Response Codes ...................................... 203 212
25.1 Provisional 1xx ..................................... 204 212
25.1.1 100 Trying .......................................... 204 212
25.1.2 180 Ringing ......................................... 204 212
25.1.3 181 Call Is Being Forwarded ......................... 204 212
25.1.4 182 Queued .......................................... 204 212
25.1.5 183 Session Progress ................................ 204 213
25.2 Successful 2xx ...................................... 205 213
25.2.1 200 OK .............................................. 205 213
25.3 Redirection 3xx ..................................... 205 213
25.3.1 300 Multiple Choices ................................ 205 213
25.3.2 301 Moved Permanently ............................... 205 214
25.3.3 302 Moved Temporarily ............................... 206 214
25.3.4 305 Use Proxy ....................................... 206 214
25.3.5 380 Alternative Service ............................. 206 214
25.4 Request Failure 4xx ................................. 206 215
25.4.1 400 Bad Request ..................................... 206 215
25.4.2 401 Unauthorized .................................... 207 215
25.4.3 402 Payment Required ................................ 207 215
25.4.4 403 Forbidden ....................................... 207 215
25.4.5 404 Not Found ....................................... 207 215
25.4.6 405 Method Not Allowed .............................. 207 215
25.4.7 406 Not Acceptable .................................. 207 215
25.4.8 407 Proxy Authentication Required ................... 207 216
25.4.9 408 Request Timeout ................................. 208 216
25.4.10 410 Gone ............................................ 208 216
25.4.11 413 Request Entity Too Large ........................ 208 216
25.4.12 414 Request-URI Too Long ............................ 208 216
25.4.13 415 Unsupported Media Type .......................... 208 216
25.4.14 416 Unsupported URI Scheme .......................... 208 217
25.4.15 420 Bad Extension ................................... 208 217
25.4.16 421 Extension Required .............................. 209 217
25.4.17 423 Registration Too Brief .......................... 209 217
25.4.18 480 Temporarily Unavailable ......................... 209 217
Various Authors [Page g]
Internet Draft SIP February 4, 2002
25.4.19 481 Call/Transaction Does Not Exist ................. 209 218
25.4.20 482 Loop Detected ................................... 210 218
25.4.21 483 Too Many Hops ................................... 210
Various Authors [Page g]
Internet Draft SIP January 28, 2002 218
25.4.22 484 Address Incomplete .............................. 210 218
25.4.23 485 Ambiguous ....................................... 210 218
25.4.24 486 Busy Here ....................................... 211 219
25.4.25 487 Request Terminated .............................. 211 219
25.4.26 488 Not Acceptable Here ............................. 211 219
25.4.27 491 Request Pending ................................. 211 219
25.4.28 493 Undecipherable .................................. 211 219
25.5 Server Failure 5xx .................................. 211 220
25.5.1 500 Server Internal Error ........................... 211 220
25.5.2 501 Not Implemented ................................. 212 220
25.5.3 502 Bad Gateway ..................................... 212 220
25.5.4 503 Service Unavailable ............................. 212 220
25.5.5 504 Server Time-out ................................. 212 220
25.5.6 505 Version Not Supported ........................... 212 221
25.5.7 513 Message Too Large ............................... 213 221
25.6 Global Failures 6xx ................................. 213 221
25.6.1 600 Busy Everywhere ................................. 213 221
25.6.2 603 Decline ......................................... 213 221
25.6.3 604 Does Not Exist Anywhere ......................... 213 221
25.6.4 606 Not Acceptable .................................. 213 222
26 Examples ............................................ 214 222
26.1 Registration ........................................ 214 222
26.2 Session Setup ....................................... 215 223
27 Augmented BNF for the SIP Protocol ................. 220 228
27.1 Basic Rules ......................................... 222 229
28 IANA Considerations ............................ 239 ................................. 246
28.1 Option Tags ......................................... 239 246
28.1.1 Registration of 100rel .............................. 240 247
28.2 Warn-Codes .......................................... 241 248
28.3 Header Field Names .................................. 241 248
28.4 Method and Response Codes ........................... 242 249
29 Changes Made in Version 00 .......................... 242
30 Changes Made in Version 01 .......................... From RFC 2543 ............................... 249
31
29.1 Major Functional Changes Made in Version 02 .......................... ............................ 249
32 Changes Made in Version 03 .......................... 251
33 Changes Made in Version 04 .......................... 254
34 Changes Made in Version 05 .......................... 256
35
29.2 Minor Functional Changes Made in Version 06 .......................... 260
36 ............................ 253
30 Acknowledgments ..................................... 272
37 254
31 Authors' Addresses .................................. 272
38 Bibliography ........................................ 274
EOTOC 255
32 Normative References ................................ 256
33 Non-Normative References ............................ 258
Various Authors [Page h]
Internet Draft SIP February 4, 2002
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 services 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. SIP works in
concert with these protocols by 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 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
The Session Initiation Protocol (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 [1] [29] - users can maintain
a single externally visible identifier (SIP URI) 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;
Various Authors [Page 2]
Internet Draft SIP January 28, February 4, 2002
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 [2]) [32]) for transporting real-time data and
providing QoS feedback, the real-time streaming protocol (RTSP) (RFC
2326 [3]) [35]) for controlling delivery of streaming media, the Media
Gateway Control Protocol (MEGACO) (RFC 3015 [4]) [43]) for controlling
gateways to the Public Switched Telephone Network (PSTN), and the
session description protocol (SDP) (RFC 2327 [5]) [11]) 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. SIP rather 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 parameters of a session can be agreed between
endpoints. 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 by SIP 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", "SHALLNOT", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
Various Authors [Page 3]
Internet Draft SIP January 28, February 4, 2002
and "OPTIONAL" are to be interpreted as described in RFC 2119 [6] [24]
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.
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 dashed lines
in Figure 1.
Alice "calls" Bob using his SIP identity, a type of Uniform Resource
Identifier (URI) called a SIP URI and defined in Section 23.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 (which can be
an enterprise, retail provider, etc). Alice also 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 is based on an HTTP-like request/response transacton 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 which 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:
Various Authors [Page 4]
Internet Draft SIP January 28, February 4, 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
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>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
Various Authors [Page 5]
Internet Draft SIP January 28, February 4, 2002
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 headers are briefly
described below:
Via contains the address (pc33.atlanta.com) on which Alice is
expecting to receive responses to this request.It request. It also contains a
branch parameter that contains an identifier for this transaction.
To contains a display name (Bob) and a SIP URI (sip:bob@biloxi.com)
towards which the request was originally directed. Display names are
described in RFC 2822 [7]. [20].
From also contains a display name (Alice) and a SIP URI
(sip:alice@atlanta.com) that indicate the originator of the request.
This header field also has a tag parameter containing a pseudorandom
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 pseudorandom string and the
softphone's IP address. The combination of the To, From, and Call-ID
completely define a peer-to-peer SIP relationship betwee 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, and is a traditional
sequence number.
Contact contains a SIP URI that represents a direct route to reach or
contact Alice, usually composed of a username at an FQDN. While a 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 for this
dialog.
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 24.
The details of the session, type of media, codec, sampling rate, etc.
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 Session Description Protocol (SDP) [5]. [11].
This SDP message (not shown in the example) is carried by the SIP
Various Authors [Page 6]
Internet Draft SIP January 28, February 4, 2002
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 IP
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, and CSeq 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 [8]. [2]. 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 that contains its own IP address
(the INVITE already contains Alice's IP 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 with its own IP
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 or not to answer the
call, i.e., Bob's phone rings. Bob's SIP phone sends an indication of
this in a 180 (Ringing) response, which is routed back through the
two proxies in the reverse direction. Each proxy uses the Via header
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
maintained in the proxies. This also has the desirable property that
Various Authors [Page 7]
Internet Draft SIP January 28, February 4, 2002
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 25. 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 pc33.atlanta.com;branch=z9hG4bK776asdhds server10.biloxi.com;branch=z9hG4bKnashds8
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 pc33.atlanta.com;branch=z9hG4bK776asdhds
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.8>
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 header fields, To, From, Call- ID, and CSeq are all copied
from the INVITE request. (There are three Via headers - 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 User
Agents into the dialog and will be included in all future 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-
Various Authors [Page 8]
Internet Draft SIP January 28, February 4, 2002
Type and Content-Length refer to the message body (not shown) that
contains Bob's SDP media information.
In additon 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, an
acknowledgement message, ACK, is sent by Alice to Bob to confirm the
reception of the final response (200 (OK)). In this example, the ACK
is sent directly from Alice to Bob, bypassing the two proxies. This
is because, through the INVITE/200 (OK) exchange, the two SIP user
agents have learned each other's IP address through the Contact
header fields, which was not known when the initial INVITE was sent.
The lookups performed by the two proxies are no longer needed, so
they drop out of the call flow. This completes the INVITE/200/ACK
three-way handshake used to establish SIP sessions and is the end of
the transaction. 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 agreed to 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. If the change is
accepted by the other party, a 200 (OK) is sent, which is itself
responded to with an ACK. This re-INVITE references the existing
dialog so the other party knows that it is to modify an existing
session instead of establishing a new session. If the change is not
accepted, an error response, such as a 406 (Not Acceptable), is sent,
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.
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
Various Authors [Page 9]
Internet Draft SIP January 28, February 4, 2002
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.
Full details of all the messages shown in the example of Figure 1 are
shown in Section 26.2.
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 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
messaging, and that messaging will go 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 URI
(sip:bob@biloxi.com) with the machine he is currently logged in at
(conveyed as a SIP URI in the Contact header). 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
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
Various Authors [Page 10]
Internet Draft SIP January 28, February 4, 2002
contains information that allows a proxy to input a URI and get back
a translated URI that tells 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 programmed, 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, challenge/response mechanism, or
using a lower layer scheme as discussed in Section 22.
The complete set of SIP message details for this registration example
is in Section 26.1.
Additional operations in SIP, such as querying for the capabilities
of a SIP server or client using OPTIONS, canceling a pending request
using CANCEL, or supporting reliability of provisional responses
using PRACK 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 is structured into layers for the purpose of presentation
and conciseness; it allows the grouping of functions common across
elements into a single place. 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 a BNF. The complete BNF is specified in Section 27.
However, a basic overview of the structure of a SIP message can be
found in Section 7. This section provides enough understanding of the
format of a SIP message to facilitate understanding the remainder of
the protocol.
The next higher layer is the transport layer. This layer defines how
a client takes a request and physically sends it over the network,
and how a response is sent by a server and then received by a client.
All SIP elements contain a transport layer. The transport layer is
described in Section 19.
Various Authors [Page 11]
Internet Draft SIP January 28, February 4, 2002
The next higher 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 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 an FSM that is
constructed to process a particular request. The layer on top of the
transaction layer is called the transaction user (TU), of which there
are several types. 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 which 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. Cancellation is described in Section 9.
There are several different types of transaction users. A UAC
contains a UAC core, a UAS contains a UAS core, and a proxy contains
a proxy core. The behavior of the UAC and UAS cores depend largely on
the method. However, there are some common rules for all methods.
These rules are captured in Section 8. They primarily deal with
construction of a request, in the case of a UAC, and processing of
that request and generation of a response, in the case of a UAS.
UAC and UAS core behavior for the REGISTER method is described in
Section 10. Registrations play an important role in SIP. In fact, a
UAS that handles a REGISTER is given a special name - a registrar -
and it is described in that section.
UAC and UAS core behavior for the OPTIONS method, used for
determining the capabilities of a UA, are described in Section 11.
Certain other requests are sent within a dialog. A dialog is a
peer-to-peer SIP relationship between two user agents that persists
Various Authors [Page 12]
Internet Draft SIP January 28, February 4, 2002
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 UAS core can generate provisional responses to requests, which
are responses that provide additional information about the request
processing but do not indicate completion. Normally, provisional
responses are not transmitted reliably. However, an optional
mechanism exists for them to be transmitted reliably. This mechanism
makes use of a method called PRACK, sent as a separate transaction
within the dialog between the UAC and UAS, which is used to
acknowledge a reliable provisional response.
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
This specification uses a number of terms to refer to the roles
played by participants in SIP communications. The terms and generic
syntax of URI and URL are defined in RFC 2396 [9]. [13]. The following
terms have special significance for SIP.
Back-to-Back user agent: A back-to-back user agent (B2BUA) is a
logical entity that receives a request and processes it as
an user agent server (UAS). In order to determine how the
request should be answered, it acts as an 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
Various Authors [Page 13]
Internet Draft SIP January 28, February 4, 2002
needed for its behavior.
Call: A call is an informal term that refers to a dialog between
peers generally set up for the purposes of a multimedia
conversation.
Call leg: Another name for a dialog.
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 stateful, but the
converse is not 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.
Dialog: A dialog is a peer-to-peer SIP relationship between a
UAC and 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 address, and remote address. 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 header
name, followed by a colon, followed by its value.
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
Various Authors [Page 14]
Internet Draft SIP January 28, February 4, 2002
role from the time it sends the initial INVITE which
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 purposes 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
adress-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 headers that affect proxy operation are unchanged, so
that the proxy would make the same processing decision on
the request it made the first time around. 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 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 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 all requests from a
client, even though it is not the server resolved by the
Request-URI. The outbound proxy sends these requests, after
any local processing, to the address indicated in the
Request-URI, or to another outbound proxy. Typically, a UA
Various Authors [Page 15]
Internet Draft SIP February 4, 2002
is manually configured with its outbound proxy, or can
learn it 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
Various Authors [Page 15]
Internet Draft SIP January 28, 2002
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. Normally, provisional responses are not
sent reliably. A provisional response that is sent reliably
is referred to as a reliable provisional response
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 passed on 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 the URIs in the Contact headers in the
response.
Redirect Server: A redirect server is a server that generates
3xx responses to requests it receives, directing the client
to contact an alternate URI.
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.
Reliable Provisional Response: A provisional response that is
sent reliably from the UAS to UAC.
Request: A SIP message sent from a client to a server, for the
Various Authors [Page 16]
Internet Draft SIP February 4, 2002
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
Various Authors [Page 16]
Internet Draft SIP January 28, 2002
alerted (ringing).
Route Refresh Request: A route refresh request sent within a
dialog is defined as a request that can modify the route
set of the dialog.
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 non-
2xx final response.
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 [5]) [11]) (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 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 sent from the server to the client, and the ACK
for the response in the case the response was a non-2xx.
The ACK for a 2xx response 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
Various Authors [Page 17]
Internet Draft SIP February 4, 2002
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.
Various Authors [Page 17]
Internet Draft SIP January 28, 2002
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 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 is said to be strict routing if it
follows the Route processing rules of RFC 2543 and many
prior Internet Draft 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.
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.
Upstream: A direction of message forwarding within a transaction
that refers to the direction that responses flow from the
user agent server to user agent client.
URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [10]. [4].
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 on, it assumes the role of a user
Various Authors [Page 18]
Internet Draft SIP February 4, 2002
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 on, 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
reside above the transaction and transport layers.
Various Authors [Page 18]
Internet Draft SIP January 28, 2002
User agent (UA): A logical entity that can act as both a user
agent client and user agent server for the duration of a
dialog.
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 ISO 10646 character set in
UTF-8 encoding (RFC 2279 [11]). [25]).
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 [7], [20], 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 (also known as "headers"), an empty line indicating the end of
the header fields, and an optional message-body.
Various Authors [Page 19]
Internet Draft SIP February 4, 2002
generic-message = start-line
*message-header
CRLF
[ message-body ]
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 [12]). [15]).
However, SIP is not an extension of HTTP.
Various Authors [Page 19]
Internet Draft SIP January 28, 2002
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 LWS is allowed in any of the
elements.
Method Request-URI SIP-Version
Method:
This specification defines seven methods: REGISTER for
registering contact information, INVITE, ACK, PRACK 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.
Request-URI: The Request-URI is a SIP URI as described in
Section 23.1 or a general URI (RFC 2396 [9]). [13]). 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", for example the "tel" URI scheme of RFC 2806
[13].
[19]. SIP elements MAY translate non-SIP URIs using any
Various Authors [Page 20]
Internet Draft SIP February 4, 2002
mechanism at their disposal, resulting in either a SIP 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
Various Authors [Page 20]
Internet Draft SIP January 28, 2002
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.
SIP-version Status-Code Reason-Phrase
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, e.g., in the language
indicated in the Accept-Language header field of the request.
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
Various Authors [Page 21]
Internet Draft SIP February 4, 2002
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 25 defines these classes and describes the individual codes.
7.3 Header Fields
SIP header fields are similar to HTTP header fields in both syntax
Various Authors [Page 21]
Internet Draft SIP January 28, 2002
and semantics. In particular, SIP header fields follow the [H4.2]
definitions of syntax for message-header, and the rules for extending
header fields over multiple lines, lines. However, the use of multiple message-header
fields latter is specified
in HTTP with the same field-name, implicit white space and the rules regarding ordering folding. This specification
conforms with RFC 2234 [28] and uses only explicit white space and
folding as an integral part of
header fields.
7.3.1 Header Field Format
Header fields follow the same generic header format as grammar.
[H4.2] also specifies that given in
Section 2.2 of RFC 2822 [7]. Each multiple header field consists fields of a the same field
name followed by whose value is a colon 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. This is also true for the Contact header, as long as
none of the header instances have a value of "*".
7.3.1 Header Field Format
Header fields follow the same generic header format as that given in
Section 2.2 of RFC 2822 [20]. Each header field consists of a field
Various Authors [Page 22]
Internet Draft SIP February 4, 2002
name followed by a colon (":") and the field value.
field-name: field-value
The formal grammar for a message-header specified in Section 27
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. Thus,
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
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 headers which are needed
for proxy processing (Via, Route, Record-Route, Proxy-Require,
Max-Forwards, Max-
Forwards, and Proxy-Authorization, for example) appear towards the
top of the message, to facilitate rapid parsing. The relative order
of header fields with the same field name is important. Multiple
header fields 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, #(values)). if follows the grammar defined in
Section 7.3). It MUST be
Various Authors [Page 22]
Internet Draft SIP January 28, 2002 possible to combine the multiple header
fields 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 exception to this rule are
the Authorization, Proxy-Authorization, Proxy-Authenticate and
Proxy-Authorization headers. Multiple header fields 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.
Various Authors [Page 23]
Internet Draft SIP February 4, 2002
Implementations MUST be able to process multiple header fields with
the same name in any combination of the single-value-per-line or
comma-separated value forms.
The following groups of header fields 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 headers 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)
Various Authors [Page 23]
Internet Draft SIP January 28, 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.
All new header fields MUST follow this generic format unless they
Various Authors [Page 24]
Internet Draft SIP February 4, 2002
have been inherited from other RFC 2822-like specifications.
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 appears in a message not matching its
category (such as a request header field in a response), it MUST be
Various Authors [Page 24]
Internet Draft SIP January 28, 2002
ignored. Section 24 defines the classification of each header field.
7.3.3 Compact Form
SIP provides a mechanism to represent common header fields in an
Various Authors [Page 25]
Internet Draft SIP February 4, 2002
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 24. A compact
form MAY be substituted for the longer form of a header name at any
time without changing the semantics of the message. The same type of
header field 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 [14] [8] 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.
Note that SIP messages MAY contain binary bodies or body parts.
7.4.2 Message Body Length
The body length in bytes is provided by the Content-Length header
field. Section 24.14 describes the necessary contents of this header
in detail.
Various Authors [Page 25]
Internet Draft SIP January 28, 2002
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.)
Various Authors [Page 26]
Internet Draft SIP February 4, 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 19 on constraints on usage of unreliable
transports.
Likewise, implementations processing SIP messages over stream-
oriented transports MUST ignore any CRLF appearing before the start-
line [H4.1]
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, it will pass 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, 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 22. 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.
Various Authors [Page 26]
Internet Draft SIP January 28, 2002
8.1 UAC Behavior
This section covers UAC behavior outside of a dialog.
8.1.1 Generating the Request
Various Authors [Page 27]
Internet Draft SIP February 4, 2002
A valid SIP request formulated by a UAC MUST at a minimum contain the
following headers: To, From, CSeq, Call-ID, Max-Forwards, and Via;
all of these headers are mandatory in all SIP messages. These six
headers 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 headers 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.
Another exception is
In some special circumstances, the case presence of a pre-existing Route headers; in that
case, route
set can affect the procedures Request-URI of Section 12.2.1.1 as they pertain to the
Request-URI are followed, even though there message. A pre-existing route
set is no dialog. Pre-
existing Route headers are an ordered set of URIs that identify a chain of servers servers, to
which outgoing requests from a UAC will be sent. send outgoing requests that are outside of a dialog.
Commonly, they are configured on the user agent by a user or service
provider manually, or through some non-SIP mechanism. They are most
often used When a provider
wishes to identify configure a local UA with an outbound proxy server through which proxy, it is RECOMMENDED
that this by done by providing it with a
UAC will send all requests, which in turn allows service providers to
maintain pre-existing route set with
a common point single URI, that of policy enforcement the outbound proxy.
When a pre-existing route set is present, the procedures for requests.
populating the Request-URI and Route header field detailed in Section
12.2.1.1 MUST be followed, even though there is no dialog.
8.1.1.2 To
The To general-header field first and foremost specifies the desired "logical"
recipient of the request, or the address of record 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 MAY contain a
SIP URI, but it may also make use of other URI schemes (the tel URL [13],
[19], for example) when appropriate. All SIP implementations MUST
support the SIP URI. The To header field allows for a display
Various Authors [Page 27]
Internet Draft SIP January 28, 2002 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
Various Authors [Page 28]
Internet Draft SIP February 4, 2002
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 (i.e., "bob"). It is at the discretion of the UA to
choose how to interpret this input. Using it to form the user part of
a SIP URL implies that the UA wishes the name to be resolved in the
domain the right hand side (RHS) of the at-sign in the SIP URI (i.e.,
sip:bob@example.com). The RHS will frequently be the home domain of
the user, which allows for the home domain to process the outgoing
request. This is useful for features like "speed dial" which require
interpretation of the user part in the home domain. The tel URL is
used when the UA does not wish to specify the domain that should
interpret the user input. Rather, each domain that the request passes
through 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 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 24.41.
The following is an example of valid To header:
To: Carol <sip:carol@chicago.com>
8.1.1.3 From
The From general-header field indicates the logical identity of the
initiator of the request, possibly the user's address of record.
Like the To field, it contains a URI and optionally a display name.
It is used by SIP elements to determine 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 the UA is running on, since these are not logical names.
The From header field allows for a display name. A UAC SHOULD use the
Various Authors [Page 28]
Internet Draft SIP January 28, 2002
display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:988776a@ahhs.aa), if the identity
of the client is to remain hidden.
Usually the value that populates the From header field in requests
Various Authors [Page 29]
Internet Draft SIP February 4, 2002
generated by a particular user agent is pre-provisioned by the user
or by the administrators of the user's local domain. If a particular
user agent 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 20 for more on
authentication).
The From field MUST contain a new "tag" parameter, chosen by the UAC.
See Section 23.3 for details on choosing a tag.
For further information on the From header see Section 24.20.
Examples:
From: "Bob" <sip:bob@biloxi.com> ;tag=a48s
From: sip:+12125551212@server.phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
8.1.1.4 Call-ID
The Call-ID general-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 MUST be selected by the UAC as a globally unique identifier
over space and time unless overridden by method specific behavior.
All SIP user agents must have a means to guarantee that the Call-ID
headers they produce will not be inadvertently generated by any other
user agent. Note that when requests are retried after certain 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
headers; see Section 8.1.4.6. 8.1.3.6.
Use of cryptographically random identifiers [15] [5] in the generation of
Call-IDs is RECOMMENDED. Implementations MAY use the form
Various Authors [Page 29]
Internet Draft SIP January 28, 2002
"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.
Various Authors [Page 30]
Internet Draft SIP February 4, 2002
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 see Section 24.8.
Example:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
8.1.1.5 CSeq
The Cseq header 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 requests outside of a dialog, the sequence
number value is arbitrary, but 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
8.1.1.6 Max-Forwards
The Max-Forwards header 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
Various Authors [Page 30]
Internet Draft SIP January 28, 2002
originates with a value of which SHOULD be 70.
8.1.1.7 Via
The Via header is used to indicate the transport used for the
transaction, and to identify the location where the response is This number was chosen to
be
sent.
When the UAC creates sufficiently large to guarantee that a request, 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, only in networks where topologies are
known by the UA.
Various Authors [Page 31]
Internet Draft SIP February 4, 2002
8.1.1.7 Via
The Via header is used to indicate the transport used for the
transaction, and to identify the location where the response is to be
sent.
When the UAC creates a request, it MUST insert a Via into that
request. The protocol and version in the header MUST be SIP and 2.0,
respectively. The Via header it inserts MUST contain a branch
parameter. This parameter is used to uniquely 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 time for all
requests sent by the UA. The exception to this rule is CANCEL. As
discussed below, a CANCEL request will have the same value of the
branch parameter as the request it cancels.
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
specification (i.e., 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 19).
Via processing for proxies is described in Sections 3 and sec:proxy-
response-processing-via.
8.1.1.8 Contact
The Contact header provides a SIP URI that can be used to contact
that specific instance of the user agent for subsequent requests. The
Contact header MUST be present 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 the dialog. global. That is, the
Various Authors [Page 31]
Internet Draft SIP January 28, 2002 Contact
header refers to the URI at which the UA would like to receive
requests, for and this URI MUST be valid even if used in subsequent
Various Authors [Page 32]
Internet Draft SIP February 4, 2002
requests that are part outside of that dialog only. any dialogs. Only a single URI MUST be present.
For further information on the Contact header, see Section 24.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 in
the request listing the option tags (Section 23.2) for those
extensions. This includes support for reliability for provisional
responses, which is an extension even though it is defined within
this specification. The option tag for reliability of provisional
responses is 100rel
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 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 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 traversed understand
that extension, it MUST insert a Proxy-Require header into the
request listing the option tag for that extension.
As with the Supported header, the option-tags in the Require header
MUST only refer to extensions defined in standards-track RFCs.
A Require header in a request with the option tag 100rel means that
the UAC wishes for all provisional responses to this request to be
transmitted reliably. This header MUST NOT be present in any requests
excepting INVITE, although extensions to SIP may allow its usage with
other request methods.
8.1.1.10 Additional Message Components
After a new request has been created, and the headers described above
have been properly constructed, any additional optional headers are
added, as are any headers specific to the method.
SIP requests MAY contain a MIME-encoded message-body. Regardless of
Various Authors [Page 32]
Internet Draft SIP January 28, 2002
the type of body that a request contains, certain headers must be
formulated to characterize the contents of the body. For further
Various Authors [Page 33]
Internet Draft SIP February 4, 2002
information on these headers see Sections 24.14, 24.15 and 24.12.
8.1.2 Sending the Request
The destination for the request is then computed. A loose-routing
element MAY use Unless there is
local policy to determine the IP address, port, and
transport used to reach the destination. One example of such a policy
is an element configured to send requests to a default outbound
proxy. Section 8.1.3 discusses restrictions on loose-routing
policies. For other elements, specifying otherwise, then the destination can MUST be
determined by applying the DNS proceedures described in [8] [2] 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 proceedures MUST be applied to the Request-URI. Request-URI of the
request. Otherwise, the proceedures 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.
Local policy MAY specify an alternate set of destinations to attempt.
There are no restrictions on the alternate destinations if the
request contains no Route headers. This provides a simple alternative
to a pre-existing route set as way to specify an outbound proxy.
However, that approach for configuring outbound proxy is NOT
RECOMMENDED; a pre-existing route set with a single URI SHOULD be
used instead. If the request contains Route headers, the request 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).
The UAC SHOULD follow the procedures defined
there in [2] for stateful
elements, trying each address until a server is contacted. Each try
constitutes a new transaction, and therefore each carries a different
Via header with a new branch parameter. Furthermore, the transport
value in the Via header is set to whatever transport was determined
for the target server.
8.1.3 Loose Routing Policies
An element MAY apply a local loose-routing policy when preparing and
sending a request. This policy MAY affect Processing Responses
Responses are first processed by the Request-URI transport layer and Route
header field values in the request as well as where then passed
up to the request is
sent, transaction layer. The transaction layer performs its
processing and what transport mechanism is used then passes it up to send it.
Elements SHOULD use the strict-routing policy TU. The majority of removing the topmost
value from a route set, placing it response
processing in the Request-URI and sending TU is method specific. However, there are some
general behaviors independent of the
request to method.
8.1.3.1 Transaction Layer Errors
In some cases, the location indicated response returned by the transaction layer will
not be a SIP message, but rather a transaction layer event. The only
event that URI.
This the TU will encounter is the behavior of elements implementing earlier
strict versions of Route/Record-Route.
Where appropriate, elements MAY deviate from timeout event. When the strict-routing
policy as long as the following restrictions are met:
8.1.3.1 Modifying the Route header field
A loose-routing element MAY remove the topmost Route header field
value. It MUST remove the topmost Route header field value if that
value indicates a resource this element is responsible for. The
element MUST NOT modify or remove any subsequent Route header field
values. The element MAY place additional Route header field values
into the Route header field before any existing values (effectivly
pushing values onto the top of the Route set).
Various Authors [Page 33]
Internet Draft SIP January 28, 2002
A loose-routing element may chose to not remove the first
Route header field value. For example, elements configured
to use default outbound proxies in liu of using the DNS
resolution proceedures will leave the topmost Route header
field value in the message.
When the topmost Route header field value indicates a
resource this element
timeout event is responsible for, the message has
reached the element indicated by the route, and that value
must be removed received from the Route header field. This assures
that Route header field values are consumed when the
destination they indicate has been reached.
8.1.3.2 Modifying the Request-URI
If the Request-URI identifies a resource for which this element is
responsible, the loose-route policy SHOULD include modifying the
Request-URI before sending the request.
This restriction ensures that a Request-URI is modified
once the resource it indicates has been reached.
8.1.3.3 Destination Choice
A loose-routing policy MUST direct the request to or the resource
indicated in the first Route header field value, or to a proxy transaction layer, it
trusts to ensure this property.
This restriction ensures the resource indicated by the
topmost Route header field value is actually visited.
8.1.3.4 Loop Avoidance
The Request-URI of a request emitted by a loose-routing element MUST
differ from the URI in the first Route header field value.
This restriction is necessary to avoid triggering false loop
detections in older systems. The following algorithm can be applied
to ensure sufficient difference in otherwise matching Request-URIs
and first Route header field values.
For each of these items, D is the address of the next hop (which may
or may not be equivalent to A).
If the topmost element in the received Route header field is
Various Authors [Page 34]
Internet Draft SIP January 28, February 4, 2002
<sip:a@A>, the outgoing request will contain
METHOD sip:a@A;maddr=D
Route: <sip:a@A>
If the topmost element in the received Route header field is
<sip:a@A;maddr=D>, the outgoing request will contain
METHOD sip:a@A
Route: <sip:a@A;maddr=D>
If the topmost element in the received Route header field is
<sip:a@A;maddr=B> and D!=B, the outgoing request will contain
METHOD sip:a@A;maddr=D
Route: <sip:a@A;maddr=B>
8.1.4 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 it 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.4.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 event. The only
event that the TU will encounter is the timeout event. When the
timeout event is received from the transaction layer, it MUST be
treated as if a 408 (Request Timeout) status code has been received.
8.1.4.2
8.1.3.2 Unrecognized Responses
A UAC MUST treat any 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.
Various Authors [Page 35]
Internet Draft SIP January 28, 2002
8.1.4.3
8.1.3.3 Vias
If more than one Via header field is present in a response, the UAC
SHOULD discard the message.
The presence of additional Via header fields that precede
the originator of the request suggests that the message was
misrouted or possibly corrupted.
8.1.4.4
8.1.3.4 Processing Reliable 1xx Responses
A 1xx response that contains a Require header with the option tag
100rel is a reliable provisional response. The UA core follows the
procedures in Section 18.2 to process the response, which will result
in the generation of a PRACK request to acknowledge the reliable
provisional response.
8.1.4.5
8.1.3.5 Processing 3xx responses
Upon receipt of a redirection response (for example, a 3xx 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.
If more than one URI is present in Contact header fields within the
3xx response, the UA MUST determine an order in which these contact
addresses should be processed. UAs MUST consult the "q" parameter
value of the Contact header fields (see Section 22.10) 24.10) if available.
Contact addresses MUST be ordered from highest qvalue to lowest. If
no qvalue is present, a contact address is considered to have a
qvalue of 1.0. Note that two or more contact addresses might have an
equal qvalue - these URIs are eligible to be tried in parallel.
Once an ordered list has been established, UACs MUST try to contact
each URI in the ordered list in turn until a server responds. If
there are contact addresses with an equal qvalue, the UAC MAY decide
randomly on an order in which to process these addresses, or it MAY
attempt to process contact addresses of equal qvalue
Various Authors [Page 35]
Internet Draft SIP February 4, 2002
attempt to process contact addresses of equal qvalue in parallel.
Note that for example, the UAC may effectively divide the ordered
list into groups, processing the groups serially and processing the
destinations in each group in parallel.
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.
Various Authors [Page 36]
Internet Draft SIP January 28, 2002
Failures SHOULD be detected through failure response codes (codes
greater than 399) or network timeouts. Client transaction will report
any transport layer failures to the transaction user.
When a failure for a particular contact address is recieved, 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 Contact header into
the Request-URI, except for the "method-param" and "header" URI
parameters (see Section 23.1.1 for a definition of these parameters).
It uses the "header" parameters to create headers for the new
request, overwriting headers associated with the redirected request
in accordance with the guidelines in Section 23.1.5.
Note that in some instances, headers that have been communicated in
the contact address may instead append to existing request headers in
the original redirected request. As a general rule, if the header can
accept a comma-separated list of values, then the new header value
MAY be appended to any existing values in the original redirected
request. If the header does not accept multiple values, the value in
the original redirected request MAY be overwritten by the header
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 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
Various Authors [Page 36]
Internet Draft SIP February 4, 2002
to update for example the Call-ID header field value for new
requests.
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.
In all other respects, requests sent upon receipt of a redirect
response SHOULD re-use the headers and bodies of the original
Various Authors [Page 37]
Internet Draft SIP January 28, 2002
request.
In some instances, Contact header values may be cached at UAC
temporarily or permanently depending on the status code received and
the presence of an expiration interval; see Sections 25.3.2 and
25.3.3.
8.1.4.6
8.1.3.6 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 20.2 and Section 20.3 to retry the request with
credentials.
If a 413 (Request Entity Too Large) response is received (Section
25.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
25.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 in the response, with
encodings listed in the Accept-Encoding header in the response, and
with languages listed in the Accept-Language in the response.
If a 416 (Unsupported URI Scheme) response is received (Section
25.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 25.4.15), the
request contained a Require or Proxy-Require header 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 in the response.
Various Authors [Page 37]
Internet Draft SIP February 4, 2002
In all of the above cases, the request is retried by creating a new
request with the appropriate modifications. This new request 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.
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
Various Authors [Page 38]
Internet Draft SIP January 28, 2002 case.
8.2 UAS Behavior
When a request outside of a dialog is processed by a UAS, there is a
set of processing rules which 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.
8.2.1 Method Inspection
Once a request is authenticated (or no authentication was desired),
the UAS MUST inspect the method of the request. If the UAS does not
support the method of a request it MUST generate a 405 (Method Not
Allowed) response. Procedures for generation of responses are
described in Section 8.2.6. The UAS MUST also add an Allow header 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 24.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 is not defined in this specification or in any supported
extension), the server MUST ignore that header and continue
processing the message. A UAS SHOULD ignore any malformed headers
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 in determination of whether to accept requests when the To
Various Authors [Page 38]
Internet Draft SIP February 4, 2002
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, 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
Various Authors [Page 39]
Internet Draft SIP January 28, 2002
server transaction layer 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 those contact
addressess. Other potential sources of received Request-URIs include
the Contact headers 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, the TU checks ongoing
transactions. If the To, From, Call-ID, CSeq exactly match (including
tags) those of any request received previously, but the branch-ID in
the topmost Via is different from those received previously, the TU
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 general-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
24.33. 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 of the request. Upon receipt of the 420
(Bad Extension) the client SHOULD retry the request, this time
Various Authors [Page 39]
Internet Draft SIP February 4, 2002
without using those extensions listed in the Unsupported header field
in the response.
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
headers should be ignored if they are present in these requests.
Various Authors [Page 40]
Internet Draft SIP January 28, 2002
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 is to make sure 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 headers 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), the UAS MUST reject the request with a 415
(Unsupported Media Type) response. The response MUST contain an
Accept header 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 listing the
encodings understood by the UAS. If the request contained content
Various Authors [Page 40]
Internet Draft SIP February 4, 2002
with languages not understood by the UAS, the response MUST contain
an Accept-Language header 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 content-specific
headers
Various Authors [Page 41]
Internet Draft SIP January 28, 2002 see Section 7.4 as well as Section 24.11 through 24.15.
8.2.4 Applying Extensions
A UAS that wishes to apply some extension when generating the
response MUST only do so if support for that extension is indicated
in the Supported header 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. To ensure that the SHOULD
can be fulfilled, any specification of a new extension MUST include
discussion of how to return gracefully to baseline SIP when the
extension is not present. 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 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 included in the response. Of course, the server MUST
NOT apply extensions not listed in the Supported header in the
request. As a result of this, the Require header 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
these procedures. Additional procedures may be needed depending on
the status code of the response and the circumstances of its
construction. These additional procedures are documented elsewhere.
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
Various Authors [Page 41]
Internet Draft SIP February 4, 2002
a non-INVITE request as sooon soon as possible.
When a 100 (Trying) response is generated, any Timestamp header
present in the request MUST be copied into this 100 (Trying)
Various Authors [Page 42]
Internet Draft SIP January 28, 2002
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 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 field of the
request. The Call-ID field of the response MUST equal the Call-ID
field of the request. The Cseq field of the response MUST equal the
Cseq field of the request. The Via headers in the response MUST equal
the Via headers in the request and MUST maintain the same ordering.
If a request contained a To tag in the request, the To field in the
response MUST equal that of the request. However, if the To field in
the request did not contain a tag, the URI in the To field in the
response MUST equal the URI in the To field in the request;
additionally, the UAS MUST add a tag to the To 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 generation of tags
are defined in Section 23.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 the replying to the first
instance of the request. Stateless UASs do not use a transaction
layer; they receive requests directly from the transport layer amd 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 transaction
state that might slow or complete completely halt call processing in a UAS,
effectively creating a denial of service condition; for more
information see Section 22.1.5.
Various Authors [Page 42]
Internet Draft SIP February 4, 2002
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.
Various Authors [Page 43]
Internet Draft SIP January 28, 2002
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 23.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 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 gathers the list of
alternative locations from the location service and either returns a
final response of class 3xx or it refuses the request. 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
Various Authors [Page 43]
Internet Draft SIP February 4, 2002
servers.
When a redirect server returns a 3xx response to a request, it
populates the list of (one or more) alternative locations into
Contact headers. An "expires" parameter to the Contact header may
also be supplied to indicate the lifetime of the Contact data.
The Contact header field contains URIs giving the new locations or
Various Authors [Page 44]
Internet Draft SIP January 28, 2002
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 redirect server SHOULD proxy the request to
the destination URI.
If a client is using an outbound proxy, and that proxy
actually redirects requests, a potential arises for
infinite redirection loops.
Note that the Contact header field MAY also refer to a different
entity than the one originally called. For example, a SIP call
connected to GSTN 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, [16]) [36]) URL.
The "expires" parameter of the Contact header field 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.
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.
Redirect servers MUST ignore features that are not understood
(including unrecognized headers, Required extensions, or even method
names) and proceed with the redirection of the session in question.
If a particular extension requires that intermediate devices support
it, the extension MUST be tagged in the Proxy-Require field as well
(see Section 24.29).
Various Authors [Page 44]
Internet Draft SIP February 4, 2002
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
Various Authors [Page 45]
Internet Draft SIP January 28, 2002
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
responded. Because of this, it is most useful to CANCEL requests to
which can take a long time to respond. For this reason, CANCEL is
most useful 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 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 any type of client,
including both proxies and user agent clients. Section 15 discusses
under what conditions a UAC would CANCEL an INVITE request, and
Section 16.9 discusses proxy usage of CANCEL.
Because a stateful proxy can generate its own CANCEL, a stateful
proxy also 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.
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, whose value matches the
top Via in the request being cancelled. Using the same values for
these headers 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 CSeq header MUST have a value of CANCEL. This
allows it to be identified and processed as a transaction in its own
Various Authors [Page 45]
Internet Draft SIP February 4, 2002
right (See Section 17).
If the request being cancelled contains Route header fields, the
CANCEL request MUST include these Route header fields.
This is needed so that stateless proxies are able to route
CANCEL requests properly.
Various Authors [Page 46]
Internet Draft SIP January 28, 2002
The CANCEL request MUST NOT contain any Require or Proxy-Require
header fields.
Once the CANCEL is constructed, the client SHOULD check whether any
response (provisional or final) has been received for the request
being cancelled (herein referred to as the "original request"). The
CANCEL request MUST NOT be sent if no provisional response has been
received, 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 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 transaction to be canceled is determined by
taking the CANCEL request, and then assuming that the request method
were anything but CANCEL, apply the transaction matching procedures
of Section 17.2.3. The matching transaction is the one to be
Various Authors [Page 46]
Internet Draft SIP February 4, 2002
canceled.
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.9 for proxy treatment of CANCEL.
A UAS first processes the CANCEL request according to the general UAS
Various Authors [Page 47]
Internet Draft SIP January 28, 2002
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 Require
header fields.
If the CANCEL did not find a matching transaction according to the
procedure above, the CANCEL SHOULD be responded to 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). The behavior
upon reception of a CANCEL request for any other method defined in
this specification is effectively no-op. Extensions to this
specification that define new methods MUST define the behavior of a
UAS upon reception of a CANCEL for those methods.
Regardless of the method of the original request, as long as the
CANCEL matched an existing transaction, the CANCEL request itself is
answered 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.
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) that at
which the destination user is reachable at. reachable. This discovery process is
accomplished by SIP proxy servers, which are responsible for
receiving a request, determining where to send it based on knowledge
Various Authors [Page 47]
Internet Draft SIP February 4, 2002
of the location of the user, and then sending it there. To do this,
proxies consult an abstract service known as a location service ,
which provides address bindings for a particular domain. These
address bindings map an incoming SIP URI, sip:bob@Biloxi.com , for
example, to one or more SIP URIs which that are somehow "closer" to the
desired user, sip:bob@engineering.Biloxi.com , for example.
Ultimately, a proxy will consult a location service which that maps a
received URI to the current host(s) that into which a user is logged in to.
Various Authors [Page 48]
Internet Draft SIP January 28, 2002 logged.
Registration creates bindings in a location service for a particular
domain that associate an address-of-record URI with one or more
contact addresses. This means that Thus, when a proxy for that domain receives a
request whose request URI 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 for a domain 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, however, mechanism for
a user agent UA to explicitly create a binding. binding explicitly. This mechanism is known as
registration.
Registration entails sending a REGISTER request to a special type of
UAS known as a registrar. The registrar acts as a front end to the
location service for a domain, reading and writing mappings based on
the contents of the REGISTER requests. This location service will
then be consulted by a proxy server that is responsible for routing
requests for that domain.
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 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 remove, and query bindings. A REGISTER request
may add a new binding between an address-of-record and one or more
contact addresses. Registration on behalf of a particular address-
of-record may be performed by a suitably authorized third party. A
Various Authors [Page 48]
Internet Draft SIP February 4, 2002
client may also remove previous bindings, 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. The
following header fields MUST be included:
Request-URI: The Request-URI names the domain of the location
Various Authors [Page 49]
Internet Draft SIP January 28, 2002
service that for which the registration is meant for (e.g., (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 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.
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 user agent client UAC SHOULD use the same Call-ID Call-
ID header 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 contain zero or more Contact header
fields, containing address bindings.
User agents
UAs MUST NOT send a new registration (i.e., (that is, containing new Contact
header fields, 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.
The following Contact header parameters have a special meaning in
REGISTER requests:
Various Authors [Page 49]
Internet Draft SIP February 4, 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
Various Authors [Page 50]
Internet Draft SIP February 4, 2002
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.
Various Authors [Page 50]
Internet Draft SIP January 28, 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
Various Authors [Page 51]
Internet Draft SIP January 28, 2002
Malformed values should be treated as equivalent to 3600.
10.2.1 Adding Bindings
The REGISTER request sent to a registrar includes contact addresses
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.
The Contact header fields of the request typically contain SIP 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,
[13])
[19]) or email addresses (with a mailto URL, [16]) [36]) as Contacts for an
address-of-record.
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 Contact header fields, a complete list of
bindings that have been registered for this address-of-record at this
registrar.
Registrations do not need to update all bindings. Typically, a UA
only updates its own SIP URI as well as any non-SIP URIs.
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.)
Various Authors [Page 51]
Internet Draft SIP February 4, 2002
There are two ways in which a client can suggest an expiration
interval for a binding: through an Expires header field, 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 fields that do
not contain the "expires" parameter.
Various Authors [Page 52]
Internet Draft SIP January 28, 2002
If neither mechanism for expressing a suggested expiration time is
present in a REGISTER, a default suggestion of one hour is assumed.
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 given in these
Contact headers header fields with the address-of-record present in the To
field. This list can be prioritized with the "q" parameter in the
Contact header fields. The "q" parameter indicates a relative
preference for the particular Contact header field compared to other
bindings present in this REGISTER message or existing within the
location service of the registrar. Section 16.5 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 user agent UA requests the immediate removal of a binding by
specifying an expiration interval of "0" for that contact address in
a REGISTER request. User agents 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 only be used when the Expires header
field is present with a value of "0".
Use of the "*" Contact header field value allows a
registering user agent UA to remove all of its bindings without
knowing their precise values.
If no Contact header fields are present in a REGISTER request, the
list of bindings is left unchanged.
10.2.3 Fetching Bindings
A success response to any REGISTER request contains the complete list
Various Authors [Page 52]
Internet Draft SIP February 4, 2002
of existing bindings, regardless of whether the request contained a
Contact header field or not. field.
10.2.4 Refreshing Bindings
Each UA is responsible to refresh the bindings that it has previously
established. A UA SHOULD NOT refresh bindings set up by other UAs.
Various Authors [Page 53]
Internet Draft SIP January 28, 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. using comparison
rules in Section 23.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 REGISTER request contains a Date header, 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
to:
registrations: by configuration, using the address-of-record 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 address-
of-record as the Request-URI and address the request there, using the
normal SIP server location mechanisms [8]. [2]. For example, the UA for
the user "sip:carol@chicago.com" addresses the REGISTER request to
"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. This request MUST be
scoped to ensure it is not forwarded beyond the boundaries of the
administrative system. This MAY be done with either TTL or
administrative scopes (see [17]), [12]), depending on what is implemented in
the network. SIP user agents UAs MAY listen to that address and use it to become
Various Authors [Page 53]
Internet Draft SIP February 4, 2002
aware of the location of other local users (see [18]); [40]); 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.
Various Authors [Page 54]
Internet Draft SIP January 28, 2002
10.2.7 Transmitting a Request
Once the REGISTER method has been constructed, and the destination of
the message identified, UACs should follow the procedures described
in Section 8.1.2 to hand off the REGISTER to the transaction layer.
If the transaction layer returns a timeout error because the REGISTER
yielded no response, the UAC SHOULD wait some reasonable time
interval before re-attempting a registration to the same registrar;
no specific interval is mandated.
10.2.8 Error Responses
If a UA receives a 423 (Registration 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 (Registration 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 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 does not generate 6xx responses.
If a registrar listens at a multicast interface, it MAY redirect
multicast REGISTER requests to its own unicast interface with a 302
(Moved Temporarily) response.
A REGISTER request MUST NOT contain Record-Route or Route header
fields; registrars MUST ignore them if they appear.
A registrar must know (e.g., (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
REGISTER requests are either processed completely or not at all.
Each REGISTER message must be processed independently of any other
Various Authors [Page 54]
Internet Draft SIP February 4, 2002
registration or binding changes.
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 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.
Various Authors [Page 55]
Internet Draft SIP January 28, 2002
2. To guarantee that the registrar supports any necessary
extensions, the registrar processes Require header fields
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
20; 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 a
authorization database that maps user names to a list of
addresses-of-record for which this identity is authorized
to modify bindings. If not, the registrar returns 403
(Forbidden) and skips 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 request. If the address-of-record is not
valid for the domain in the Request-URI, the registrar
sends a 404 (Not Found) response and skips the remaining
steps. The URI MUST then be converted to a canonical form.
To do that, all URI parameters are removed (including the user
param),
user-param), and any escaped characters are converted to
their unescaped form. The result serves as an index into
the list of bindings.
6. The registrar checks whether the request contains any
Various Authors [Page 55]
Internet Draft SIP February 4, 2002
Contact header fields. If not, it skips to the last step.
Next, the registrar checks if there is one Contact field
that contains the special value "*" and a Expires field. If
the request has additional Contact fields or an expiration
time other than zero, the request is invalid invalid, and the
server returns 400 (Invalid Request) and skips the
remaining steps. If not, the registrar checks whether the
Call-ID agrees with the value stored for each binding. If
not, it removes the binding. If it does agree, it only
removes the binding if the CSeq in the request is higher
than the value
Various Authors [Page 56]
Internet Draft SIP January 28, 2002 stored for that binding and leaves the
binding as is otherwise. It then skips to the last step.
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
is used.
- If there is no such parameter, but the request has an
Expires header field, that value is used.
- If there is neither, a locally-configured default value
is used.
The registrar MAY shorten the expiration interval. If and
only if the 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 (Registration 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
Various Authors [Page 56]
Internet Draft SIP February 4, 2002
degrade registrar performance.
For each address, it 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 has differs from
the same Call-ID value differs from in the request, the binding is 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
updates or removes
Various Authors [Page 57]
Internet Draft SIP January 28, 2002 the binding as above. If not, the update
is 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 are committed (i.e., (that is, made visible to
the proxy) if and only if all binding updates and additions
succeed. If any one of them fails, the request fails with
500 (Server Error) response and all tentative binding
updates are removed.
8. The registrar returns a 200 (OK) response. The response
MUST contain Contact header fields 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
codecs, etc.
supported without actually "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.
The target of the OPTIONS request is identified by the Request-URI,
which could identify another User Agent UA or a SIP Server. server. If the OPTIONS is
addressed to a proxy server, the Request-URI is set without a user
Various Authors [Page 57]
Internet Draft SIP February 4, 2002
part, similar to the way a Request-URI is set for a REGISTER request.
Alternatively, a server receiving an OPTIONS request with a Max-Forwards Max-
Forwards header 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
Various Authors [Page 58]
Internet Draft SIP January 28, 2002
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 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 which generated the OPTIONS
response.
Example OPTIONS request:
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKhjhs8ass877
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Various Authors [Page 58]
Internet Draft SIP February 4, 2002
Contact: <sip:alice@192.0.2.4>
Max-Forwards: 70
Accept: application/sdp
Content-Length: 0
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 is 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
Various Authors [Page 59]
Internet Draft SIP January 28, 2002
basic state of a UAS, which can be an indication of whether the UAC
will accept an INVITE request.
An OPTIONS request received within a dialog generates a 200 (OK)
response which 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 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 13.2.1
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 redirect. 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 in the OPTIONS request (application/sdp if the Accept
header was not present). If the types include one that can describe
media capabilities, the UA SHOULD include a body in the response for
that purpose. Details on construction of such a body in the case of
application/sdp are described in [19]. [1].
Various Authors [Page 59]
Internet Draft SIP February 4, 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 192.0.2.4;branch=z9hG4bKhjhs8ass877
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@100.1.3.3
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Various Authors [Page 60]
Internet Draft SIP January 28, 2002
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 a 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- 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 URI and local tag (together called the local
address), and a remote URI and remote tag (together called the remote
address). The dialog ID at each UA involved in the dialog is not the
same. Specifically, the local URI and local tag at one UA are
identical to the remote URI and 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
Various Authors [Page 60]
Internet Draft SIP February 4, 2002
request that contains a tag in the To field. The rules for computing
the dialog ID of a message depend on whether the entity 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 address is set to the To field of
the message, and the local address is set to the From 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 address is set to the From
field of the message, and the local address is set to 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
Various Authors [Page 61]
Internet Draft SIP January 28, 2002
its peer), a remote sequence number (used to order requests from its
peer to the UA), the URI of the remote target, and a route set, which
is an ordered list of URIs. The route set is the set 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 the final response comes.
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 to INVITE 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.
A dialog is identified by a dialog ID. A dialog ID consists of three
components, namely a call identifier component, a local address
component and a remote address component. UAs MUST assign values to
these 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
headers from the request into the response (including the URIs, URI
parameters, and any Record-Route header parameters, whether they are
known or unknown to the UAS) and MUST maintain the order of those
headers. 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
Various Authors [Page 61]
Internet Draft SIP February 4, 2002
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 URI and have
global scope (i.e., the same SIP URI can be used outside this dialog
to contact the UAS). The same way, the scope of the SIP URI in the
Contact header field of the INVITE is not limited to this dialog
either. It can therefore be used to contact 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. First, the
The route set MUST be computed by following these steps:
1. The set to the list of URIs in the Record-Route headers in the
request, if present, are taken, including any URI
Various Authors [Page 62]
Internet Draft SIP January 28, 2002
parameters.
2. The URI in the Contact
header field from the request if present,
is taken, including any request, taken in order and preserving all URI
parameters. The URI If no Record-Route header field is appended
to the bottom of the list of URIs from the previous step.
Contact was not mandatory present in RFC 2543. Thus, if the
UAS is communicating with an older UAC, the UAC might
not have inserted the Contact header field.
3. The resulting list of URIs is called
request, the route set
These rules clearly imply that a UA MUST be able set to parse
and process Record-Route header fields. the empty set. This is a change
from RFC 2543, where all record-route and route processing
was optional for user agents.
It is possible for the set,
even if empty, overrides any pre-existing route set to be empty. This will occur if
neither Record-Route headers nor a Contact header were present for future
requests in the
request. this dialog. The UAS remote target MUST also remember whether the bottom-most entry in
the route be set was constructed from a Contact header. This is
effectively a boolean value, which we refer to as CONTACT_SET. From
this value the UA can determine whether the bottom-most value can be
updated from subsequent requests; if it was constructed URI
from a
Contact, it can be updated. 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
address component of the dialog ID MUST be set to the To field in the
response to the request (which therefore includes the tag), and the
remote address component of the dialog ID MUST be set to 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.
12.1.2 UAC behavior
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. First, the
The route set MUST be computed by
following these steps:
Various Authors [Page 63]
Internet Draft SIP January 28, 2002
1. The set to the list of URIs present in the Record-Route headers in
header field from the
response are taken, if present, including all URI
parameters, and their response, taken in reverse order is reversed.
2. The and preserving
all URI in the Contact parameters. If no Record-Route header from the response, if
present, field is taken, including all URI parameters, and
appended to the end of the list from the previous step.
3. The list of URIs resulting from present in the above two operations is
referred to as
response, the route set
It is possible for the route MUST be set to be empty. the empty set. This will occur route set,
even if
neither Record-Route headers nor a Contact header were present empty, overrides any pre-existing route set for future
requests in the
response. this dialog. The UAC remote target MUST also remember whether the bottom-most entry in
the route be set was constructed from a Contact header. This is
effectively a boolean value, which we refer to as CONTACT_SET. From
this value the UA can determine whether the bottom-most value can be
updated from subsequent requests; if it was constructed URI
from a
Contact, it can be updated. the Contact header field of the response. The local sequence
number MUST be set to the value of the sequence number in the Cseq
Various Authors [Page 62]
Internet Draft SIP February 4, 2002
header field of the request. The remote sequence number MUST be empty
(it is established when the 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 address component of
the dialog ID MUST be set to the From field in the request, and the
remote address component of the dialog ID MUST be set to 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.
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. However, a
dialog imposes some restrictions on the use of simultaneous
transactions.
A TU MUST NOT initiate a new regular transaction within a dialog
while a regular transaction is in progress (in either direction)
within that dialog. If there is a non-INVITE client or server
transaction in progress the TU MUST wait until this transaction
enters the completed or the terminated state to initiate the new
transaction.
Various Authors [Page 64]
Internet Draft SIP January 28, 2002
OPEN ISSUE #113: Should we relax the constraint on non-
overlapping regular transactions?
A route refresh request sent within a dialog is defined as a request
that can modify the route set of the dialog. For dialogs that have
been established with an INVITE, the only route refresh request
defined is re-INVITE (see Section 14). Other extensions may define
different route refresh requests for dialogs established in other
ways.
Note that an ACK is NOT a route refresh request.
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 To header field of the request MUST be set to the remote address,
Various Authors [Page 63]
Internet Draft SIP February 4, 2002
and the From header field MUST be set to the local address (both
including tags, assuming the tags are not null).
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. 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 placed into the Cseq header. 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
MUST match the method of the request.
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 requests the request.
If the route set is determined according to empty, the following
rules: UAC MUST place the remote target URI
into the Request-URI. The UAC takes MUST NOT add a Route header field to
the list of request.
If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 23.1.1), the UAC MUST be inserted place
the remote target URI into
Various Authors [Page 65]
Internet Draft SIP January 28, 2002 the Request-URI of and MUST a Route header
field containing the request, route set values in order, including all URI
parameters. Any
If the route set is not empty and its first URI
parameters does not allowed in contain the Request-URI
lr parameter, the UAC MUST then be stripped. Each
of place the remaining URIs (if any) first URI from the route set , including all URI
parameters, MUST be placed
into the Request-URI, stripping any parameters that are not allowed
in a Request-URI. The UAC MUST add a Route header field into containing
the
request, remainder of the route set values in order.
A TU SHOULD follow order, including all
parameters. The UAC MUST then place the rules just mentioned to build the Request-URI
of remote target URI into
the request, regardless of whether Route header field as the UA uses an outbound proxy
server or not. However, in some instances, a UA may not be willing or
capable of sending last value.
For example, if the remote target is sip:user@remoteua and the route
set contains
Various Authors [Page 64]
Internet Draft SIP February 4, 2002
<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
The request to will be formed with the top element in 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
and therefore may does not be able to follow those procedures. to use a
loose-routing policy to send contain the lr
parameter, the request to its outbound proxy server
(see section 8.1.3). This policy MUST include placing indicated does not understand the topmost
element
routing mechanisms described in the route set this document and will act
as specified in RFC 2543, replacing the Request-URI with
the first Route header field value in it receives while
forwarding the message. Placing the Request-URI at the end
of the message's Route header field as well as in preserves the Request-URI. The loop-detection
avoidance algorithm described information in section 8.1.3 SHOULD that
Request-URI across the strict router (it will be applied returned
to the message before sending. Request-URI when the request reaches a loose-
router).
A UAC SHOULD include a Contact header in any route 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. As
discussed in Section 12.2.2, a Contact header in a route refresh
request updates the route set 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 route refresh requests do not affect
the route set remote target URI for the dialog.
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.1).
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 13.2.2.
Various Authors [Page 65]
Internet Draft SIP February 4, 2002
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.
If
When a UAC has a route set for a dialog and receives recieves a 2xx response to a route refresh resquest, it sent, the Contact header field of the response is
Various Authors [Page 66]
Internet Draft SIP January 28, 2002
examined. If not present, the route set remains unchanged. If the
response had a Contact header field, and the boolean variable
CONTACT_SET is false,
MUST replace the dialog's remote target URI in the Contact header field in the
response is added to the bottom of the route set , and CONTACT_SET is
set to true. If the route refresh request response had a Contact
header field, and CONTACT_SET is true, with the URI in from the
Contact header field of the response to the route refresh request replaces the
bottom value in the route set If a route refresh request is responded
with a non-2xx final response the route set remains unchanged as that response, if
no route refresh request had been issued. present.
If the response for the 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 is 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 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 missrouted. 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
Various Authors [Page 67]
Internet Draft SIP January 28, 2002
CSeq sequence numbers even across reboots, reconstructing the route
set ,
set, and accepting out-of-range RTP timestamps and sequence numbers.
Various Authors [Page 66]
Internet Draft SIP February 4, 2002
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.
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.
Requests within a dialog MAY contain Record-Route and Contact header
fields. However, these requests that are do not cause the dialog's route set
to be modified, although they may modify the remote target URI.
Specifically, requests which are not refresh requests do not
update modify
the dialog's remote target URI, and requests which are route set for the dialog. refresh
requests do. This specification only defines one route refresh
request: re-INVITE (see Section 14).
Special rules apply when updated Record-Route or Contact header
fields are received inside a route refresh request. If a UAS has a
route set for a dialog and receives a route refresh for that dialog
containing Record-Route header fields, it MUST copy those header
fields into any 2xx response to that request. If the boolean variable
CONTACT_SET is true, the Contact header field in the request (if
present) replaces the last entry in the route set is false, the UAS
MUST add the URI in the Contact header field in the route refresh
request to the bottom of the route set , and then set CONTACT_SET to
true. If the request did not contain a Contact header field, the
route-set at the UAS remains unchanged.
Route refresh requests only update the Contact of the route
set dialog's remote
target URI, and not the elements route set formed from Record-Route.
Updating the latter would introduce severe backwards
compatibility problems with RFC 2543-compliant systems.
If the remote sequence number is empty, it MUST be set to the value
of the sequence number in the Cseq header 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 header
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 in the
Various Authors [Page 68]
Internet Draft SIP January 28, 2002
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.
12.3 Termination of a Dialog
Dialogs can end in several different ways, depending on the method.
Various Authors [Page 67]
Internet Draft SIP February 4, 2002
When a dialog is established with INVITE, it is terminated with a
BYE. No other means to terminate a dialog are described in this
specification, but extensions can define other ways.
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 is
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 invitation. After some
time, those UAS 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 a provisional response (1xx), either reliably or
unreliably, to advise the UAC of progress in contacting the called
user.
After possibly receiving one or more provisional responses, the UA
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
Various Authors [Page 69]
Internet Draft SIP January 28, 2002
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.
13.2 Caller Processing
13.2.1 Creating the Initial INVITE
Various Authors [Page 68]
Internet Draft SIP February 4, 2002
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 24.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 [20] [39]
SHOULD include an Allow header listing the INFO method.
A Supported header field (Section 24.39) SHOULD be present in the
INVITE. It enumerates all the extensions understood by the UAC.
An Accept (Section 24.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 is
especially useful for indicating support of various session
description formats.
The UA MAY add an Expires header field (Section 24.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
original INVITE.
A UAC MAY also find useful to add, among others, Subject (Section
24.38), Organization (Section 24.25) and User-Agent (Section 24.43)
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".
Various Authors [Page 70]
Internet Draft SIP January 28, 2002
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 which apply to those means, and addresses for receiving
media from the offerer. The offer/answer model defines restrictions
on when offers and answers can be mapped into the
INVITE transaction made. This results in two ways. The first, which is the most
intuitive, is that the INVITE contains the offer, the 2xx response
contains restrictions
on where the answer, offers and no session description is provided answers can appear in the
ACK. SIP messages. In this model, the UAC is the offerer,
specification, offers and the UAS is the
answerer. A second model answers can only appear in INVITE and PRACK
Various Authors [Page 69]
Internet Draft SIP February 4, 2002
requests and responses. The usage of offers and answers is that further
restricted. For the initial INVITE contains no session
description, transaction, the 2xx response contains rules are:
o The initial offer MUST be in either an INVITE or, if not
there, in the offer, and first reliable message from the ACK
contains callee back to
the answer. caller. In this model, the UAS specification, that is either the offerer, and first
reliable provisional response or the
UAC is final 2xx response.
o If the answerer. The second model initial offer is useful for gateways in an INVITE, the answer MUST be in a
reliable message from
H.323v1 callee back to SIP, where caller which is
correlated to that INVITE. For this specification, that is
either a reliable provisional response or the H.323 media characteristics are not known
until final 2xx
response to that INVITE.
o If the call is established. This initial offer is also useful in the first reliable message from the
callee back to caller, the answer MUST be in the
acknowledgement for sessions that
use third-party call control. As message (PRACK for a result of these models, reliable
provisional response or 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 (PRACK
alone for this specification), but only if it has received
answers to any previous offers, and has not send any offers to
which it hasn't gotten an answer.
o Once the
INVITE contains a session description, UAS has sent or received an answer to the ACK initial
offer, it MUST NOT contain one.
Conversely, if generate subsequent offers in any responses
to the caller chooses INVITE. Since only the UAC can send PRACK, this means
the a UAS based on this specification alone can never generate
subsequent offers.
Extensions to SIP which define new methods MAY specify whether offers
and answers can appear in requests of that method or its responses.
However, those extensions MUST adhere to omit the session description protocol rules specified
in [2], and MUST adhere to the additional constraints in the list
above.
Concretely, the above rules specify two exchanges for UAs which don't
support reliable provisional responses - the offer is in the INVITE,
and the ACK MUST contain one (if a 2xx response answer in the 2xx, or the offer is received).
2xx in the 2xx, and the answer
is in the ACK. When reliable provisional responses is supported,
several more flows are possible. One possibility is to an INVITE MUST always contain have the offer
in the INVITE, and the answer in a session description. reliable provisional response,
with no further SDP exchanges.
All user agents that support INVITE and/or PRACK MUST support both models. all
exchanges that are possible based on the above rules and on their
support for PRACK.
Various Authors [Page 70]
Internet Draft SIP February 4, 2002
The Session Description Protocol (SDP) [5] [11] MUST be supported by all
user agents as a means to describe sessions, and its usage for
construction
constructing offers and answers MUST follow the procedures defined in
[19].
[1].
The restrictions of the offer-answer model (session description only
in the INVITE OR in the ACK, but not in both) just described only apply
to bodies whose Content-Disposition header field is "session".
Therefore, it is possible that both the INVITE and the ACK contain a
body message (e.g., 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".
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.
Various Authors [Page 71]
Internet Draft SIP January 28, 2002
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. Responses are matched to
their corresponding INVITE because they have the same Call-ID, the
same From header field, the same To header field, excluding the tag,
and the same CSeq. Rules for comparisons of these headers are
described in Section 24. 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.
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. This will be the case for all reliable
provisional responses, which require transmission of PRACK. Header
fields present in a provisional response are applicable as long as
the dialog is in the early state (e.g., an Allow header field in a
provisional response contains the methods that can be used in the
Various Authors [Page 71]
Internet Draft SIP February 4, 2002
dialog while this is in the early state).
If the 1xx is reliable and contains a session description, the UAC
MUST generate an answer if the description is an offer. If the
description is an answer, the session SHOULD be established based on
the parameters of the offer and answer.
13.2.2.2 3xx responses
A 3xx response may contain a Contact header field providing new
addresses where the callee might be reachable. Depending on the
status code of the 3xx response (see Section 25.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 indicating
the location where additional information about the error can be
found.
All early dialogs are considered terminated upon reception of the
non-2xx final response.
After having received the non-2xx final response the UAC core
considers the INVITE transaction completed. The INVITE client
transaction handles generation of ACKs for the response (see Section
Various Authors [Page 72]
Internet Draft SIP January 28, 2002
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.1.2. Otherwise, a new dialog in the "confirmed" state is
constructed in the same fashion.
The route set only is recomputed for backwards
compatibility. RFC 2543 did not mandate mirroring of
Record-Route headers in a 1xx, only 2xx. However, we cannot
update the entire state of the dialog, since mid-dialog
requests may have been sent within
Various Authors [Page 72]
Internet Draft SIP February 4, 2002
requests may have been sent within the early call leg,
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 INVITE did not contain 2xx contains an offer, offer (based on the 2xx will contain one, and
therefore rules above), the ACK MUST
carry an answer in its body. If the offer in the 2xx response is not acceptable
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 [8] [2] 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.
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
Various Authors [Page 73]
Internet Draft SIP January 28, 2002
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 caller
does not want to continue with that dialog, then the caller MUST
terminate the dialog by sending a BYE request as described in Section
15.
13.3 Callee 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 complete 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 inspects this header field. If the
Various Authors [Page 73]
Internet Draft SIP February 4, 2002
INVITE has already expired a 487 (Request Terminated)
response SHOULD be generated. In any case, if the INVITE
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
behaviour 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
Various Authors [Page 74]
Internet Draft SIP January 28, 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).
The INVITE may not contain a session description at all, in which
case the UAS is being asked to participate in a session, but the UAC
has asked that the UAS provide the offer of the session. It MUST
provide the offer in its first reliable message back to the UAC.
The callee 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
The UAS may not be able to answer the invitation immediately, and
might choose to indicate some kind of progress to the caller (for
example, an indication that a phone is ringing). This is accomplished
with a provisional response between 101 and 199. These provisional
Various Authors [Page 74]
Internet Draft SIP February 4, 2002
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 unless reliable provisional responses are used.
If the INVITE contained an offer, the UAS MAY generate an answer in a
reliable provisional response (assuming these are supported by the
UAC). That results in the establishment of the session before
completion of the call. Similarly, if a reliable provisional response
is the first reliable message sent back to the caller, and the INVITE
did not contain an offer, one MUST appear in that reliable
provisional response.
If the UAS will require an extended period of time to answer the
INVITE, it will need to ask for an "extension" in order to prevent
proxies from cancelling the transaction. A proxy has the option of
canceling a transaction when there is a gap of 3 minutes between
messages in a transaction. To prevent cancellation, the UAS MUST send
a non-100 provisional response at least that often. This response
SHOULD be sent reliably, if supported by the UAC. If not, the UAS
SHOULD send provisional responses 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
Various Authors [Page 75]
Internet Draft SIP January 28, 2002
containing 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 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
Various Authors [Page 75]
Internet Draft SIP February 4, 2002
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 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.
If the UAS had placed a session description in any reliable
provisional response that is unacknowledged when the INVITE is
accepted, the UAS MUST delay sending the 2xx until the provisional
response is acknowledged. Otherwise, the reliability of the 1xx
cannot be guaranteed.
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.
Therefore, it is necessary to pass periodically the response 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 is received with the same dialog ID as the response. This is
independent of whatever transport protocols are used to send the
response.
Various Authors [Page 76]
Internet Draft SIP January 28, 2002
Since 2xx is retransmitted end-to-end, there may be hops
between UAS and UAC which are UDP. To ensure reliable
delivery across these hops, the response is retransmitted
periodically even if the transport at the UAS is reliable.
Various Authors [Page 76]
Internet Draft SIP February 4, 2002
If the server retransmits the 2xx response for 64*T1 seconds without
receiving an ACK, it considers the dialog completed, the session
terminated, and therefore it SHOULD send a BYE.
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
route refresh request (e.g., (for example, changing the route set 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 at the same time the dialog and the
parameters of the session. session at the same time.
Either the caller or callee can modify an existing session.
The behaviour 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
maintains the idempotency of SIP,
supports stateless session processing in various elements, and
supports failover and recovery
Various Authors [Page 77]
Internet Draft SIP January 28, 2002 capabilities. Of course, a UAC MAY
send a re-INVITE with no session description, in which case the first
reliable response to the re-INVITE will contain the offer.
If the session description format has the capability for version
numbers, the offerer SHOULD indicate that the version of the session
Various Authors [Page 77]
Internet Draft SIP February 4, 2002
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 Alert-Info header fields or bodies with
Content-Disposition "alert" to re-INVITEs because UASs do not
typically alert the user upon reception of a re-INVITE.
Note that, as opposed to initial INVITEs (see Section 13), re-INVITEs
contain tags in the To header field and are sent using the route set
for the dialog. Therefore, a single final (2xx or non-2xx) response
is received for re-INVITEs.
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another transaction (INVITE or non-INVITE) is in
progress in either direction.
1. If there is an ongoing INVITE client transaction 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 transaction, the TU
MUST wait until the transaction reaches the confirmed or
terminated state before initiating the new INVITE.
3. If there is an ongoing non-INVITE client or server
transaction
transaction, the TU MUST wait until the transaction reaches
the completed or terminated state before initiating the new
INVITE.
However, a UA MAY initiate a regular transaction while an INVITE
transaction is in progress.
If a re-INVITE is responded with 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) Exist), or a 408
(Request
Timeout) Timeout), or no response at all is received for the re-INVITE (a re-
INVITE (that is, a timeout is returned by the INVITE client transaction)
transaction), the UAC will terminate the dialog.
Various Authors [Page 78]
Internet Draft SIP January 28, 2002
The rules for transmitting a re-INVITE and for generating an ACK for
a 2xx response to re-INVITE are the same as for an INVITE (Section
13.2.1).
14.2 UAS Behavior
Various Authors [Page 78]
Internet Draft SIP February 4, 2002
Section 13.3.1 describes the steps to follow in order to distinguish
incoming re-INVITEs from incoming initial INVITEs. This Section section
describes the procedures to follow upon reception of a re-INVITE for
an existing dialog.
A UAS that receives a second INVITE before it sent 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 and MUST include a Retry-After header
field with a value chosen as follows:
1. If the UAS is the owner of the Call-ID of the dialog ID ID,
the Retry-After header field has a randomly chosen value of
between 2.1 and 4 seconds in units of 10 ms.
2. If the UAS is not the owner of the Call-ID of the dialog ID
ID, the Retry-After header field has a randomly chosen
value of between 0 and 2 seconds in units of 10 ms.
If a user agent UA receives a re-INVITE for an existing dialog 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
user agent server 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. If the new session description is
not acceptable 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.
Various Authors [Page 79]
Internet Draft SIP January 28, 2002
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 reason, UASs MAY choose not to use Alert-Info
header fields or bodies with Content-Disposition "alert" in responses
to a re-INVITE either. re-INVITE.
Various Authors [Page 79]
Internet Draft SIP February 4, 2002
A UAS providing an offer in a 2xx (because the INVITE did not contain
an offer) MUST offer SHOULD construct the same session description offer as last provided to if the peer, with UAS were making a
brand new call, subject to the exception constraints of being able to change sending an offer which
updates an existing session, as described in [1] in the IP
address/port if so desired.
Under error conditions (e.g., 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 has crashed and
restarted) MUST
ensure that the session description overlaps with its previous
session description in media formats, transports, or other parameters
that require support from the 2xx response peer. This is to avoid the need for
an empty re-INVITE may be different than the one in use at
that moment. If
peer to reject the new session description description. If, however, it is not
acceptable for
unacceptable to the UAC, the UAC it SHOULD generate an answer with a
valid session description, and then send a BYE (after
ACKing to terminate the 2xx response).
session.
15 Terminating a Session
This section describes the procedures to be followed in order to
terminate for terminating a SIP dialog.
For two-party sessions that are otherwise unbound in time time, the
termination of the dialog implies the termination of the session.
Other types of sessions sessions, such as multicast sessions sessions, are not
terminated when a participant terminates the SIP dialog that he used
to join the session. However, the SIP dialog SHOULD be terminated
even though its termination does not imply the termination of the
session. A UA joining a multicast session MAY terminate the SIP
dialog immediately after the INVITE transaction used to join the
session has completed.
Either the caller or callee may terminate a dialog for any reason. A
caller terminates a dialog either with BYE of or CANCEL depending on the
state of the dialog. A callee uses BYE to terminate a confirmed
dialog.
If the callee wants to terminate an early dialog dialog, it just
returns a non-2xx final response for the INVITE. Sections
13 and 12 document some cases where dialog termination is
normative behavior. As a general rule, if If a UA decides that
the dialog is to be terminated, terminate the
dialog, it MUST follow the procedures here to initiate
signaling action to convey that.
When a UAC sends an INVITE request to create a session, if a 1xx
response with a tag in the To field is received, an early dialog is
created. When a 2xx response is received, the dialog becomes
confirmed. For a confirmed dialog, if the UAC desires to terminate
Various Authors [Page 80]
Internet Draft SIP January 28, 2002
the session, the UAC SHOULD follow the procedures described in
Section 15.1.1 to terminate the session. If the callee for a new
session wishes to terminate the dialog, it uses the procedures of
Section 15.1.1, but MUST NOT do so until it has received an ACK or
until the server transaction times out.
Various Authors [Page 80]
Internet Draft SIP February 4, 2002
This does not mean a user can't cannot hang up right away; it
just means that the software in their his phone needs to maintain
state for a short while in order to properly clean up. up properly.
If the UAC desires to end the session before a confirmed dialog has
been created, it SHOULD send a CANCEL for the INVITE request that
requested establishment of the session that is to be terminated. The
UAC constructs and sends the CANCEL following the procedures
described in Section 9. This CANCEL will normally result in a 487
(Request Terminated) response to be returned to the INVITE,
indicating successful cancellation. However, it is possible that the
CANCEL and a 2xx response to the INVITE "pass on the wire". In this
case, the UAC will receive a 2xx to the INVITE. It SHOULD then
terminate the call by following the procedures described in Section
15.1.1.
A UAC can terminate a specific early dialog by following the
procedures described in Section 15.1.1. This would only terminate one
particular early dialog.
15.1 Terminating a Dialog with a BYE Request
15.1.1 UAC Behavior
A user agent client uses the BYE request, sent within a dialog, to
indicate to the server that it wishes to terminate the session. This
will also terminate the dialog. A BYE request MAY be issued by either
caller or callee. A BYE request SHOULD NOT be sent before the
creation of a dialog (either early or confirmed). In that case the
UAC SHOULD follow the procedures described in Section 9 instead.
Proxies ensure that a CANCEL request is routed in the same
way as the INVITE was. However, a proxy performing load
balancing may route a BYE without a Route header field in a
different way than the INVITE, since both requests have
different CSeq sequence numbers.
The To, From, Call-ID, CSeq, and Request-URI of a BYE are set
following the same rules as for regular requests sent within a
dialog, described in Section 12.
Once the BYE is constructed, it creates a new non-INVITE client
Various Authors [Page 81]
Internet Draft SIP January 28, 2002
transaction, and passes it the BYE request. The user agent UA SHOULD stop
sending media as soon as the BYE request is passed to the client
transaction. If the response for the BYE is a a 481 (Call/Transaction
Does Not Exist) or a 408 (Request Timeout) or no response at all is
received for the BYE (a (that is, a timeout is returned by the client transaction)
transaction), the UAC considers the dialog down anyway. down.
Various Authors [Page 81]
Internet Draft SIP February 4, 2002
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 to see 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 MUST cease transmitting media streams for the session being
terminated. 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, (which can only be an INVITE). It is RECOMMENDED that a 487
(Request Terminated) response is 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 must first
decide if it needs to respond to the request on its own. For
instance, the request could be malformed or the element may need
credentials from the client before acting as a proxy. The element MAY
respond with any appropriate error code. When responding directly to
Various Authors [Page 82]
Internet Draft SIP January 28, 2002
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 routing decision based on the request. It
Various Authors [Page 82]
Internet Draft SIP February 4, 2002
simply forwards every response it receives upstream. A stateless
proxy discards information about a message once it has been
forwarded.
On the other hand, 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 chose to "fork" a
request, routing it to multiple destinations. Any request that is
forwarded to more than one location MUST be handled statefully. Any
request processed
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 (or any other mechanism that is
inherently stateful), 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 handled 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 send a CANCEL.
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 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.
Various Authors [Page 83]
Internet Draft SIP January 28, February 4, 2002
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.
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) .IP 2. Make a routing
decision (Section 16.4) .IP 3. Forward the request to each
chosen destination (Section 16.5) .IP 4. Process all
responses (Section 16.6)
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. Max-Forwards
3. (Optional) Loop Detection
4. Proxy-Require
5. 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
Processing section MUST be well-formed. Any other
components, well-formed or not, SHOULD be ignored and
remain unchanged when the message is forwarded. For
Various Authors [Page 84]
Internet Draft SIP January 28, February 4, 2002
+------------------------------+
| | +---+
| | | T|
| | | r|
| | |C a|
| | |l n|
| | |i s|
| | |e a|
| | |n c|
| | |t t|
| | | i|
| | | o|
| | | n|
| | +---+
+---+ | | +---+
| T| | | | T|
| r| | | | r|
|S a| | | |C a|
|e n| | Proxy | |l n|
|r s| | "Higher" Layer | |i s|
|v a| | | |e a|
|e c| | | |n c|
|r t| | | |t t|
| i| | | | i|
| o| | | | o|
| n| | | | n|
+---+ | | +---+
| | +---+
| | | T|
| | | r|
| | |C a|
| | |l n|
| | |i s|
| | |e a|
| | |n c|
| | |t t|
| | | i|
| | | o|
| | | n|
| | +---+
+------------------------------+
Figure 3: Stateful Proxy Model
instance, an element SHOULD NOT reject a request because of
a malformed Date header field. Likewise, a proxy SHOULD
NOT remove a malformed Date header field before forwarding a
Various Authors [Page 85]
Internet Draft SIP January 28, February 4, 2002
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.
2. Max-Forwards check
The Max-Forwards header field (Section 24.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.
3. Optional Loop Detection check
An element MAY check for forwarding loops before forwarding
a request. If the request contains a Via header field value with A
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 3 of Section 16.5
on this message and compare it to the parameter received in
that Via field
value. 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.
In earlier versions of this memo, loop detection was
REQUIRED. This requirement has been relaxed in favor
of the Max-Forwards mechanism.
Various Authors [Page 86]
Internet Draft SIP January 28, 2002
4. Proxy-Require check
Future extensions to this protocol may introduce features
that require special handling by proxies. Endpoints will
Various Authors [Page 86]
Internet Draft SIP February 4, 2002
include a Proxy-Require header field in requests that use
these features, telling the proxy it should not process the
request unless the feature is understood.
If the request contains a Proxy-Require header field
(Section 24.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 24.42) header field listing those
option-tags the element did not understand.
5. Proxy-Authorization check
If an element requires credentials before forwarding a
request, the request MUST be inspected as described in
Section 20.3. That section also defines what the element
must do if the inspection fails.
16.4 Making a Routing Decision
At this point, the proxy must decide where to forward the request.
This can be modeled as computing a set of destinations for the
request. This set will either be predetermined by the contents of the
request or will be obtained from an abstract location service. Each
destination is represented as a URI and an optional IP address, port URI, and transport. This combination is is referred to as a
"next-hop location".
First, the proxy core checks MUST inspect the received request for Route headers. Request-URI of the request. If any Route header fields are present in the request,
Request-URI of the proxy MUST
choose request contains a single next-hop location to place in the destination set.
The value this proxy SHOULD choose to use previously
placed into a strict-routing policy, placing the
URI (including all of its parameters) from the topmost Route Record-Route header field as (see Section 16.5 item 6),
the only next hop URI proxy MUST replace the Request-URI in the destination set, request with no IP
address, port the last
value from the Route header field, and transport set for remove that next hop. value from the
Route header field. The proxy MAY
choose to use a loose-routing policy, selecting a URI, address, port
and transport based on that policy. A loose-routing policy MAY use
any information in or about MUST then proceed as if it received
this modified request.
This will only happen when the element sending the request in determining where
to route
it. Restrictions on the a loose-routing proxy's policy are discussed
in Section 8.1.3.
Once the single next-hop location proxy (which may have been an endpoint) is placed into the destination set,
the set a strict
router. This rewrite on receive is complete, and the proxy MUST proceed necessary to enable
backwards compatibility with those elements. It also allows
elements following this specification to preserve the Request
Processing of
Request-URI through strict-routing proxies (see Section 16.5.
refsec:dialog:uac:generate).
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
Various Authors [Page 87]
Internet Draft SIP January 28, February 4, 2002
The Route mechanism is used
information in those URIs to affect recognize them as values it
provided when they later appear.
If the path a request takes
through SIP elements. A strict-routing policy results in behaviour
much like strict IP source routing. Loose-routing policies will
result in the specified URIs being reached, possibly visiting
additional elements in the process. A UAC will insert Route header
fields (see Section 12), based on information provided by proxies
through Record-Route header fields or by policy obtained through
configuration. (see Step 6 of Section 16.5).
Assuming there were no Route headers in the received request, the
proxy checks the Request-URI of the received request. If the
Request-URI has 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. If the Request-URI contains an 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 an 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. Otherwise, if the Request-URI contains an
maddr parameter, the Request-URI MUST be placed into the destination
set as the only next hop URI, with no IP address, port and transport
set for that next hop, and the proxy MUST proceed to Section
16.5.
A request may arrive with an 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 domain of the Request-URI indicates a domain this element is
not responsible for, it SHOULD set the next hop URI to the Request-
URI, and leave the IP address, port and transport of the next hop
empty.
URI. That next hop MUST be placed into the destination set as the
only next hop, and the element MUST proceed to the task of Request
Processing (Section 16.5. 16.5).
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 destination set for the request has not been predetermined as
described above, this implies that the element is responsible for the
Various Authors [Page 88]
Internet Draft SIP January 28, 2002
domain in the Request-URI, and the element MAY use whatever mechanism
it desires to determine where to send the request. However, if the
request contains a Route header, the proxy MUST only choose a single
destination for 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
Various Authors [Page 88]
Internet Draft SIP February 4, 2002
constructed by the 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
destination set.
If the Request-URI does not provide sufficient information for the
proxy to determine the destination 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 to sip:John.Smith@company.com may be ambiguous at a proxy
whose location service has multiple John Smiths listed. See Section
25.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 destination 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 destinations are located through these services, their
next hops are added to the destination set. set (although, as pointed out
above, the destination set MUST NOT ever contain more than one
destination if the request contains a Route header). Next-hop
locations may only be placed in the destination set once. If a next-hop next-
hop location is already present in the set (based on the definition
of equality for the URI type and equality of the optional parameters), type), it MUST NOT be added again.
If the recieved received request contained no Route headers, header fields, a proxy MAY
continue to add destinations to the set after beginning Request
Processing. It MAY use any information obtained during that
processing to determine new locations. For instance, a proxy may
choose to incorporate contacts obtained in a redirect response (3xx
class) (3xx)
into the destination set. If a proxy uses a dynamic source of
information while building the destination 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 destination set as they become available. As above, any given URI
MUST NOT be added to the set more than once.
Various Authors [Page 89]
Internet Draft SIP January 28, 2002
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.
An example
For example, a trivial location service is achieved by configuring an
element with a default outbound destination. All requests are
forwarded to this location. The Request-URI of the request is placed
in "no-op", where the
Various Authors [Page 89]
Internet Draft SIP February 4, 2002
destination set with the optional next-hop IP address, port
and transport parameters set URI is equal to the default outbound destination. incoming request URI. The
destination set request is complete, containing only this URI, and the
element proceeds
sent to a specific next hop proxy for further processing. During
request processing of Section 16.5, Item 5, the task identity of Request Processing. that next
hop, expressed as a SIP URI, is inserted as the top most Route header
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 destination 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.5 Request Processing
As soon as the destination 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 destinations serially, allowing each
client transaction to complete before starting the next. It MAY start
client transactions with every destination in parallel. It also MAY
arbitrarily divide the set into groups, processing the groups
serially and processing the destinations in each group in parallel.
A common ordering mechanism is to use the qvalue parameter of
destinations obtained from Contact header fields (see Section 24.10).
Destinations are processed from highest qvalue to lowest.
Destinations with equal qvalues may be processed in parallel.
A stateful proxy must have a mechanism to maintain the destination
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 destination, the proxy forwards the request following these
steps:
1. Make a copy of the received request
2. Update the Request-URI
Various Authors [Page 90]
Internet Draft SIP January 28, 2002
3. Add a Via header field value
4. Update the Max-Forwards header field
5. Update the Route header field if present
6. Optionally add a Record-route header field value
Various Authors [Page 90]
Internet Draft SIP February 4, 2002
7. Optionally add additional headers header fields
8. send the new request
9. 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. Only those fields detailed in the
processing described below may 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).
An actual implementation need not perform a copy; the
primary requirement is that the processing of 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 destination. 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 destination set without being modified. For that
destination, the replacement above is effectively a no-op.
3. Via
The proxy MUST insert a Via header field into the copy
before the existing Via header fields. The construction of
this header field follows the same guidelines of Section
8.1.1.7. This implies that the proxy will compute its own
branch
Various Authors [Page 91]
Internet Draft SIP January 28, 2002 parameter, which will be globally unique for that
branch, and contain the requisite magic cookie.
Proxies choosing to detect loops have an additional
Various Authors [Page 91]
Internet Draft SIP February 4, 2002
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 Proxy-Require Route, Proxy-
Require and Proxy-Authorization headers). 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 (Section 16.3 item 2) 3) A common way to create
this value is to compute a cryptographic hash of the To,
From, Call-ID header fields, the Request-URI of the request
received (before translation) and the sequence number from
the CSeq header field, in addition to any Proxy-Require and Proxy-
Authorization
Proxy-Authorization header fields that may be present. The
algorithm used to compute the hash is implementation-dependent, implementation-
dependent, but MD5 [21], [31], 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 Request-URI and any header values 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 Section
17.2.3 and 9.2).
Various Authors [Page 92]
Internet Draft SIP January 28, 2002
4. Max-Forwards
If the copy does not contain a Max-Forwards header field,
the proxy must MUST add one with a field value of which SHOULD be
Various Authors [Page 92]
Internet Draft SIP February 4, 2002
70.
Some existing UAs will not provide a Max-Forwards
header field in a request.
If the copy contains a Max-Forwards header field, the proxy
must decrement its value by one (1).
5. Route
If the copy contains
A proxy MAY have a Route header field, the proxy's
routing local policy will determine whether that field should be
modified. 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 strict-routing policy set of URIs (each of which contains the lr parameter).
This set MUST remove be pushed into the first (topmost) Route header field value. (The strict-
routing policy would have already placed that value into
the Request-URI ahead
of this copy.) A proxy with a loose-routing
policy MAY remove any existing values, if present. If the topmost value. Restrictions on Route header
field is empty, it MUST be added, containing that list of
URIs.
If the proxy has a
loose-routing proxy's local policy with respect 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 8 below, and instead just send the
request to the address, port and transport for that
specific proxy. If the request has Route headers, this
alternative MUST NOT be used unless it 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.
In absence of a policy for forwarding a request through
specific next hops, the proxy MUST inspect the topmost
Route header are described field value. If that value indicates this
proxy, the proxy MUST remove the value from the copy
(removing the Route header field if that was the only
value).
If a Route header field remains after the previous step,
the proxy MUST inspect the URI in Section 8.1.3. its first value. If that
URI does not contain a lr parameter, the proxy MUST modify
the request as follows:
- The proxy MUST place the Request-URI into the Route
Various Authors [Page 93]
Internet Draft SIP February 4, 2002
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).
6. Record-Route
If this proxy wishes to remain on the path of future
requests in a dialog created by this request, it MUST
insert a Record-Route header value field into the copy before any
existing Record-Route header values, field, even if a Route header
field is already present.
Requests establishing a dialog may contain preloaded
Route header fields.
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 choses 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
Various Authors [Page 93]
Internet Draft SIP January 28, 2002
failed reconstitutes the dialog.
A proxy MAY insert a Record-Route header value field 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.
Various Authors [Page 94]
Internet Draft SIP February 4, 2002
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 URI. This URI MUST contain an lr parameter (see
Section 23.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 to know what the capabilities of
that element are, so it must restrict itself to the
mandatory elements of a SIP implementation: SIP URIs
and either the TCP or UDP transports.
The URI placed in the Record-Route header value field MUST
resolve to this element when the server location procedures
of [8] [2] are applied to it. This ensures subsequent requests
are routed back to this element.
The
If the URI placed in the Record-Route header value SHOULD field needs to
be
such that if a subsequent request is received with this URI be rewritten when it passes back through in a response,
the Request-URI, the proxy's normal request processing
will cause it to URI MUST be forwarded 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 the previous
elements, including the originating client, traversed by
the original request. This improves robustness, ensuring
that the Request-URI contains enough information to forward
subsequent requests to Section 16.6 recommends a reasonable destination even in mechanism to make the
absence of Route headers.
The
URI placed in the sufficiently distinct.
The proxy MAY include Record-Route header value MUST vary
with field parameters
in the Request-URI value it provides. These will be returned in some
responses to the received request. A request (200 (OK) responses to INVITE for
example) and may
legitimately pass through this proxy more than once on be useful for pushing state into the
way to its final destination (this is called a spiraling
Various Authors [Page 94]
Internet Draft SIP January 28, 2002
request). The Request-URI will be different each time the
request passes through. If this proxy places the same URI
in the Record-Route header field each time, subsequent
requests will be rejected as looped requests. It is
insufficient to simply copy the Request-URI from each
request into the Record-Route header. Some modification,
such as adding an maddr parameter, is necessary.
URIs satisfying the above paragraphs can be constructed in
many ways. One way is to use a URI that is nearly the same
as the Contact header in the initial request (if present,
else the From field), but with the maddr and port set to
resolve to the proxy, and with a transaction identifier
added to the user part of the request-URI (in order to meet
the requirement that the URI in the Record-Route be
different for each distinct Request-URI). A call stateful
proxy could use a URI of the form sip:proxy.example.com and
use information from the stored call state to meet the
requirements.
The proxy MAY include Record-Route header parameters in the
value it provides. These will be returned in some responses
to the request (200 (OK) responses to INVITE for example)
and may be useful for pushing state into the message.
The Record-Route process is designed to work for any SIP
request that initiates a dialog. The only such request in
this specification is INVITE. Extensions to the protocol
MAY define others, and the mechanisms described here will
apply.
If a proxy needs
message.
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 value field 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 value header field is
Various Authors [Page 95]
Internet Draft SIP February 4, 2002
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
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 value field outside the
Various Authors [Page 95]
Internet Draft SIP January 28, 2002
dialog in which it was provided. See Section 12 for more
information on an endpoint's use of Record-Route header
values.
fields.
Generally, the choice about whether to record-route or not
is a tradeoff of features vs. performance. Faster request
processing and higher scalability is achieved when proxies
do not record route. However, provision of certain services
may require a proxy to observe all messages in a dialog. It
is RECOMMENDED that proxies do not automatically record
route. They should do so only if specifically required.
The Record-Route process is designed to work for any SIP
request that initiates a dialog. The only such request in
this specification is INVITE. Extensions to the protocol
MAY define others, and the mechanisms described here will
apply.
7. Adding Additional Headers Header Fields
The proxy MAY add any other appropriate headers header fields to
the copy at this point.
8. Forward Request
A stateful proxy creates a new client transaction for this
request as described in Section 17.1. If The proxy MAY have a
local policy to send the next-hop
location used in building this request contains to a specific IP address,
port, and transport, independent of the
optional addressing parameters, values of the transaction Route
and Request-URI. Such a policy MUST NOT be used if the
proxy is
instructed not certain that the IP address, port, and
transport correspond to send a server that is a loose router.
However, this mechanism for sending the request based on those parameters.
Otherwise, the proxy uses through a
specific next hop is NOT RECOMMENDED; instead a Route
header field should be used for that purpose as described
above.
In the procedures absence of Section [8] to
compute such an ordered set of addresses from overriding mechanism, the Request-URI,
and proxy
Various Authors [Page 96]
Internet Draft SIP February 4, 2002
applies the procedures listed in [2] as described there, attempts follows to contact the first one
by instructing the client transaction
determine where to send the request
there. request. If the client transaction reports failure to send proxy has
reformatted the request or to send to a timeout from its state machine, strict-routing element
as described in Section 5, the
stateful proxy continues MUST apply those
proceedures to the next address that ordered
set. Each attempt is Request-URI of the request. Otherwise,
the proxy MUST apply the proceedures to the first value in
the Route header field, if present, else the Request-URI.
The proceedures will produce an ordered set of addresses.
As described in [2], the proxy MUST attempt to contact the
first address by instructing the client transaction to send
the request there. If the client transaction reports
failure to send the request or a timeout from its state
machine, the stateful proxy continues to the next address
in that ordered set. Each attempt is a new client
transaction, and therefore represents a new branch, so that
the processing described above for each branch would need
to be repeated. This results in a requirement to use a
different branch ID parameter for each attempt. If the
ordered set is exhausted, the request cannot be forwarded
to this element in the destination set. The proxy does not
need to place anything in the response context, but
otherwise acts as if this element of the destination set
returned a 408 (Request Timeout) final response.
9. Set timer C
In order to handle the case where an INVITE request never
generates a final response, a transaction timeout value is
used. This is accomplished through a timer, called timer C,
which MUST be set for each client transaction when an
INVITE
Various Authors [Page 96]
Internet Draft SIP January 28, 2002 request is proxied. The timer MUST be larger than 3
minutes. Section 16.6 bullet 2 discusses how this timer is
updated with provisional responses, and Section 16.7
discusses processing when it fires.
16.6 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 class responses to INVITE requests are
Various Authors [Page 97]
Internet Draft SIP February 4, 2002
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
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.
1. Aggregate authorization header fields if necessary;
2. forward the response;
3. generate any necessary CANCEL requests.
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.
Various Authors [Page 97]
Internet Draft SIP January 28, 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.5. 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
Various Authors [Page 98]
Internet Draft SIP February 4, 2002
The proxy removes the topmost Via header field value from the
response.
If no Via field values header fields 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.4 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
class
response by adding them to the destination set, it MUST
remove them from the response before adding the response to
the response context. If the proxy recurses on all of the
contacts in a 3xx class response, the proxy SHOULD NOT add the
resulting contactless response to the
Various Authors [Page 98]
Internet Draft SIP January 28, 2002 response context.
Removing the contact before adding the response to the
response contact prevents the next element upstream
from retrying a location this proxy has already
attempted.
3xx class responses may contain a mixture of SIP and non-
SIP non-SIP
URIs. A proxy may choose to recurse on the SIP 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 (that is,
the proxy changed the scheme from SIP to something else
when it proxied a request), the proxy SHOULD add a new URI
to the destination set. This URI SHOULD be a SIP URI
version of the non-SIP URI that was just tried. In the case
Various Authors [Page 99]
Internet Draft SIP February 4, 2002
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.
As with a 3xx response, if a proxy "recurses" on the 416 by
trying a SIP 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 pending
transactions as described in Section 10.
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
Various Authors [Page 99]
Internet Draft SIP January 28, 2002
branch, in which case the proxy would 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 class 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
Various Authors [Page 100]
Internet Draft SIP February 4, 2002
Context".
Any response chosen for immediate forwarding MUST be
processed as described in steps "Aggregate authorization
headers" Authorization
Header Fields" 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 class response or
one or more 2xx-class 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 one of the responses from
Various Authors [Page 100]
Internet Draft SIP January 28, 2002
the lowest response class stored in the response context.
The proxy MAY select any response within that lowest class.
The proxy SHOULD give preference to responses that provide
information affecting resubmission of this request, such as
401, 407, 415, 420, and 484.
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.
The forwarded response MUST be processed as described in
steps "Aggregate authorization headers" Header Fields" through "Record-
Route".
"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.
Various Authors [Page 101]
Internet Draft SIP February 4, 2002
1xx and 2xx class responses may be involved in the establishment
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 class 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 class response.
Since a proxy may not insert a tag into the To header field
of a 1xx class 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 initator 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 class responses are delivered hop-hop. When issuing a 3-6xx class
response, the element is effectivly 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
class response
to a request that did not contain a To tag.
Various Authors [Page 101]
Internet Draft SIP January 28, 2002
A proxy MUST NOT modify the To tag in any forwarded
response to a request that contains a To tag.
While it makes no difference to the upstream elements
if the proxy replaced the To tag in a forwarded 3-6xx
class
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 class responses.
7. Aggregate authorization headers Authorization Header Fields
If the selected response is a 401 (Unauthorized) or 407
(Proxy Authentication Required), the proxy MUST collect any
WWW-Authenticate and Proxy-Authenticate header fields from
Various Authors [Page 102]
Internet Draft SIP February 4, 2002
all other 401 (Unauthorized) and 407 (Proxy Authentication
Required) responses received so far in this response
context and add them to this response before forwarding.
Each WWW-Authenticate and Proxy-Authenticate header field
added to the response MUST preserve that header field
value. The resulting 401 (Unauthorized) or 407 (Proxy
Authenication Required) response may have several WWW-
Authenticate AND Proxy-Authenticate headers. header fields.
This is necessary because any or all of the destinations
the request was forwarded to may have requested
credentials. The client must 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 22.
8. Record-Route
If the selected response contains a Record-Route header
field value originally provided by this proxy, the proxy
MAY chose 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.
Various Authors [Page 102]
Internet Draft SIP January 28, 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 6 of Section 16.5) 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.
The URI placed in the Record-Route header value SHOULD be
such that if a subsequent request is received with this URI
in the Request-URI, the proxy's normal request processing
will cause it to be forwarded to the same next-hop element
(as opposed to some previous element) as the originally
forwarded request.
When a proxy does decide to modify the Record-Route header
field in the response, one of the operations it must
perform is to locate the Record-Route that it had inserted.
If the request spiraled, and the proxy inserted a Record-Route Record-
Route in each iteration of the spiral, locating the correct
header field in the response (which must be the proper
iteration in the reverse direction) is tricky. The rules
above dictate recommend that a proxy wishing to rewrite Record-
Route header field values insert a different URI sufficiently distinct URIs
into the Record-Route for
each distinct Request-URI received. The two issues can header field so that the right one
may be
solved jointly. selected for rewriting. A RECOMMENDED mechanism to
achieve this is for the proxy to append a piece of data to the user portion of the URI.
This piece of data is a hash of the transaction key (those
peices of data used to match a request against existing
transactions as discussed in section 17.2.3) for the
incoming request, concatenated with a unique identifier
Various Authors [Page 103]
Internet Draft SIP February 4, 2002
for the proxy instance. Since the transaction key either
contains Request-URI or depends on it (when the key is
encoded in instance to to the branch parameter user portion of the topmost Via header),
this key will be unique for each distinct Request-URI. 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 with the parameter) will correctly
extract the next Record-Route header field inserted by that
proxy.
9. Forward response
After performing the processing described in steps
"Aggregate authorization headers" Authorization Header Fields" through "Record-Route",
Various Authors [Page 103]
Internet Draft SIP January 28, 2002 "Record-
Route", the proxy may perform any feature specific
manipulations on the selected response. Unless otherwise
specified, the proxy MUST NOT remove the message body or
any header values fields other than the Via header value field discussed
in Section 3. In particular, the proxy MUST NOT remove any
"received" parameter it may have added to the next Via
header value field 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 may indicate failure to send the
response or signal a timeout in its state machine. These
errors should 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
OPEN ISSUE #7: If CANCEL is restricted to INVITE only, this
behavior must restrict itself to INVITE requests.
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 and has not had an
Various Authors [Page 104]
Internet Draft SIP February 4, 2002
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
Various Authors [Page 104]
Internet Draft SIP January 28, 2002
CANCEL requests.
16.7 Processing Timer C
If timer C should fire, the proxy MUST either reset the timer with
any value it chooses, or generate a CANCEL for that particular
request.
16.8 Handling Transport Errors
If the transport layer notifies a proxy of an error when it tries to
forward a request (see Section 19.4), the proxy MUST behave as if the
forwarded request received a 400 (Bad Request) 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.9 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 INVITEs 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.
Various Authors [Page 105]
Internet Draft SIP February 4, 2002
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 10.
Various Authors [Page 105]
Internet Draft SIP January 28, 2002
If a response context is not found, the element does not have any
knowledge of the request to apply the CANCEL to. It MUST forward the
CANCEL request (it may have statelessly forwarded the associated
request previously).
16.10 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 19). As a
result, stateless proxies do not retransmit messages on their own.
They do, however, forward all retransmission 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 make a routing decision as described in
Section 16.4 with the following exception:
o A stateless proxy MUST choose one and only one destination
from the destination 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 process the request before forwarding as
Various Authors [Page 106]
Internet Draft SIP February 4, 2002
described in Section 16.5 with the following exceptions:
o The requirement for unique branch IDs across 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.5
bullet 3. 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
Various Authors [Page 106]
Internet Draft SIP January 28, 2002
for a stateless proxy, the branch parameter MUST be computed
as a combinatoric function of message parameters which are
invariant on retransmission.
o 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 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 To header, header field,
the From header , field, the Call-ID header, 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 The request is sent directly to the transport layer instead of
through a client transaction. If the next-hop destination
parameters don't provide an explicit destination, the element
applies the procedures of [8] [2] to the Request-URI to determine
where to send the request.
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.
Various Authors [Page 107]
Internet Draft SIP February 4, 2002
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.
Response processing as described in Section 16.6 does not apply to a
proxy behaving statelessly. When a response arrives at a stateless
proxy, the proxy inspects the sent-by value in the first (topmost)
Via header value. field. If that address matches the proxy (it equals a
value this proxy has inserted into previous requests) the proxy MUST
remove that value from the response and forward the result to the
Various Authors [Page 107]
Internet Draft SIP January 28, 2002
location indicated in the next Via header value. field. Unless specified
otherwise, the proxy MUST NOT remove any other header values fields or the
message body. If the address does not match the proxy, the message
MUST be silently discarded.
16.11 Record-Route Example
This example demonstrates one way Record-Route header values can be
constructed Summary of Proxy Route Processing
In the absence of local policy to satisfy the requirements described in section 16.5
item 6 and section 16.6 item 8.
Consider contrary, the processing a
proxy at server12.atlanta.com listening performs on port 5061 which
receives a request containing a route header can be
summarized in the following request (many headers are omitted for
brevity):
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP callerspc.univ.edu
Contact: sip:caller@callerspc.univ.edu steps.
o 1 The proxy forwards this request to will inspect the Request-URI. If it indicates a UAS at
sip:j_user@div11.example.com, and record-routes:
INVITE sip:j_user@div11.example.com SIP/2.0
Via: SIP/2.0/UDP server12.atlanta.com:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route: <sip:caller.8jjs@callerspc.univ.edu:5061;
maddr=server12.atlanta.com>
Contact: sip:caller@callerspc.univ.edu
The 200 (OK) response received
resource owned by this proxy, the proxy will look like, in part:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server12.atlanta.com:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route: <sip:caller.8jjs@callerspc.univ.edu:5061;
maddr=server12.atlanta.com>
Contact: sip:j_user@host32.div11.example.com replace it with
the results of running a location service. Otherwise, the
proxy will not change the Request-URI.
o 2 The proxy modifies its Record-Route header in will inspect the response, resulting
Various Authors [Page 108]
Internet Draft SIP January 28, 2002 URI in the new response forwarded upstream:
SIP/2.0 200 OK
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route: <sip:user@example.com:5061;maddr=server12.atlanta.com>
Contact: sip:j_user@host32.div11.example.com
The route set computed by topmost Route header
field value. If it indicates this proxy, the UAS is:
sip:caller.8jjs@callerspc.univ.edu:5061;maddr=server12.atlanta.com
sip:caller@callerspc.univ.edu
and proxy removes it
from the Route header field (this route set computed by node has been
reached).
o 3 The proxy will forward the UAC is:
sip:j_user@example.com:5061;maddr=server12.atlanta.com
sip:j_user@host32.div11.example.com
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 to the case of a transaction where resource indicated
by the
request was an INVITE (known as an INVITE transaction), URI in the
transaction also includes topmost Route header field value or in the ACK only
Request-URI if the final response was not
a 2xx response. If the response was a 2xx, the ACK no Route header field is not considered
part of the transaction. present. The reason for this separation is rooted in proxy
determines the importance
of delivering all 200 (OK) responses to an INVITE address, port and transport to use when
forwarding the
UAC. To deliver them all request by applying the proceedures in [2] to
that URI.
If no strict-routing elements are encountered on the UAC, path of the UAS alone takes
responsibility for retransmitting them, and
request, the UAC alone
takes responsibility for acknowledging them with ACK. Since
this ACK is retransmitted only by Request-URI will always indicate 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 target of the server side, as a server
request.
16.11.1 Examples
16.11.1.1 Basic SIP Trapezoid
Various Authors [Page 109] 108]
Internet Draft SIP January 28, February 4, 2002
transaction. The client transaction sends the request, and
This scenario is the server
transaction sends basic sip trapeziod, U1 -> P1 -> P2 -> U2, with
both proxies record-routing. Here is the response. The client flow.
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 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 of Section 4. In this example, the UAC
executes the client transaction, and its outbound proxy executes the
server transaction. The outbound proxy sends it there. It also executes adds a client
transaction, which sends the request to 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 server transaction in location
service and rewrites the
inbound proxy. That proxy also executes a client transaction, which
in turn, Request-URI. There are no Route headers, so
it sends the request to a server transaction in the UAS. This
is shown pictorially 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 result of the stateless proxy, location lookup. It also adds a
Record-Route header field value:
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 the UA or stateful proxy on the other 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
Various Authors [Page 110] 109]
Internet Draft SIP January 28, February 4, 2002
side. As far as SIP transactions are concerned, stateless proxies are
effectively transparent. The purpose of the client transaction
(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
This is forwarded by P2 to
receive a request from 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 for the BYE:
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
As any other element (including proxies) would do, it sends this
request to the client location obtained by looking up the topmost Route
header field value in DNS. This goes to P1. P1 notices that it is embedded
not responsible for the resource indicated in (call
this element the "Transaction User" or TU; Request-URI so it can be a UA or a
stateful proxy),
doesn't change it. It does see that it is the first value in the
Route header field, so it removes that value, and reliably deliver forwards the
request to that server
transaction. The client transaction is P2:
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p2.domain.com;lr>
P2 also notices it is not responsible for receiving
responses, and delivering them to the TU, filtering out any
retransmissions or disallowed responses (such as a response to ACK).
In resource indicated by
the case of an INVITE transaction, that includes generation of the
ACK request for any final response excepting a 2xx response.
Similarly, the purpose of the server transaction Request-URI (it 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 responsible for transmission over the
network. In the case of an INVITE transaction, domain.com, not
u2.domain.com), so it absorbs doesn't change it. It does see itself in the ACK
request for any final response excepting a 2xx response.
The 2xx response,
first Route header field value, so it removes it and forwards the ACK for it, have special treatment. This
response is retransmitted only by
following to u2.domain.com based on a UAS, and its ACK generated only
by DNS lookup against the UAC. This end-to-end treatment is needed so that
Request-URI:
BYE sip:callee@u2.domain.com SIP/2.0
16.11.1.2 Traversing a caller
knows the entire set of users that have accepted the call. Because of strict-routing proxy
Various Authors [Page 110]
Internet Draft SIP February 4, 2002
In this special handling, retransmissions of the 2xx response are
handled by the UA core, not the transaction layer. Similarly,
generation scanario, a dialog is established across three proxies, each
of which adds Record-Route header field values. The second proxy
implements the ACK for the 2xx is handled by strict-routing proceedures specified in RFC2543 and
the UA core. Each
proxy along bis drafts up to bis-05.
U1->P1->P2->P3->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:p3.domain.com;lr>
Record-Route: <sip:p2.middle.com>
Record-Route: <sip:p1.example.com;lr>
Which U2 responds to with a 200 OK. Later, U2 sends the path merely forwards each 2xx response following BYE
to INVITE, and
its corresponding ACK.
A reliable provisional response, and P3 based on the PRACK first Route header field value.
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p3.domain.com;lr>
Route: <sip:p2.middle.com>
Route: <sip:p1.example.com;lr>
P3 is not responsible for it, also have
special treatment. Reliable provisional responses are also only
retransmitted by the UAS core, and the PRACK generated by resource indicated in the UAC
core. Unlike ACK, however, PRACK is a normal non-INVITE transaction,
which means that Request-URI
so it will generate its own final response. The reason
for this seemingly inexplicable difference between PRACK and ACK is leave it alone. It notices that reliability of provisional responses was added on later as an
extra feature, and therefore needed to be done within it is the confines of
SIP extensibility. SIP extensibility only allowed element in the additions of
new methods which behaved like any other non-INVITE method.
17.1 Client Transaction
The client transaction provides its functionality through
first Route header field value so it removes it. It then prepares to
send the
maintenance request based on the now first Route header field value of a state machine.
The TU communicates with
sip:p2.middle.com, but it notices that this URI does not contain the client transaction through a simple
interface. When
lr parameter, so before sending, it reformats the TU wishes request to initiate a new transaction, it
creates be:
BYE sip:p2.middle.com SIP/2.0
Route: <sip:p1.example.com;lr>
Route: <sip:caller@u1.example.com>
P2 is a client transaction, and passes strict router, so it forwards the SIP request following to send, P1:
Various Authors [Page 111]
Internet Draft SIP January 28, February 4, 2002
and an IP address, port, and transport to send
BYE sip:p1.example.com;lr SIP/2.0
Route: <sip:caller@u1.example.com>
P1 sees the request-URI is a value it to. 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 placed into a Record-Route
header field, so before further processing, it rewrites the request passed by the TU. One handles client
transactions for INVITE request. This type of machine is referred
to
as an INVITE client transaction. Another type handles client
transactions be
BYE sip:caller@u1.example.com SIP/2.0
Since P1 is not responsible for all requests except INVITE u1.example.com and ACK. This is referred
to as a non-INVITE client transaction. There there is no client transaction
for ACK. If Route
header field, P1 will forward the TU wishes to send an ACK, it passes one directly request to u1.example.com based on
the transport layer for transmission.
The INVITE transaction is different from those of other methods
because of its extended duration. Normally, human input is required Request-URI:
BYE sip:caller@u1.example.com SIP/2.0
16.11.1.3 Rewriting Record-Route header field values
In this scenario, U1 and U2 are in order to respond to an INVITE. The long delays expected for
sending different private namespaces and
they enter a response argue for dialog through a three way handshake. Requests of other
methods, on proxy P1 which acts as a gateway
between the other hand, are expected namespaces.
U1->P1->U2
U1 receives:
INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>
P1 its location service and sends the following to completely rapidly. In
fact, because of U2:
INVITE sip:callee@rightprivatespace.com SIP/2.0
Contact: <sip:caller@u1.leftprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>
Various Authors [Page 112]
Internet Draft SIP February 4, 2002
U2 sends this 200 OK back to the gateway:
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.rightprivatespace.com;lr>
P1 rewrites its reliance on just a two way handshake, TUs SHOULD
respond immediately Record-Route header parameter to non-INVITE requests. Protocol extensions which
require longer durations for generation of a response (such as provide a new
method value that does require human interaction) SHOULD instead use two
transactions - one to send the request,
U1 will find useful, and another in sends the reverse
direction following to convey the result of U1:
SIP/2.0 200 OK
Contact: <sip:callee@u2.rightprivatespace.com>
Record-Route: <sip:gateway.leftprivatespace.com;lr>
Later, U1 sends the request.
17.1.1 INVITE Client Transaction
17.1.1.1 Overview following BYE 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 INVITE Transaction
The INVITE independent message exchanges. Specifically, a
SIP transaction consists of a three-way handshake. The client
transaction sends an INVITE, the server transaction sends responses, single request, and any responses to
that request (which include zero or more provisional responses and
one or more final responses). In the client case of a transaction sends where the
request was an ACK. For unreliable transports
(such INVITE (known as UDP), an INVITE transaction), the client
transaction will retransmit requests at an
interval that starts at T1 seconds and doubles after every
retransmission. T1 is an estimate of also includes the RTT, and it defaults to 500
ms. Nearly all of ACK only if the transaction timers described here scale with
T1, and changing T1 is how their values are adjusted. The request is final response was not retransmitted over reliable transports. After receiving
a 1xx
response, any retransmissions cease altogether, and 2xx response. If the client waits
for further responses. The server transaction can send additional
1xx responses, which are response was a 2xx, the ACK is not transmitted reliably by considered
part of the server transaction. If the provisional response needs to be sent reliably,
The reason for this separation is handled by the TU. Eventually, rooted in the server transaction
decides to send a final response. For unreliable transports, that
response is retransmitted periodically, and for reliable transports,
its sent once. For each final response that is received at the
client transaction, the client transaction sends an ACK, the purpose importance
of which is delivering all 200 (OK) responses to an INVITE to quench retransmissions of the response.
Various Authors [Page 112] 113]
Internet Draft SIP January 28, February 4, 2002
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
UAC. To deliver them all to the TU
initiates a new client transaction with an INVITE request. The client
transaction MUST pass UAC, the request to UAS alone takes
responsibility for retransmitting them (see Section
13.3.1.4) , and the transport layer UAC alone takes responsibility for
transmission
acknowledging them with ACK (see Section 19). If an unreliable transport 13.2.2.4). Since
this ACK is being
used, retransmitted only by the client transaction SHOULD start timer A with UAC, it is
effectively considered its own transaction.
Transactions have a value of T1, client side and SHOULD NOT start timer A when a reliable transport is being used
(Timer A controls request retransmissions). For any transport, the server side. The client transaction MUST start timer B with side is
known as a value of 64*T1 seconds
(Timer B controls transaction timeouts).
When timer A fires, client transaction, and the server side, as a server
transaction. The client transaction SHOULD retransmit the
request by passing it to sends the transport layer, request, and SHOULD reset the
timer with a value of 2*T1. server
transaction sends the response. The formal definition client and server transactions
are logical functions that are embedded in any number of retransmit elements.
Specifically, they exist within user agents and stateful proxy
servers. Consider the context example of Section 4. In this example, the transaction layer, is to take the message
previously sent to UAC
executes the transport layer, client transaction, and pass it to its outbound proxy executes the transport
layer once more.
When timer A fires 2*T1 seconds later,
server transaction. The outbound proxy also executes a client
transaction, which sends the request SHOULD be
retransmitted again (assuming to a server transaction in the
inbound proxy. That proxy also executes a client transaction is still transaction, which
in this
state). This process SHOULD continue, so that turn, sends the request is
retransmitted with intervals that double after each transmission.
These retransmissions SHOULD only be done while the client to a server transaction is in the "calling" state.
The default value for T1 is 500 ms. T1 UAS. This
is an estimate of the RTT
between the shown pictorially in Figure 4.
A stateless proxy does not contain a client and or server transactions. transaction.
The optional RTT
estimation procedure of Section 17.3 MAY be followed, in which case transaction exists between the resulting estimate MAY be used instead UA or stateful proxy on one side
of 500 ms. If no RTT
estimation is used, the stateless proxy, and the UA or stateful proxy on the other values MAY be used in private networks
where it
side. As far as SIP transactions are concerned, stateless proxies are
effectively transparent. The purpose of the client transaction is known that RTT has to
receive a different value. On request from the public
Internet, T1 MAY be chosen larger, but SHOULD NOT be smaller.
If element the client transaction is still embedded in (call
this element the "calling"state when timer B
fires, the client transaction SHOULD inform "Transaction User" or TU; it can be a UA or a
stateful proxy), and reliably deliver the TU request to that a timeout has
occurred. server
transaction. The client transaction MUST NOT generate an ACK. The value
of 64*T1 is equal to the amount of time required also responsible for receiving
responses, and delivering them to send seven
requests in the case of an unreliable transport.
If the client transaction receives TU, filtering out any
retransmissions or disallowed responses (such as a provisional response while in
the "calling" state, it transitions to the "proceeding" state. ACK).
In the
"proceeding" state, the client transaction SHOULD NOT retransmit case of an INVITE transaction, that includes generation of the
ACK request for any longer. Furthermore, the provisional final response MUST be
passed to the TU. Any further provisional responses MUST be passed up
to the TU while in the "proceeding" state. Passing of all provisional
Various Authors [Page 113]
Internet Draft SIP January 28, 2002
responses is necessary since the TU will handle reliability of these
messages, and therefore even retransmissions of excepting a provisional
response must be passed upwards.
When in either 2xx response.
Similarly, the "calling" or "proceeding" states, reception purpose of a
response with status code from 300-699 MUST cause the client
transaction to transition to "completed". The client server transaction MUST
pass the received response up is to receive
requests from the TU, transport layer, and deliver them to the client TU. The
server transaction
MUST generate an ACK request, even if the transport is reliable
(guidelines for constructing filters any request retransmissions from the ACK
network. The server transaction accepts responses from the response are given in
Section 17.1.1.3) TU, and then pass the ACK
delivers them to the transport layer for
transmission. The ACK MUST be sent to transmission over the same address, port and
transport that
network. In the original request was sent to. The client
transaction SHOULD start timer D when case of an INVITE transaction, it enters absorbs the "completed"
state, with a value of at least 32 seconds ACK
request for unreliable transports,
and any final response excepting a value of zero seconds 2xx response.
The 2xx response, and the ACK for reliable transports. Timer D it, have special treatment. This
response is retransmitted only by a
reflection of the amount of time that the server transaction can
remain in UAS, and its ACK generated only
by the "completed" state when unreliable transports are used. UAC. This end-to-end treatment is equal to Timer H in the INVITE server transaction, whose
default is 64*T1. However, the client transaction does not know the
value of T1 in use by the server transaction, needed 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 SHOULD cause the ACK to be re-passed to the
transport layer for retransmission, but the newly received response
MUST NOT be passed up to a caller
knows the TU. A retransmission entire set of users that have accepted the response is
defined as any response which would match the same client
transaction, based on the rules call. Because of Section 17.1.3.
If timer D fires while the client transaction is in the "completed"
state, the client transaction MUST move to the terminated state, and
it MUST inform the TU of the timeout.
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 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
Various Authors [Page 114]
Internet Draft SIP January 28, February 4, 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: +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | 300-699 V
| |C||------->||S| |C||------->||S| |C||------->||S| | ACK sent +-----------+Transport Err.
| transitions |l|| ||e| |l|| ||e| |l|| ||e| | +---------| |Inform TU
| labeled with |i|| ||r| |i|| ||r| |i|| ||r| |
| |e|| ||v| |e|| ||v| |e|| ||v| | Completed |-------------->| the event
| +-------->| |n|| ||e| |n|| ||e| |n|| ||e| |
| over the action |t|| ||r| |t|| ||r| |t|| ||r| | +-----------+
| to take | ^ || || | | || || | | || || | Timer D fires |
+--------------+
| - |T|| ||T| |T|| ||T| |T|| ||T| |
| |r|| ||r| |r|| ||r| |r|| ||r| |
V
|
+-----------+ |a|| ||a| |a|| ||a| |a|| ||a| |
| |n|| ||n| |n|| ||n| |n|| ||n| |
| |s||Response||s| |s||Response||s| |s||Response||s| | Terminated|<--------------+
| +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ |
+-----------+
Figure 5: INVITE client transaction
Various Authors [Page 115]
Internet Draft SIP January 28, 2002
in a
+---------+ +---------+ +---------+ +---------+
UAC is different. Thus, each Outbound Inbound UAS
Proxy Proxy
Figure 4: Transaction relationships
this special handling, retransmissions of the 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 are
handled by the transport, if UA core, not the transport layer finds
no matching client transaction (using the rules layer. Similarly,
generation of Section 17.1.3),
the response is passed directly to the core. Since ACK for the matching
client transaction 2xx is destroyed handled by the first 2xx, subsequent 2xx will
find no match and therefore be passed to the UA core.
17.1.1.3 Construction of the ACK Request
The ACK request constructed by Each
proxy along the client transaction MUST contain
values for the Call-ID, From, and Request-URI which are equal path merely forwards each 2xx response to INVITE, and
its corresponding ACK.
A reliable provisional response, and the
values of those headers in PRACK for it, also have
special treatment. Reliable provisional responses are also only
retransmitted by the request passed to UAS core, and the transport PRACK generated by the
client transaction (call this the "original request"). UAC
core. Unlike ACK, however, PRACK is a normal non-INVITE transaction,
which means that it will generate its own final response. The To field
in the reason
for this seemingly inexplicable difference between PRACK and ACK MUST equal the To field in the response being
acknowledged, is
that reliability of provisional responses was added on later as an
extra feature, and will therefore usually differ from the To field in
the original request by needed to be done within the addition confines of
SIP extensibility. SIP extensibility only allowed the tag parameter. additions of
new methods which behaved like any other non-INVITE method.
Various Authors [Page 115]
Internet Draft SIP February 4, 2002
17.1 Client Transaction
The ACK
MUST contain a single Via header, and this MUST be equal to client transaction provides its functionality through the top
Via header
maintenance of the original request. a state machine.
The ACK request MUST contain TU communicates with the
same Route headers as 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 whose response to send,
and an IP address, port, and transport to send it is acknowledging
. to. The CSeq header in the ACK MUST contain the same value for client
transaction begins execution of its state machine. Valid responses
are passed up to the
sequence number as was present in TU from the original request, but client transaction.
There are two types of client transaction state machines, depending
on the method parameter MUST be equal to "ACK".
If of the INVITE request whose response is being acknowledged had Route
headers, those headers MUST appear in passed by the TU. One handles client
transactions for INVITE request. 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 ensure
that the ACK can be routed properly through any downstream stateless
proxies.
Although any request MAY contain a body, as a body in an ACK non-INVITE client transaction. There is special
since no client transaction
for ACK. If the request cannot be rejected if TU wishes to send an ACK, it passes one directly to
the body transport layer for transmission.
The INVITE transaction is not understood.
Therefore, placement different from those of bodies other methods
because of its extended duration. Normally, human input is required
in ACK order to respond to an INVITE. The long delays expected for non-2xx is NOT RECOMMENDED,
but if done,
sending a response argue for a three way handshake. Requests of other
methods, on the body types other hand, are restricted expected to any that appeared in
the INVITE, assuming that that the response complete rapidly. In
fact, because of its reliance on just a two way handshake, TUs SHOULD
respond immediately to the INVITE was not
415. If it was, the body in the ACK MAY be any type listed in the
Accept header in the 415.
These rules for construction of ACK only apply to the client
transaction. A UAC core non-INVITE requests. Protocol extensions which generates an ACK
require longer durations for 2xx MUST generation of a response (such as a new
method that does require human interaction) SHOULD instead
follow use two
transactions - one to send the rules described request, and another in Section 13.
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>
Various Authors [Page 116]
Internet Draft SIP January 28, 2002
From: Alice <sip:alice@atlanta.com>;tag=88sja8x
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
The ACK request for a non-2xx final response reverse
direction 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
Call-ID: 987asjd97y7atg
CSeq: 986759 ACK
17.1.2 non-INVITE convey the result of the request.
17.1.1 INVITE Client Transaction
17.1.2.1
17.1.1.1 Overview of the non-INVITE INVITE Transaction
Non-INVITE transactions do not make use
The INVITE transaction consists of ACK. They are a simple
request-response interaction. three-way handshake. The client
transaction sends an INVITE, the server transaction sends responses,
and the client transaction sends an ACK. For unreliable transports, transports
(such as UDP), the client transaction will retransmit requests are
retransmitted at an
interval which that starts at T1, T1 seconds and doubles until it
hits T2. If a provisional response after every
retransmission. T1 is received, retransmissions
continue for unreliable transports, but at an interval estimate of T2. The
server transaction retransmits the last response RTT, and it sent (which can
be a provisional or final response) only when a retransmission defaults to 500
ms. Nearly all of the
request is received. This transaction timers described here scale with
T1, and changing T1 is why how their values are adjusted. The request retransmissions need to
continue even after is
not retransmitted over reliable transports. After receiving a provisional 1xx
response, they any retransmissions cease altogether, and the client waits
for further responses. The server transaction can send additional 1xx
Various Authors [Page 116]
Internet Draft SIP February 4, 2002
responses, which are what ensure
reliable delivery of not transmitted reliably by the server
transaction. If the provisional response needs to be sent reliably,
this is handled by the TU. Eventually, the server transaction decides
to send a final response.
Unlike an INVITE transaction, a non-INVITE transaction has no special
handling For unreliable transports, that response is
retransmitted periodically, and for the 2xx response. The result reliable transports, it is that only a single 2xx sent
once. For each final response to a non-INVITE that is received at the client
transaction, the client transaction sends an ACK, the purpose of
which is ever delivered to a UAC.
17.1.2.2 quench retransmissions of the response.
17.1.1.2 Formal Description
The state machine for the non-INVITE INVITE client transaction is shown in
Figure 6. It is very similar to the state machine for INVITE. 5. The "Trying" state is initial state, "calling", MUST be entered when the TU
initiates a new client transaction with a an INVITE request. When entering this state, the The client
transaction SHOULD set timer F to fire in 64*T1 seconds. The request MUST be passed pass the request to the transport layer for transmission.
transmission (see Section 19). If an
Various Authors [Page 117]
Internet Draft SIP January 28, 2002 unreliable transport is in use, being
used, the client transaction MUST set timer
E to fire in T1 seconds. If SHOULD start timer E fires while still in this state,
the A with a value of T1,
and SHOULD NOT start timer A when a reliable transport is reset, but this time being used
(Timer A controls request retransmissions). For any transport, the
client transaction MUST start timer B with a value of MIN(2*T1, T2). 64*T1 seconds
(Timer B controls transaction timeouts).
When
the timer fires again, A fires, the client transaction SHOULD retransmit the
request by passing it is reset to the transport layer, and SHOULD reset the
timer with a MIN(4*T1, T2). value of 2*T1. The formal definition of retransmit
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 SHOULD be
retransmitted again (assuming the client transaction is still in this
state). This process
continues, SHOULD continue, so that retransmissions occur the request is
retransmitted with an exponentially
increasing inverval intervals that caps at T2. double after each transmission.
These retransmissions SHOULD only be done while the client
transaction is in the "calling" state.
The default value of T2 for T1 is 4s,
and it represents the amount 500 ms. T1 is an estimate 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 RTT
between the client and T2, this results server transactions. The optional RTT
estimation procedure of Section 17.3 MAY be followed, in
intervals which case
the resulting estimate MAY be used instead of 500 ms, 1 s, 2 s, 4 s, 4 s, 4s, etc. ms. If no RTT
estimation is used, other values MAY be used in private networks
where it is known that RTT has a different value. On the public
Internet, T1 MAY be chosen larger, but SHOULD NOT be smaller.
If Timer F fires while the client transaction is still in the
"Trying" state, "calling"state when timer B
fires, the client transaction SHOULD inform the TU about that a timeout has
occurred. The client transaction MUST NOT generate an ACK. The value
Various Authors [Page 117]
Internet Draft SIP February 4, 2002
of 64*T1 is equal to the
timeout, and then it SHOULD enter amount of time required to send seven
requests in the "Terminated" state. case of an unreliable transport.
If the client transaction receives a provisional response is received while in
the "Trying" "calling" state, the
response MUST be passed it transitions to the TU, and then "proceeding" state. In the
"proceeding" state, the client transaction SHOULD move to the "Proceeding" state. If a final response (status
codes 200-699) is received while in NOT retransmit the "Trying" state,
request any longer. Furthermore, the provisional 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 TU. Any further provisional responses MUST be passed up
to the transport layer for retransmission, and Timer E MUST be
reset with a value of T2 seconds. If timer F fires TU while in the
"Proceeding" state, "proceeding" state. Passing of all provisional
responses is necessary since the TU MUST will handle reliability of these
messages, and therefore even retransmissions of a provisional
response must be informed passed upwards.
When in either the "calling" or "proceeding" states, reception of a timeout, and
response with status code from 300-699 MUST cause the client
transaction MUST to transition to "completed". The client transaction MUST
pass the terminated state. If a
final received response (status codes 200-699) is received while in the
"Proceeding" state, the response MUST be passed up to the TU, and the client transaction
MUST transition 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 "Completed" state.
Once transport layer for
transmission. The ACK MUST be sent to the same address, port and
transport that the original request was sent to. The client
transaction SHOULD start timer D when it enters the "Completed" "completed"
state, it MUST set
Timer K to fire in T4 with a value of at least 32 seconds for unreliable transports,
and a value of zero seconds for reliable transports. The "Completed" state exists to
buffer any additional response retransmissions that may be received
(which Timer D is why the client transaction remains there only for
unreliable transports). T4 represents a
reflection of the amount of time that the network
will take server transaction can
remain in the "completed" state when unreliable transports are used.
This is equal to clear messages between client and Timer H in the INVITE server transactions.
The transaction, whose
default is 64*T1. However, the client transaction does not know the
value of T4 T1 in use by the server transaction, so an absolute minimum
of 32s is 5s. used instead of basing Timer D on T1.
Any retransmissions of the final response that are received while in
the "completed" state SHOULD 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 a retransmission when it
matches
defined as any response which would match the same client
transaction, using based on the rules specified in of Section 17.1.3.
If Timer K timer D fires while the client transaction is in this the "completed"
state, the client transaction MUST transition move to the "Terminated" state.
Once terminated state, and
it MUST inform the transaction is TU of the timeout.
When in either the "calling" or "proceeding" states, reception of a
2xx response MUST cause the client transaction to enter the
terminated state, it and the response MUST be
destroyed. As with client transactions, passed up to the TU. The
handling of this response depends on whether the TU is needed to ensure
reliability a proxy core
or a UAC core. A UAC core will handle generation of the 2xx responses to INVITE.
17.1.3 Matching Responses to Client Transactions ACK for this
Various Authors [Page 118]
Internet Draft SIP January 28, February 4, 2002
|Request
|INVITE from app
|send request TU
Timer E A fires |INVITE sent
Reset A, V
send request Timer B fires
INVITE sent +-----------+ or Transport Err.
+---------| |-------------------+ |---------------+inform TU
| | Trying Calling | Timer F |
+-------->| | or Transport Err.| |-------------->|
+-----------+ inform TU |
200-699 2xx |
| |
resp. 2xx to TU |
| |1xx |
300-699 +---------------+ |resp. |1xx to TU |
ACK sent | | |
resp. to TU | Timer E 1xx V Timer F |
| send req +-----------+ or Transport Err. 1xx to TU -----------+ |
| +---------| | inform TU |
| | |Proceeding |------------------>| |-------------->|
| +-------->| |-----+ | 2xx |
| +-----------+ |1xx 2xx to TU |
| 300-699 | ^ |resp to TU |
| 200-699 ACK sent, | +--------+ |
| resp. to TU | TU| |
| | | NOTE:
| 300-699 V |
| +-----------+ | ACK sent +-----------+Transport Err. | transitions
| +---------| |Inform TU | labeled with
| | | Completed |-------------->| the event
| +-------->| | | | | | over the action
| +-----------+ | to take
| ^ | |
| | | Timer K D fires |
+--------------+ | - |
| |
V |
NOTE:
+-----------+ |
| | |
transitions
| Terminated|<------------------+
labeled with Terminated|<--------------+
| |
the event
+-----------+
over the action
to take
Figure 6: non-INVITE 5: INVITE client transaction
Various Authors [Page 119]
Internet Draft SIP January 28, February 4, 2002
When the transport layer in the client receives a
response, it has to
figure out which client transaction will handle the response, so that while a proxy core will always forward the processing 200 (OK)
upstream. The differing treatment of Sections 17.1.1 200 (OK) between proxy and 17.1.2 can UAC
is the reason that handling of it does not take place.
The branch parameter place in the top Via header is used for this purpose.
A response matches a
transaction layer.
The client transaction under two conditions. First,
if MUST be destroyed the response has instant it enters the same value of
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 branch parameter 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 top
Via header as transport, if the branch parameter in transport layer finds
no matching client transaction (using the top Via header rules of Section 17.1.3),
the
request that created response is passed directly to the transaction. Second, if core. Since the method parameter
in matching
client transaction is destroyed by the CSeq header matches first 2xx, subsequent 2xx will
find no match and therefore be passed to the method core.
17.1.1.3 Construction of the request that created the
transaction. ACK Request
The method is needed since a CANCEL ACK request constitutes
a different transaction, but shares the same value of the branch
parameter.
A response which matches a transaction matched constructed by a previous response
is considered a retransmission of that response.
17.1.4 Handling Transport Errors
When the client transaction sends a request to MUST contain
values for the transport layer Call-ID, From, and Request-URI which are equal to
be sent, the following procedures are followed if
values of those header fields in the transport layer
indicates a failure.
The client transaction SHOULD inform request passed to the TU that a transport failure
has occurred, and
by the client transaction SHOULD transition directly
to (call this the terminated state.
17.2 Server Transaction "original request"). The server transaction is responsible for To
header field in the delivery of requests to ACK MUST equal the TU, To header field in the
response being acknowledged, and will therefore usually differ from
the reliable transmission of responses. It accomplishes
this through a state machine. Server transactions are created To header field in the original request by the
core when addition of the
tag parameter. The ACK MUST contain a request is received, single Via header field, and transaction handling is desired
for that request (this won't always
this MUST be equal to the case).
As with top Via header field of the client transactions, original
request. The ACK request MUST contain the state machine depends on whether same Route header fields as
the received request whose response it is an INVITE request or not.
17.2.1 INVITE Server Transaction acknowledging. The state diagram CSeq header field
in the ACK MUST contain the same value for the INVITE server transaction is shown sequence number as was
present in
Figure 7.
When a server transaction is constructed with a the original request, it enters but the "Proceeding" state. The server transaction method parameter MUST generate a 100
response (not any status code -- be
equal to "ACK".
If the specific value of 100) unless it
knows that the TU will generate a provisional or final INVITE request whose response
Various Authors [Page 120]
Internet Draft SIP January 28, 2002
withpin 200 ms, is being acknowledged had Route
header fields, those header fields MUST appear in which case it MAY generate a 100 (Trying)
response. the ACK. This provisional response is needed
to rapidly quench ensure that the ACK can be routed properly through any downstream
stateless proxies.
Although any request retransmissions MAY contain a body, a body in order to avoid network congestion. The
100 response an ACK is constructed according to special
since the procedures request cannot be rejected if the body is not understood.
Therefore, placement of bodies in Section
8.2.6, except ACK for non-2xx is NOT RECOMMENDED,
but if done, the body types are restricted to any that insertion of tags appeared in
the To field of INVITE, assuming that that the response
(when none to the INVITE was present not
415. If it was, the body in the request), is downgraded from ACK MAY to
SHOULD NOT. The request MUST be passed to the TU.
The TU passes any number type listed in the
Accept header field in the 415.
Various Authors [Page 120]
Internet Draft SIP February 4, 2002
These rules for construction of provisional responses ACK only apply to the server client
transaction. So long as A UAC core which generates an ACK for 2xx MUST instead
follow the server transaction is rules described in Section 13. For example, consider the "Proceeding"
state, each of these MUST be passed
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 transport layer for
transmission. non-INVITE Transaction
Non-INVITE transactions do not make use of ACK. They are not sent reliably by the transaction layer
(they a simple
request-response interaction. For unreliable transports, requests are not
retransmitted by it), and do not cause a change in the
state of the server transaction. When provisional responses need to
be delivered reliably, it is handled by the TU, at an interval which will retransmit
the provisional responses itself, starts at T1, and pass downwards each
retransmission to the server transaction. doubles until it
hits T2. If a request
retransmission is received while in the "Proceeding" state, the most
recent provisional response that was received from is received, retransmissions
continue for unreliable transports, but at an interval of T2. The
server transaction retransmits the TU MUST last response it sent (which can
be
passed to a provisional or final response) only when a retransmission of the transport layer for retransmission. A
request is received. This is why request retransmissions need to
continue even after a
retransmission if it matches the same server transaction based on the
rules provisional response, they are what