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-05.txt
October 26, 2001
draft-ietf-sip-rfc2543bis-06.txt
January 28, 2002
Expires: April July 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, assist in firewall traversal, 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.
1 Introduction
Various Authors [Page 1] a]
Internet Draft SIP October 26, 2001
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, SIP relies on 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 January 28, 2002
Table of session that is being
established. Contents
1 Introduction ........................................ 2
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. A SIP entity issuing an
invitation for an already existing session does not necessarily have
to be a member ....................... 2
3 Terminology ......................................... 3
4 Overview of Operation ............................... 4
5 Structure of the session to which it is inviting. Media can be
added to (and removed from) an existing session. Protocol ........................... 11
6 Definitions ......................................... 13
7 SIP transparently
supports name mapping and redirection services, which supports
personal mobility [1] - users can maintain a single externally
visible identifier (SIP URI) regardless of their network location. Messages ........................................ 19
7.1 Requests ............................................ 20
7.2 Responses ........................................... 20
7.3 Header Fields ....................................... 21
7.3.1 Header Field Format ................................. 22
7.3.2 Header Field Classification ......................... 24
7.3.3 Compact Form ........................................ 25
7.4 Bodies .............................................. 25
7.4.1 Message Body Type ................................... 25
7.4.2 Message Body Length ................................. 25
7.5 Framing SIP supports five facets of establishing and terminating multimedia
communications: messages ................................ 26
8 General User location: determination of Agent Behavior ......................... 26
8.1 UAC Behavior ........................................ 27
8.1.1 Generating the end system to be used for
communication;
User availability: determination of Request .............................. 27
8.1.1.1 Request-URI ......................................... 27
8.1.1.2 To .................................................. 27
8.1.1.3 From ................................................ 28
8.1.1.4 Call-ID ............................................. 29
8.1.1.5 CSeq ................................................ 30
8.1.1.6 Max-Forwards ........................................ 30
8.1.1.7 Via ................................................. 31
8.1.1.8 Contact ............................................. 31
8.1.1.9 Supported and Require ............................... 32
8.1.1.10 Additional Message Components ....................... 32
8.1.2 Sending the willingness of Request ................................. 33
8.1.3 Loose Routing Policies .............................. 33
8.1.3.1 Modifying the
called party to engage in communications;
User capabilities: determination of Route header field .................... 33
8.1.3.2 Modifying 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 October 26, 2001
Session handling: including transfer and termination of
sessions, modifying session parameters, and invoking
services.
SIP is not a vertically integrated communications system. Request-URI ........................... 34
8.1.3.3 Destination Choice .................................. 34
8.1.3.4 Loop Avoidance ...................................... 34
8.1.4 Processing Responses ................................ 35
8.1.4.1 Transaction Layer Errors ............................ 35
8.1.4.2 Unrecognized Responses .............................. 35
8.1.4.3 Vias ................................................ 36
8.1.4.4 Processing Reliable 1xx Responses ................... 36
Various Authors [Page b]
Internet Draft SIP is
rather a component of the overall IETF multimedia data and control
architecture which incorporates protocols such as RSVP (RFC 2205 [2])
for reserving network resources, the real-time transport protocol
(RTP) (RFC 1889 [3]) for transporting real-time data January 28, 2002
8.1.4.5 Processing 3xx responses ............................ 36
8.1.4.6 Processing 4xx responses ............................ 38
8.2 UAS Behavior ........................................ 39
8.2.1 Method Inspection ................................... 39
8.2.2 Header Inspection ................................... 39
8.2.2.1 To and providing
QOS feedback, Request-URI .................................. 39
8.2.2.2 Merged Requests ..................................... 40
8.2.2.3 Require ............................................. 40
8.2.3 Content Processing .................................. 41
8.2.4 Applying Extensions ................................. 42
8.2.5 Processing the real-time streaming protocol (RTSP) (RFC 2326 [4])
for controlling delivery of streaming media, Request .............................. 42
8.2.6 Generating the session announcement
protocol (SAP) [5] for advertising multimedia sessions via multicast Response ............................. 42
8.2.6.1 Sending a Provisional Response ...................... 42
8.2.6.2 Headers and Tags .................................... 43
8.2.7 Stateless UAS Behavior .............................. 43
8.3 Redirect Servers .................................... 44
9 Canceling a Request ................................. 45
9.1 Client Behavior ..................................... 46
9.2 Server Behavior ..................................... 47
10 Registrations ....................................... 48
10.1 Overview ............................................ 48
10.2 Constructing the session description protocol (SDP) (RFC 2327 [6]) for
describing multimedia sessions. Therefore, SIP should be used in
conjunction with other protocols in order to provide complete
services to the users. However, REGISTER Request ................... 49
10.2.1 Adding Bindings ..................................... 52
10.2.1.1 Setting the basic functionality and operation
of SIP does not depend on any Expiration Interval 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 Contact
Addresses ...................................................... 52
10.2.1.2 Preferences among Contact Addresses ................. 53
10.2.2 Removing Bindings ................................... 53
10.2.3 Fetching Bindings ................................... 53
10.2.4 Refreshing Bindings ................................. 53
10.2.5 Setting the Internal Clock .......................... 54
10.2.6 Discovering a user and deliver an opaque object to his current location.
If this primitive is used to deliver Registrar ............................. 54
10.2.7 Transmitting a session description written in
SDP, Request .............................. 55
10.2.8 Error Responses ..................................... 55
10.3 Processing REGISTER Requests ........................ 55
11 Querying for instance, the parameters Capabilities ........................... 58
11.1 Construction of OPTIONS Request ..................... 59
11.2 Processing of OPTIONS Request ....................... 59
12 Dialogs ............................................. 61
12.1 Creation of a session can be agreed between
endpoints. If the same primitive is used to deliver Dialog ................................ 62
12.1.1 UAS behavior ........................................ 62
12.1.2 UAC behavior ........................................ 63
12.2 Requests within a photo of Dialog ............................ 64
12.2.1 UAC Behavior ........................................ 65
12.2.1.1 Generating the
caller as well as Request .............................. 65
12.2.1.2 Processing the session description, a "caller ID" service can
be easily implemented. As this example shows, Responses ............................ 66
12.2.2 UAS behavior ........................................ 67
12.3 Termination of a single primitive is
typically used to provide several different services. Consequently,
generality is more important than efficiency when designing SIP
primitives.
SIP does not offer conference control services such as floor control
or voting and does not prescribe how Dialog ............................. 69
13 Initiating a conference is to be managed,
but Session ................................ 69
Various Authors [Page c]
Internet Draft SIP can be used to initiate a session that uses some other
conference control protocol. SIP does not allocate multicast
addresses and does not reserve network resources.
3 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and
indicate requirement levels for compliant SIP implementations.
4 January 28, 2002
13.1 Overview of Operation
This section will introduce ............................................ 69
13.2 Caller Processing ................................... 70
13.2.1 Creating the basic operations Initial INVITE ......................... 70
13.2.2 Processing INVITE Responses ......................... 72
13.2.2.1 1xx responses ....................................... 72
13.2.2.2 3xx responses ....................................... 72
13.2.2.3 4xx, 5xx and 6xx responses .......................... 72
13.2.2.4 2xx responses ....................................... 73
13.3 Callee Processing ................................... 74
13.3.1 Processing of the SIP protocol
using simple examples. Note that this section INVITE ............................ 74
13.3.1.1 Progress ............................................ 75
13.3.1.2 The INVITE is tutorial in nature
and does not contain any normative statements.
Various Authors [Page 3]
Internet Draft SIP October 26, 2001 redirected ............................ 75
13.3.1.3 The first example will show the basic functions of SIP: location of INVITE is rejected .............................. 76
13.3.1.4 The INVITE is accepted .............................. 76
14 Modifying an end point, signaling a desire to communicate, negotiation of
session parameters to establish the session, and teardown of the
session once established.
Figure 1 shows Existing Session ....................... 77
14.1 UAC Behavior ........................................ 77
14.2 UAS Behavior ........................................ 79
15 Terminating a typical example of Session ............................... 80
15.1 Terminating a SIP message exchange between
two users, Alice and Bob. (Each message is labeled Dialog 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 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 softphone) to call
Bob on his SIP phone over the Internet. Also shown are two SIP proxy
servers which act on behalf 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 ................................ 108
17 Transactions ........................................ 109
17.1 Client Transaction .................................. 111
17.1.1 INVITE Client Transaction ........................... 112
17.1.1.1 Overview of INVITE Transaction ...................... 112
17.1.1.2 Formal Description .................................. 113
17.1.1.3 Construction 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 ACK Request ..................... 116
17.1.2 non-INVITE Client Transaction ....................... 117
17.1.2.1 Overview of the dashed
lines in Figure 1.
Alice "calls" Bob using his non-INVITE Transaction .............. 117
17.1.2.2 Formal Description .................................. 117
17.1.3 Matching Responses to Client Transactions ........... 118
17.1.4 Handling Transport Errors ........................... 120
17.2 Server Transaction .................................. 120
17.2.1 INVITE Server Transaction ........................... 120
17.2.2 non-INVITE Server Transaction ....................... 123
17.2.3 Matching Requests to Server Transactions ............ 124
Various Authors [Page d]
Internet Draft SIP identity, a type January 28, 2002
17.2.4 Handling Transport Errors ........................... 126
17.3 RTT Estimation ...................................... 126
18 Reliability of Uniform Resource
Identifier (URI) called a SIP URI and defined in Section 21.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 Provisional Responses ................ 127
18.1 UAS Behavior ........................................ 128
18.2 UAC Behavior ........................................ 130
19 Transport ........................................... 131
19.1 Clients ............................................. 132
19.1.1 Sending Requests .................................... 132
19.1.2 Receiving Responses ................................. 134
19.2 Servers ............................................. 134
19.2.1 Receiving Requests .................................. 134
19.2.2 Sending Responses ................................... 135
19.3 Framing ............................................. 136
19.4 Error Handling ...................................... 136
20 Usage of Bob's SIP service provider (which can be
an enterprise, retail provider, etc). Alice also has a HTTP Authentication ........................ 137
20.1 Framework ........................................... 137
20.2 User-to-User Authentication ......................... 139
20.3 Proxy to User Authentication ........................ 141
20.4 The Digest Authentication Scheme .................... 143
20.4.1 HTTP Digest ......................................... 143
21 S/MIME .............................................. 145
21.1 S/MIME Certificates ................................. 145
21.2 S/MIME Key Exchange ................................. 146
21.3 Securing MIME bodies ................................ 148
21.4 Tunneling SIP URI of
sip:alice@atlanta.com. Alice might have typed in Bob's URI or perhaps
clicked on MIME ............................... 149
21.4.1 Tunneling Integrity and Authentication .............. 149
21.4.2 Tunneling Encryption ................................ 151
22 Security Considerations ............................. 152
22.1 Threat Models ....................................... 153
22.1.1 Registration Hijacking .............................. 153
22.1.2 Impersonating a hyperlink or an entry in an address book.
SIP is based on an HTTP-like request/response transacton model. Each
transaction consists Server .............................. 154
22.1.3 Tampering with Message Bodies ....................... 154
22.1.4 Tearing Down Sessions ............................... 155
22.1.5 Denial of a request that invokes a particular "Method",
or function, on the server, Service 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 Amplification ................. 156
22.2 Security Mechanisms ................................. 156
22.2.1 Transport and Network Layer Security ................ 157
22.2.2 HTTP Authentication ................................. 158
22.2.3 S/MIME .............................................. 158
22.3 Implementing Security Mechanisms .................... 159
22.3.1 Requirements for Implementers 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 additional named attributes which
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, ................ 159
22.3.2 Security Solutions .................................. 160
22.3.2.1 Registration ........................................ 160
22.3.2.2 Requests and information about the type of session
that Alice wishes Transitive Trust ....................... 161
22.3.2.3 Peer to establish with Bob. The INVITE (message F1 in
Figure 1) might look like this:
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP 10.1.3.3:5060
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3
CSeq: 314159 INVITE
Contact: <sip:alice@10.1.3.3>
Content-Type: application/sdp Peer Requests ............................... 163
22.3.2.4 DoS Protection ...................................... 164
22.4 Limitations ......................................... 165
22.4.1 HTTP Digest ......................................... 165
22.4.2 S/MIME .............................................. 166
Various Authors [Page 4] e]
Internet Draft SIP October 26, 2001
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone January 28, 2002
22.4.3 TLS ................................................. 167
22.5 Privacy ............................................. 167
23 Common Message Components ........................... 168
23.1 SIP Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F3 | |
| 100 Trying F2 |--------------->| INVITE F5 |
|<---------------| 100 Trying F4 |--------------->|
| |<-------------- | 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: Uniform Resource Indicators ..................... 168
23.1.1 SIP session setup example with URI Components .................................. 168
23.1.2 Character Escaping Requirements ..................... 172
23.1.3 Example SIP trapezoid
Contact-Length: 142
(Alice's SDP not shown)
The first line of the text-encoded message contains the method name
(INVITE). The lines which follow are a list of header fields. This
example contains URIs .................................... 172
23.1.4 SIP URI Comparison .................................. 173
23.1.5 Forming Requests from a minimum required set. The headers are briefly
described below:
Via contains the IP address (10.1.3.3), port number (5060), SIP URI ..................... 175
23.1.6 Relating SIP URIs and
transport protocol (UDP) on which Alice is expecting to receive
responses to this request. tel URLs ...................... 176
23.2 Option Tags ......................................... 178
23.3 Tags ................................................ 179
24 Header Fields ....................................... 179
24.1 Accept .............................................. 181
24.2 Accept-Encoding ..................................... 181
24.3 Accept-Language ..................................... 184
24.4 Alert-Info .......................................... 184
24.5 Allow ............................................... 184
24.6 Authentication-Info ................................. 185
24.7 Authorization ....................................... 185
24.8 Call-ID ............................................. 186
24.9 Call-Info ........................................... 186
24.10 Contact ............................................. 186
24.11 Content-Disposition ................................. 187
24.12 Content-Encoding .................................... 188
24.13 Content-Language .................................... 189
24.14 Content-Length ...................................... 189
24.15 Content-Type ........................................ 189
24.16 CSeq ................................................ 190
24.17 Date ................................................ 190
24.18 Error-Info .......................................... 191
24.19 Expires ............................................. 191
24.20 From ................................................ 191
24.21 In-Reply-To ......................................... 192
24.22 Max-Forwards ........................................ 192
24.23 Min-Expires ......................................... 193
24.24 MIME-Version ........................................ 193
24.25 Organization ........................................ 193
24.26 Priority ............................................ 194
24.27 Proxy-Authenticate .................................. 194
24.28 Proxy-Authorization ................................. 195
24.29 Proxy-Require ....................................... 195
24.30 RAck ................................................ 195
24.31 Record-Route ........................................ 196
24.32 Reply-To ............................................ 196
24.33 Require ............................................. 196
24.34 Retry-After ......................................... 197
24.35 Route ............................................... 197
Various Authors [Page 5] f]
Internet Draft SIP October 26, 2001 January 28, 2002
24.36 RSeq ................................................ 198
24.37 Server .............................................. 198
24.38 Subject ............................................. 198
24.39 Supported ........................................... 199
24.40 Timestamp ........................................... 199
24.41 To contains a display name (Bob) and a SIP URI (sip:bob@biloxi.com)
that the request was originally directed towards.
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 which contains a
pseudorandom string (1928301774) which was added to the .................................................. 199
24.42 Unsupported ......................................... 200
24.43 User-Agent .......................................... 200
24.44 Via ................................................. 200
24.45 Warning ............................................. 201
24.46 WWW-Authenticate .................................... 203
25 Response Codes ...................................... 203
25.1 Provisional 1xx ..................................... 204
25.1.1 100 Trying .......................................... 204
25.1.2 180 Ringing ......................................... 204
25.1.3 181 Call Is Being Forwarded ......................... 204
25.1.4 182 Queued .......................................... 204
25.1.5 183 Session Progress ................................ 204
25.2 Successful 2xx ...................................... 205
25.2.1 200 OK .............................................. 205
25.3 Redirection 3xx ..................................... 205
25.3.1 300 Multiple Choices ................................ 205
25.3.2 301 Moved Permanently ............................... 205
25.3.3 302 Moved Temporarily ............................... 206
25.3.4 305 Use Proxy ....................................... 206
25.3.5 380 Alternative Service ............................. 206
25.4 Request Failure 4xx ................................. 206
25.4.1 400 Bad Request ..................................... 206
25.4.2 401 Unauthorized .................................... 207
25.4.3 402 Payment Required ................................ 207
25.4.4 403 Forbidden ....................................... 207
25.4.5 404 Not Found ....................................... 207
25.4.6 405 Method Not Allowed .............................. 207
25.4.7 406 Not Acceptable .................................. 207
25.4.8 407 Proxy Authentication Required ................... 207
25.4.9 408 Request Timeout ................................. 208
25.4.10 410 Gone ............................................ 208
25.4.11 413 Request Entity Too Large ........................ 208
25.4.12 414 Request-URI Too Long ............................ 208
25.4.13 415 Unsupported Media Type .......................... 208
25.4.14 416 Unsupported 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 Scheme .......................... 208
25.4.15 420 Bad Extension ................................... 208
25.4.16 421 Extension Required .............................. 209
25.4.17 423 Registration Too Brief .......................... 209
25.4.18 480 Temporarily Unavailable ......................... 209
25.4.19 481 Call/Transaction Does Not Exist ................. 209
25.4.20 482 Loop Detected ................................... 210
25.4.21 483 Too Many Hops ................................... 210
Various Authors [Page g]
Internet Draft 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 January 28, 2002
25.4.22 484 Address Incomplete .............................. 210
25.4.23 485 Ambiguous ....................................... 210
25.4.24 486 Busy Here ....................................... 211
25.4.25 487 Request Terminated .............................. 211
25.4.26 488 Not Acceptable Here ............................. 211
25.4.27 491 Request Pending ................................. 211
25.4.28 493 Undecipherable .................................. 211
25.5 Server Failure 5xx .................................. 211
25.5.1 500 Server Internal Error ........................... 211
25.5.2 501 Not Implemented ................................. 212
25.5.3 502 Bad Gateway ..................................... 212
25.5.4 503 Service Unavailable ............................. 212
25.5.5 504 Server Time-out ................................. 212
25.5.6 505 Version Not Supported ........................... 212
25.5.7 513 Message Too Large ............................... 213
25.6 Global Failures 6xx ................................. 213
25.6.1 600 Busy Everywhere ................................. 213
25.6.2 603 Decline ......................................... 213
25.6.3 604 Does Not Exist Anywhere ......................... 213
25.6.4 606 Not Acceptable .................................. 213
26 Examples ............................................ 214
26.1 Registration ........................................ 214
26.2 Session Setup ....................................... 215
27 Augmented BNF for each new request, the SIP Protocol ................. 220
27.1 Basic Rules ......................................... 222
28 IANA Considerations ............................ 239
28.1 Option Tags ......................................... 239
28.1.1 Registration of 100rel .............................. 240
28.2 Warn-Codes .......................................... 241
28.3 Header Field Names .................................. 241
28.4 Method and is a traditional
sequence number.
Contact contains Response Codes ........................... 242
29 Changes Made in Version 00 .......................... 242
30 Changes Made in Version 01 .......................... 249
31 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 Changes Made in Version 06 .......................... 260
36 Acknowledgments ..................................... 272
37 Authors' Addresses .................................. 272
38 Bibliography ........................................ 274
EOTOC
Various Authors [Page h]
1 Introduction
There are many applications of the Internet that require the creation
and management of a SIP URI which represents session, where a direct route to reach
or contact Alice, usually composed session is considered an
exchange of a username at data between an IP address.
While the Via header field association of participants. The
implementation of these services is used 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 tell other elements where discover one another and to
send the response, the Contact header field tells other elements
where agree on a
characterization of a session they would like to send future requests share. For locating
prospective session participants, and for this dialog.
Content-Type contains a description other functions, SIP
enables creation of the message body (not shown).
Content-Length contains an octet (byte) count of the message body.
The complete set infrastructure of network hosts (called "proxy
servers") to which user agents can send registrations, invitations to
sessions and other requests. SIP header fields is defined in Section 22.
The details an agile, general-purpose tool
for creating, modifying and terminating sessions that works
independently of underlying transport protocols and without
dependency on the session, type of media, codec, sampling rate, etc.
are not described using SIP. Rather, the body session that is being established.
2 Overview of a SIP message
contains a description of the session, encoded in some other protocol
format. One such format is Functionality
The Session Description Initiation Protocol (SDP) [6].
This SDP message (not shown in the example) (SIP) is carried by the SIP
message in an analogous way application-layer control
protocol that a document attachment is carried by
an email message, or a web page is carried in 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 HTTP message.
Since the softphone has no knowledge existing
session. SIP transparently supports name mapping and redirection
services, which supports personal mobility [1] - users can maintain a
single externally visible identifier (SIP URI) regardless of Bob's exact location, or how
to locate the their
network location.
SIP server in the biloxi.com domain, the softphone
sends supports five facets of establishing and terminating multimedia
communications:
User location: determination of the INVITE end system to be used for
communication;
User availability: determination of the SIP server that serves Alice's domain,
atlanta.com. The IP address willingness of the atlanta.com SIP server could have
been configured
called party to engage in Alice's softphone, or it could have been
discovered by DHCP, for example.
The atlanta.com SIP server is a type communications;
User capabilities: determination of SIP server known as a proxy
server. A proxy server receives SIP requests the media and forwards them on media
parameters to be used;
Session setup: "ringing", establishment of session parameters at
both called and calling party;
Various Authors [Page 6] 2]
Internet Draft SIP October 26, 2001
behalf January 28, 2002
Session management: including transfer and termination of the requestor. In this example, the proxy server receives
the INVITE request
sessions, modifying session parameters, and generates invoking
services.
SIP is not a 100 Trying response which vertically integrated communications system. SIP is sent
back to Alice's softphone. The 100 Trying response indicates
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
INVITE has been received real-time transport
protocol (RTP) (RFC 1889 [2]) for transporting real-time data and that
providing QoS feedback, the proxy is working on her behalf
to try to route real-time streaming protocol (RTSP) (RFC
2326 [3]) for controlling delivery of streaming media, the INVITE Media
Gateway Control Protocol (MEGACO) (RFC 3015 [4]) for controlling
gateways to the destination. Responses in SIP use
a numerical three digit code followed by a descriptive phrase. This
response contains the same To, From, Call-ID, Public Switched Telephone Network (PSTN), and CSeq as the INVITE,
which allows Alice's softphone
session description protocol (SDP) (RFC 2327 [5]) for describing
multimedia sessions. Therefore, SIP should be used in conjunction
with other protocols in order to correlate this response provide complete services to the sent
INVITE. The atlanta.com proxy server locates
users. However, the proxy server at
biloxi.com, possibly by performing a DNS (Domain Name Service) lookup 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 find the implement different services. For example, SIP server which serves the biloxi.com domain. This can
locate a user and deliver an opaque object to his current location.
If this primitive is
described in Section 24. As used to deliver a result, it obtains session description written in
SDP, for instance, the IP address parameters of a session can be agreed between
endpoints. If the biloxi.com proxy server and forwards, or proxies, same primitive is used to deliver a photo of the INVITE
request there. Before forwarding
caller as well as the request, the atlanta.com proxy
server adds an additional Via header field which 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 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 responds
with does not prescribe how a 100 Trying response back conference is to the Atlanta.com proxy server be managed.
SIP can be used to
indicate initiate a session that it has received the INVITE uses some other conference
control protocol. Since SIP messages and is processing the
request. sessions they establish
can pass through entirely different networks, SIP cannot, and does
not, provide any kind of network resource reservation capabilities.
The proxy server consults a database, generically called a
location service, which contains the current IP address nature 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 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 the INVITE user and proxies it proxy to Bob's SIP phone.
Bob's user), integrity protection, and encryption and
privacy services.
SIP phone receives the INVITE works with both IPv4 and begins to alert Bob to IPv6.
3 Terminology
In this document, the
incoming call from Alice so that Bob can decide whether or not key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
Various Authors [Page 3]
Internet Draft SIP January 28, 2002
and "OPTIONAL" are to
answer the call - i.e. Bob's phone rings. Bob's be interpreted as described in RFC 2119 [6] and
indicate requirement levels for compliant SIP phone sends an
indication implementations.
4 Overview of this in a 180 Ringing response. Operation
This response is routed
back thorough section introduces the two proxies 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 reverse direction. Each proxy
uses the Via header basic functions of SIP: location of an
end point, signal of a desire to figure out where communicate, negotiation of session
parameters to send establish the response, session, and
removes its own address from teardown of the top. As session once
established.
Figure 1 shows a result, although DNS typical example of a SIP message exchange between
two users, Alice and
location service lookups were required to route Bob. (Each message is labeled with the initial INVITE, letter
"F" and a number for reference by the 180 Ringing response can be returned 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 caller without
lookups, or without state being maintained in the proxies. This also
has the desirable property that each Internet. Also shown are two SIP proxy
servers that sees act on behalf of Alice and Bob to facilitate the INVITE will
also see all responses session
establishment. This typical arrangement is often referred to as the INVITE.
When Alice's softphone receives
"SIP trapezoid" as shown by the 180 Ringing response, it passes
this information to Alice, perhaps 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 audio ringback tone, 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
just by displaying perhaps
clicked on a hyperlink or flashing an entry in an address book.
SIP is based on an HTTP-like request/response transacton model. Each
transaction consists of a message request that invokes a particular "Method",
or function, on Alice's screen. the server, and at least one response. In this
example, Bob decides to answer the call. When he picks up the
handset his transaction begins with Alice's softphone sending an
INVITE request addressed to Bob's SIP phone sends URI. INVITE is an example of a 200 OK response to indicate
SIP method which specifies the action that the
call has been answered. requestor (Alice)
wants the server (Bob) to take. The 200 OK INVITE request contains a message body containing
the SDP media description 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 Bob is willing Alice
wishes 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 Bob. The INVITE (message F1 in Figure 1)
might look like this:
Various Authors [Page 7] 4]
Internet Draft SIP October 26, 2001
Alice. This two-phase exchange provides basic negotiation
capabilities, and is based on a simple offer/answer model, 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 January 28, 2002
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
softphone SIP response codes is in Section 23. The Phone
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 Trying F3 |--------------->| INVITE F4 |
|<---------------| 100 Trying F5 |--------------->|
| |<-------------- | 180 Ringing F6 |
| | 180 Ringing F7 |<---------------|
| 180 Ringing F8 |<---------------| 200 OK (message F9 in Figure
1) might look like this:
SIP/2.0 |
|<---------------| 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 10.2.1.1:5060;branch=4b43c2ff8.1
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=77ef4c2312983.1
Via: SIP/2.0/UDP 10.1.3.3:5060 pc33.atlanta.com;branch=z9hG4bK776asdhds
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3 a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@10.4.1.4> <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Contact-Length: 131
(Bob's
Content-Length: 142
(Alice's SDP not shown)
Various Authors [Page 5]
Internet Draft SIP January 28, 2002
The first line of the response text-encoded message contains the response code (200) and
the reason phrase (OK). method name
(INVITE). The remaining lines contain that follow are a list of header fields. This
example contains a minimum required set. The Via header fields, To, From, Call- ID, and CSeq headers are all copied
from briefly
described below:
Via contains the INVITE request. (Note address (pc33.atlanta.com) on which Alice is
expecting to receive responses to this request.It also contains a
branch parameter that there are three Via headers -
one added by Alice's contains an identifier for this transaction.
To contains a display name (Bob) and a SIP phone, one added by URI (sip:bob@biloxi.com)
towards which the atlanta.com proxy, request was originally directed. Display names are
described in RFC 2822 [7].
From also contains a display name (Alice) and one added by the biloxi.com proxy.) Also note that Bob's a SIP
phone URI
(sip:alice@atlanta.com) that indicate the originator of the request.
This header field also has added a tag parameter containing a pseudorandom
string (1928301774) that was added to the To header field. This tag will
be incorporated URI by both User Agents into the dialog and will be
included in all future requests and responses in softphone. It is
used for identification purposes.
Call-ID contains a globally unique identifier for this call. call,
generated by the combination of a pseudorandom string and the
softphone's IP address. The
Contact header field contains combination of the To, From, and Call-ID
completely define a URI at which Bob can be directly
reached at his peer-to-peer SIP phone. The Content-Type relationship betwee Alice and Content-Length refer
Bob, and is referred to the not shown message body which as a "dialog".
CSeq or Command Sequence contains Bob's SDP media
information.
In additon to DNS an integer and location service lookups shown in this example,
proxy servers can make arbitrarily complex "routing decisions" in
order 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 decide reach or
contact Alice, usually composed of a username at an FQDN. While a
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 a request. For example, if Bob's SIP
phone returned a 486 Busy Here response, the biloxi.com proxy server
could proxy response, the INVITE Contact header
field tells other elements where to Bob's voicemail server. A proxy server can
also send an INVITE to future requests for this
dialog.
Content-Type contains a number description of locations at the same time. This 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 parallel search 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 known as "forking".
In this case, Session Description Protocol (SDP) [5].
This SDP message (not shown in the 200 OK example) is routed back through carried by the two proxies and SIP
Various Authors [Page 8] 6]
Internet Draft SIP October 26, 2001
is received by Alice's softphone which then stops the ringback tone
and indicates January 28, 2002
message in a way that the call has been answered. Finally, an
acknowledgement message, ACK, is sent by Alice to Bob analogous to confirm a document attachment being
carried by an email message, or a web page being carried in an HTTP
message.
Since the
reception softphone does not know the location of Bob or the final response (200 OK). Note that SIP
server in this example,
the ACK is sent directly from Alice to Bob, bypassing the two
proxies. This is due to biloxi.com domain, the fact that through softphone sends the INVITE/200 OK
exchange, INVITE to
the two SIP user agents have learned each other's server that serves Alice's domain, atlanta.com. The IP
address through the Contact header fields, something which was not
known when of the initial INVITE was sent. The lookups performed atlanta.com SIP server could have been configured in
Alice's softphone, or it could have been discovered by the
two proxies are no longer needed, so they drop put DHCP, for
example.
The atlanta.com SIP server is a type of the call flow.
This completes the INVITE/200/ACK three way handshake used to
establish SIP sessions, server known as a proxy
server. A proxy server receives SIP requests and is the end forwards them on
behalf of the transaction. Full
details on session setup is in Section 13.
Alice requestor. In this example, the proxy server receives
the INVITE request and Bob's media session sends a 100 (Trying) response back to Alice's
softphone. The 100 (Trying) response indicates that the INVITE has now begun,
been received and they begin sending
media packets using that the format agreed proxy is working on her behalf to in route
the exchange of SDP. In
general, INVITE to the end-to-end media packets will take destination. Responses in SIP use a different path from three-digit
code followed by a descriptive phrase. This response contains the SIP signaling messages.
During
same To, From, Call-ID, and CSeq as the session, either Alice or Bob may decide INVITE, which allows Alice's
softphone to correlate this response to change the
characteristics of sent INVITE. The
atlanta.com proxy server locates the media session. This is accomplished proxy server at biloxi.com,
possibly by sending
a re-INVITE containing a new media description. If the change is
acceptable to the other party, performing a 200 OK is sent which is itself
responded particular type of DNS (Domain Name Service)
lookup to with an ACK. This re-INVITE will reference the existing
dialog so find the other party knows SIP server that it is to modify an existing
session instead of establishing a new session. If serves the change biloxi.com domain.
This is not
acceptable, an error response, such as described in [8]. As a 406 Not Acceptable response
is sent, which also receives an ACK. However, result, it obtains the failure IP address of
the re-
INVITE does not cause biloxi.com proxy server and forwards, or proxies, the existing call to fail - INVITE
request there. Before forwarding the session
continues using request, the previously negotiated characteristics. Full
details on session modification is 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 Section 14.
At the end of first
Via). The biloxi.com proxy server receives the call, Bob disconnects (hangs up) first, INVITE and
generates responds
with a BYE message. This BYE is routed directly 100 (Trying) response back to Alice's
softphone, again bypassing the proxies. Alice confirms receipt of the
BYE with a 200 OK response, which terminates Atlanta.com proxy server to
indicate that it has received the session INVITE and the BYE
transaction. Note that no ACK is sent - an ACK is only sent in
response to a response to an INVITE processing the
request. The reasons for this
special handling for INVITE will be discussed later, but relate to proxy server consults a database, generically called a
location service, that contains the reliability mechanisms current IP address of Bob. (We
shall see in SIP, the length of time it next section how this database can take for
a ringing phone to be answered, populated.)
The biloxi.com proxy server adds another Via header with its own IP
address to the INVITE and forking. For this reason, request
handling in proxies it to Bob's SIP is often classified as either phone.
Bob's SIP phone receives the INVITE or non- INVITE,
referring and alerts Bob to all other methods besides INVITE. Full details on
session termination is in Section 15.
Full details of all the messages shown in incoming
call from Alice so that Bob can decide whether or not to answer the example of Figure 1 are
shown in Section 25.2.
Various Authors [Page 9]
Internet Draft
call, i.e., Bob's phone rings. Bob's SIP October 26, 2001
In some cases, it may be useful for proxies phone sends an indication of
this in the SIP signaling path
see all the messaging between a 180 (Ringing) response, which is routed back through the
two endpoints for the duration of
the session. For example, if the biloxi.com proxy server wished to
remain proxies in the SIP messaging path beyond reverse direction. Each proxy uses the initial INVITE, it would
add Via header
to determine where to send the INVITE response and removes its own address
from the top. As a result, although DNS and location service lookups
were required routing header field known as Record-
Route containing a URI which resolves to route the proxy. This information
would initial INVITE, the 180 (Ringing) response
can be received by both Bob's SIP phone and (due returned to the Record-
Route header field caller without lookups or without state being passed back
maintained in the 200 OK) Alice's softphone
and stored for the duration of the dialog. proxies. This would then result in
the ACK, BYE, and 200 OK to the BYE being received and proxied by also has the
biloxi.com proxy server. Each desirable property that
Various Authors [Page 7]
Internet Draft SIP January 28, 2002
each proxy can independently decide to
receive subsequent messaging, and that messaging sees the INVITE will go through also see all
proxies that elected responses to receive it. A common use of the
INVITE.
When Alice's softphone receives the 180 (Ringing) response, it passes
this capability
is in firewall traversal information to Alice, perhaps using an audio ringback tone or mid-call feature implementation.
Registration is another common operation in SIP. Registration is one
way in which by
displaying a message on Alice's screen.
In this example, Bob decides to answer the biloxi.com server can learn call. When he picks up the current location of
Bob. Upon initialization, and at periodic intervals, Bob's
handset, his SIP phone sends REGISTER messages a server in 200 (OK) response to indicate that the biloxi.com domain known as a
SIP registrar.
call has been answered. The REGISTER messages associate Bob's SIP URL
(sip:bob@biloxi.com) 200 (OK) contains a message body with the machine he is currently logged in at
(conveyed as a SIP URL in
SDP media description of the Contact header). The registrar writes
this association, also called a binding, type of session that Bob is willing to
establish with Alice. As a database, called the
location service , where it can be used by the proxy in the
biloxi.com domain. Often, a registrar server for result, there is a domain 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 co-
located with based on a simple offer/answer model of SDP exchange. If Bob did
not wish to answer the proxy for that domain. It is call or was busy on another call, an important concept
that error
response would have been sent instead of the distinction between types 200 (OK), which would
have resulted in no media session being established. The complete
list of SIP servers are logical, not
physical.
Bob 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
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
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 limited to registering 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 a single device. For example,
both his the INVITE request. (There are three Via headers - one added by
Alice's SIP phone at home and phone, one added by the atlanta.com proxy, and one in added
by the office could send in
registrations. biloxi.com proxy.) Bob's SIP phone has added a tag parameter
to the To header field. This information is stored together in tag will be incorporated by both User
Agents into the location
service, dialog and allows will be included in all future requests
and responses in this call. The Contact header field contains a proxy to perform various types of searches to
locate Bob. Similarly, more than one user URI
at which Bob can be registered on a
single device directly reached at the same time. his SIP phone. The Content-
Various Authors [Page 8]
Internet Draft SIP January 28, 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 is just an abstract concept. It generally
contains information that allows a lookups shown in this example,
proxy servers can make flexible "routing decisions" to input decide where
to send a URI and get back request. For example, if Bob's SIP phone returned a translated URI that tells 486
(Busy Here) response, the biloxi.com proxy server could proxy where to send the request.
Registrations are one way
INVITE to create this information, but not the
only way. Arbitrarily complex mapping functions Bob's voicemail server. A proxy server can be programmed, also send an
INVITE to a number of locations at the discretion same time. This type of
parallel search is known as "forking".
In this case, the administrator.
Finally, it 200 (OK) is important to note that in SIP, registration routed back through the two proxies and
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 received by request, challenge/response mechanism, or
using a lower layer scheme as discussed in Section 20.
Various Authors [Page 10]
Internet Draft SIP October 26, 2001
The complete set of SIP message details for this registration example
is in Section 25.2.
Additional operations in SIP include querying for Alice's softphone which then stops the capabilities of
a SIP server or client using OPTIONS, ringback tone
and canceling a pending request
using CANCEL will be introduced in later sections.
5 Structure of the Protocol
The SIP protocol is structured as a layered protocol, which means indicates that its behavior is described in terms of a set of fairly
independent processing stages, with only a loose coupling between
each stage. The structuring of the protocols into layers call has been answered. Finally, an
acknowledgement message, ACK, is for sent by Alice to Bob to confirm the
purpose
reception 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, that means it final response (200 (OK)). In this example, the ACK
is compliant sent directly from Alice to Bob, bypassing the set of rules
defined by that layer.
Not every element specified by two proxies. This
is because, through the protocol contains every layer.
Furthermore, INVITE/200 (OK) exchange, the elements specified by two SIP are logical elements, user
agents have learned each other's IP address through the Contact
header fields, which was not
physical ones. A physical realization can choose to act as different
logical elements, perhaps even on a transaction by transaction basis. known when the initial INVITE was sent.
The lowest layer 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 protocol is its syntax sessions and encoding. Its
encoding is specified using a BNF. The complete BNF is specified in
Section 26. However, a basic overview of the structure end of a SIP
message can be found
the transaction. Full details on session setup are in Section 7. This section introduces enough of
an understanding of 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 message signaling messages.
During the session, either Alice or Bob may decide to facilitate
understanding change the remainder
characteristics of the protocol.
The next higher layer is the transport layer. media session. 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 accomplished by sending
a
client. All SIP elements contain re-INVITE containing a transport layer. The transport
layer is described in Section 19.
The next higher layer is new media description. If the transaction layer. Transactions are a
fundamental component of SIP. A transaction change is a request, sent
accepted by a
client transaction (using the transport layer), to other party, a server
transaction, along 200 (OK) is sent, which is itself
responded to with all responses to that request sent from an ACK. This re-INVITE references the
server transaction back to existing
dialog so the client. The transaction layer handles
retransmissions, matching of responses to requests, and timeouts. Any
task other party knows that a UAC wishes it is to accomplish takes place using a series modify an existing
session instead of
transactions. Discussion 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 transactions can be found 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 17.
User agents contain 14.
At the end of the call, Bob disconnects (hangs up) first, and
generates a transaction layer, as do stateful BYE message. This BYE is routed directly to Alice's
softphone, again bypassing the proxies.
Stateless proxies do not contain Alice confirms receipt of the
BYE with a transaction layer. 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 11] 9]
Internet Draft SIP October 26, 2001
The transaction layer has January 28, 2002
a client component (referred response to as a client
transaction), and a server component (referred an INVITE request. The reasons for this special
handling for INVITE will be discussed later, but relate to as a server
transaction), each the
reliability mechanisms in SIP, the length of which are represented by an FSM that time it can take for a
ringing phone to be answered, and forking. For this reason, request
handling in SIP is
constructed often classified as either INVITE or non- INVITE,
referring to process a particular request. The layer all other methods besides INVITE. Full details on top
session termination are in Section 15.
Full details of all the
transaction layer is called messages shown in the transaction user (TU), example of which there Figure 1 are several types. When a TU wishes to send a request, it creates a
client transaction instance and passes
shown in Section 26.2.
In some cases, it may be useful for proxies in the request, along with SIP signaling path
to see all the
destination IP address, port, and transport messaging between the endpoints for the duration of
the session. For example, if the biloxi.com proxy server wished to send
remain in the request to. SIP provides messaging path beyond the ability for a transaction initial INVITE, it would
add to be canceled by the
client which initiated it. When a client cancels INVITE a transaction, it
requests required routing header field known as Record-
Route that contained a URI resolving to the server give up on further processing, revert proxy. This information
would be received by both Bob's SIP phone and (due to the
state that existed before Record-
Route header field being passed back in the transaction was initiated, 200 (OK)) Alice's
softphone and generate
a specific error response 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 transaction. messaging will go through all proxies that elect
to receive it. This capability 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 frequently used for all methods.
These rules proxies that
are captured in Section 8. The primarily deal with
construction of a request, providing mid-call features.
Registration is another common operation in SIP. Registration is one
way that the case of a UAC, and processing biloxi.com server can learn the current location of
that request, Bob.
Upon initialization, and generation of at periodic intervals, Bob's SIP phone sends
REGISTER messages to a response, server in the case of biloxi.com domain known as a UAS.
UAC and UAS core behavior for the SIP
registrar. The REGISTER method messages associate Bob's SIP URI
(sip:bob@biloxi.com) with the machine he is described in
Section 10. Registrations play an important role currently logged in SIP. In fact, a
UAS that handles at
(conveyed as a REGISTER is given SIP URI in the Contact header). The registrar writes
this association, also called a special name - binding, to a registrar -
and it is described in that section.
UAC and UAS core behavior for database, called the OPTIONS method,
location service , where it can be used for
determining by the capabilities of a UAC, are described proxy in Section 11.
Certain other requests are sent within a dialog peer-to-peer SIP
relationship between the
biloxi.com domain. Often, a two user agents that persists registrar server for some time.
The dialog facilitates sequencing of messages between the user
agents, and proper routing of requests between both them. One way to
setup a dialog domain is co-
located with the INVITE method. When a UAC sends a request proxy for that domain. It is within an important concept
that the context distinction between types of SIP servers is logical, not
physical.
Bob is not limited to registering from a dialog, it follows single device. For example,
both his SIP phone at home and the common UAC
rules as discussed one in Section 8, but also the rules for mid-dialog
requests. Section 12 discusses dialogs, and presents office could send
registrations. This information is stored together in the procedures
for their construction, location
service and maintenance, in addition allows a proxy to construction perform various types of requests within a dialog.
The most important method in SIP is the INVITE method, which is used searches to establish
locate Bob. Similarly, more than one user can be registered on a session between participants. A session
single device at the same time.
The location service is a
collection of participants, and streams of media between them, for just an abstract concept. It generally
Various Authors [Page 12] 10]
Internet Draft SIP October 26, 2001 January 28, 2002
contains information that allows a proxy to input a URI and get back
a translated URI that tells the purposes of communication. Section 13 discusses how sessions proxy where to send the request.
Registrations are
initiated, resulting in one or more SIP dialogs. Section 14 discusses
how characteristics way to create this information, but not the
only way. Arbitrary mapping functions can be programmed, at the
discretion of that session are modified, through the use of
an INVITE request within a dialog. administrator.
Finally, section 15 discusses how
a session it is terminated.
The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
entirely with the UA 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 important to the roles
played by participants note that in SIP communications. The definitions of
client, server and proxy are similar to those SIP, registration is used by the Hypertext
Transport Protocol (HTTP) (RFC 2616 [8]). The terms
for routing incoming SIP requests and generic
syntax of URI has no role in authorizing
outgoing requests. Authorization and URL authentication are defined handled in RFC 2396 [9].
SIP either on a request-by-request, challenge/response mechanism, or
using a lower layer scheme as discussed in Section 22.
The following
terms have special significance complete set of SIP message details for SIP.
Back-to-Back user agent: A back-to-back user agent (B2BUA) this registration example
is a
logical entity that receives a request, and processes it in Section 26.1.
Additional operations in SIP, such as
a UAS. In order to determine how querying for the request should be
answered, it acts as capabilities
of a UAC and generates requests. Unlike SIP server or client using OPTIONS, canceling a
proxy server, it maintains dialog state, and must
participate pending request
using CANCEL, or supporting reliability of provisional responses
using PRACK will be introduced in all requests sent on later sections.
5 Structure of the dialogs it has
established. Since it Protocol
SIP is structured as a concatenation of a UAC and UAS,
no explicit definitions are needed for layered protocol, which means that its behavior.
Call: A call
behavior is an informal term that refers to described in terms of a dialog between
peers, generally set up for the purposes of fairly independent
processing stages with only a multimedia
conversation.
Call leg: Another name for a dialog.
Call stateful: A proxy loose coupling between each stage. The
protocol is call stateful if it retains state structured into layers for
a dialog from the initiating INVITE to the terminating BYE
request. A call stateful proxy is always stateful, but purpose of presentation
and conciseness; it allows the
converse is grouping of functions common across
elements into a single place. It does not true.
Client: A client is dictate an implementation
in any network element way. When we say that sends SIP requests,
and receives SIP responses. Clients may or may not interact
directly with an element "contains" a human user. User agent clients and proxies
are clients.
Conference: A multimedia session (see below) layer, we mean
it is compliant to the set of rules defined by that layer.
Not every element specified by the protocol contains
multiple participants.
Dialog: A dialog is a peer-to-peer every layer.
Furthermore, the elements specified by SIP relationship between are logical elements, not
physical ones. A physical realization can choose to act as different
logical elements, perhaps even on a
Various Authors [Page 13]
Internet Draft transaction-by-transaction basis.
The lowest layer of SIP October 26, 2001
UAC is its syntax and UAS that persists for some time. A dialog encoding. Its encoding is
established by SIP messages, such as
specified using a 2xx response to an
INVITE request. A dialog BNF. The complete BNF is identified by specified in Section 27.
However, a call
identifier, local address, and remote address. A dialog was
formerly known as basic overview of the structure of a call leg SIP message can be
found in RFC 2543.
Downstream: A direction Section 7. This section provides enough understanding of message forwarding within a
transaction which refers to the direction that requests
flow from the user agent client to user agent server.
Final response: A response that terminates
format of a SIP transaction, as
opposed message to a provisional response that does not. All 2xx,
3xx, 4xx, 5xx and 6xx responses are final.
Informational Response: Same as a provisional response.
Initiator, calling party, caller: The party initiating a session
with an INVITE request. A caller retains this role from the
time it sends the INVITE until facilitate understanding the termination remainder of any
dialogs established by
the INVITE.
Invitation: An INVITE request.
Invitee, invited user, called party, callee: protocol.
The party that
receives an INVITE request for next higher layer is the purposes of establishing transport layer. This layer defines how
a client takes 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.
Isomorphic request or response: Two requests are defined to be
isomorphic for the purposes of this document if they have
the same values for the Call-ID, To, From, CSeq, Request-
URI and physically sends it over the top-most Via header. Two responses are
isomorphic if they have the same values for the Call-ID,
To, From, CSeq network,
and top Via header. A message which is
isomorphic to another is also known as how a retransmission.
Location server: See location service.
Location service: A location service response is used sent by a SIP redirect
or proxy server to obtain information about and then received by a callee's
possible location(s). It is an abstract database, sometimes
referred to as client.
All SIP elements contain a location server. transport layer. The contents of the
database can be populated in many ways, including being
written by registrars.
Loop: A request that arrives at a proxy, transport layer is forwarded, and later
arrives back at the same proxy. When it arrives the second
described in Section 19.
Various Authors [Page 14] 11]
Internet Draft SIP October 26, 2001
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.
Method: January 28, 2002
The method next higher layer is the primary function that transaction layer. Transactions are a request
fundamental component of SIP. A transaction is
meant to invoke on a server. The method is carried in request, sent by a
client transaction (using the
request message itself. Example methods are INVITE and BYE.
Outbound proxy: A proxy that receives transport layer), to a server
transaction, along with all requests responses to that request sent from a
client, even though it is not the
server resolved by transaction back to the
Request-URI. client. The outbound proxy sends these requests, after
any local processing, transaction layer handles
application layer retransmissions, matching of responses to the address indicated in the
Request-URI, or 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 another outbound proxy.
Parallel search: In as a parallel search, client
transaction), and a proxy issues several
requests server component (referred to possible user locations upon receiving as a server
transaction), each of which are represented by an
incoming FSM that is
constructed to process a particular request. Rather than issuing one request and then
waiting for The layer on top of the final response before issuing
transaction layer is called the next
request as in transaction user (TU), of which there
are several types. When a sequential search , TU wishes to send a parallel search
issues requests without waiting for request, it creates a
client transaction instance and passes it the result of previous
requests.
Provisional response: request along with the
destination IP address, port, and transport to which to send the
request.
A response used by 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 indicate
progress, but the state that does not terminate existed before the
transaction was initiated, and generate a SIP transaction.
1xx responses are provisional, other responses are
considered final.
Proxy, proxy server: An intermediary entity specific error response to
that acts as both a
server and transaction. This is done with a client for CANCEL request, which
constitutes its own transaction, but references the purpose of making requests on
behalf transaction to be
cancelled. Cancellation is described in Section 9.
There are several different types of other clients. transaction users. A UAC
contains a UAC core, a UAS contains a UAS core, and a proxy server primarily plays to
role of routing, which means its job is to ensure that contains
a
request is passed proxy core. The behavior of the UAC and UAS cores depend largely on to another entity that can further
process
the request. Proxies method. However, there are also useful for enforcing
policy and some common rules for firewall traversal. A proxy interprets, and,
if necessary, rewrites parts 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 message before
forwarding it.
Registrar: A registrar 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 server
UAS that accepts handles a REGISTER
requests, is given a special name - a registrar -
and places the information it receives is described in those
requests into that section.
UAC and UAS core behavior for the location service OPTIONS method, used for
determining the domain it
handles.
Regular Transaction: capabilities of a UA, are described in Section 11.
Certain other requests are sent within a dialog. A regular transaction dialog is any transaction
with a method other than INVITE, ACK, or CANCEL.
peer-to-peer SIP relationship between two user agents that persists
Various Authors [Page 15] 12]
Internet Draft SIP October 26, 2001
Ringback: Ringback is January 28, 2002
for some time. The dialog facilitates sequencing of messages and
proper routing of requests between the signaling tone produced by user agents. The INVITE method
is the calling
party's application indicating that only way defined in this specification to establish a called party is being
alerted (ringing).
Server: A server is dialog.
When a network element UAC sends a request that receives requests is within the context of a dialog, it
follows the common UAC rules as discussed in
order to service them, Section 8, but also the
rules for mid-dialog requests. Section 12 discusses dialogs and sends back responses
presents the procedures for their construction, and maintenance, in
addition to those
requests. Examples construction of servers requests within a dialog.
The UAS core can generate provisional responses to requests, which
are proxies, user agent
servers, redirect servers, and registrars.
Sequential search: In 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 sequential search, method called PRACK, sent as a proxy server
attempts each contact address in sequence, proceeding to separate transaction
within the next one only after dialog between the previous has generated UAC and UAS, which is used to
acknowledge a non-
2xx final reliable provisional response.
Session: From
The most important method in SIP is the SDP specification: "A multimedia INVITE method, which is used
to establish a session between participants. A session is a
set
collection of multimedia senders and receivers participants, and the data streams flowing from senders to receivers. A multimedia
conference is an example of a multimedia session." (RFC
2327 [6]) (A session as defined media between them, for SDP can comprise
the purposes of communication. Section 13 discusses how sessions are
initiated, resulting in one or more RTP sessions.) As defined, a callee can be invited
several times, by different calls, to SIP dialogs. Section 14 discusses
how characteristics of that session are modified through the same session. If
SDP is used, use of
an INVITE request within a dialog. Finally, section 15 discusses how
a session is defined by the concatenation terminated.
The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
entirely with the user name , session id , network type , address type UA core (Section 9 describes cancellation, which
applies to both UA core and address elements in proxy core). Section 16 discusses the origin field.
(SIP) transaction: A SIP transaction occurs
proxy element, which facilitates routing of messages between user
agents.
6 Definitions
This specification uses a client and
a server and comprises all messages from the first request
sent from the client to the server up number of terms to a final (non-1xx)
response sent from the server refer to the client, roles
played by participants in SIP communications. The terms and the ACK
for the response generic
syntax of URI and URL are defined in the case the response was a 2xx. RFC 2396 [9]. The
ACK following
terms have special significance for a 2xx response is a separate transaction.
Spiral: SIP.
Back-to-Back user agent: A spiral back-to-back user agent (B2BUA) is a SIP request which is routed to
logical entity that receives a proxy,
forwarded onwards, request and arrives once again at that proxy,
but this time, differs in a way which will result in a
different processing decision than the original request.
Typically, this means that processes it has a Request-URI that
differs from the previous arrival. A spiral is not as
an error
condition, unlike a loop.
Stateless proxy: A logical entity that does not maintain the
client or user agent server transaction state machines defined in this
specification when it processes requests. A stateless proxy
forwards every (UAS). In order to determine how the
request should be answered, it receives downstream acts as an user agent client
(UAC) and every
response generates requests. Unlike a proxy server, it receives upstream.
Stateful proxy: A logical entity that
maintains dialog state and must participate in all requests
sent on the client dialogs it has established. Since it is a
concatenation of a UAC and
server transaction state machines defined by this UAS, no explicit definitions are
Various Authors [Page 16] 13]
Internet Draft SIP October 26, 2001
specification during January 28, 2002
needed for its behavior.
Call: A call is an informal term that refers to a dialog between
peers generally set up for the processing purposes of a request. Also
known as multimedia
conversation.
Call leg: Another name for a transaction dialog.
Call stateful: A proxy is call stateful proxy. The behavior of if it retains state for
a dialog from the initiating INVITE to the terminating BYE
request. A call stateful proxy is further defined in Section 16. always stateful, but the
converse is not true.
Client: A stateful
proxy client is any network element that sends SIP requests
and receives SIP responses. Clients may or may not the same as interact
directly with a call stateful proxy.
Transaction human user. User (TU): The layer of protocol processing agent clients and proxies
are clients.
Conference: A multimedia session (see below) that
resides above the transaction layer. Transaction users
include the contains
multiple participants.
Dialog: A dialog is a peer-to-peer SIP relationship between a
UAC core, and UAS core, 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 proxy core.
Upstream: remote address. A dialog
was formerly known as a call leg in RFC 2543.
Downstream: A direction of message forwarding within a
transaction
which that refers to the direction that responses requests flow
from the user agent server client to user agent client.
URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [10].
User agent client (UAC): server.
Final response: A user agent client is a logical entity response that creates terminates a new request, and then uses the client
transaction state machinery SIP transaction, as
opposed to send it. The role of UAC
lasts only for the duration of a provisional response that transaction. In other
words, if does not. All 2xx,
3xx, 4xx, 5xx and 6xx responses are final.
Header: A header is a piece component of software initiates a request, it acts sip message that conveys
information about the message. It is structured as a UAC for the duration of that transaction. If it
receives header
name, followed by a request later on, it takes on the role of colon, followed by its value.
Home Domain: The domain providing service to a User
Agent Server for SIP user.
Typically, this is the processing of that transaction.
UAC Core: The set of processing functions required domain present in the URI in the
address-of-record 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 registration.
Informational Response: Same as a response to 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, 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 response
accepts, rejects or redirects party that
receives an INVITE request for the request. This purposes of establishing
a new session. A callee retains this role lasts
only for from the duration time it
receives the INVITE until the termination of the dialog
established by that transaction. In other words,
if INVITE.
Location service: A location service is used by a piece of software responds SIP redirect
or proxy server to obtain information about a request, it acts as callee's
possible location(s). It contains a
UAS for the duration list of that transaction. If it generates 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 on,
arrives back at the same proxy. When it takes 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 role of a User agent
client request it made the first time around. Looped requests
are errors, and the procedures for detecting them and
handling them are described by the processing protocol.
Message: Data sent between SIP elements as part of that transaction.
UAS Core: the the
protocol. SIP messages are either requests or responses.
Method: The set of processing functions required at a UAS method is the primary function that
reside above a request is
meant to invoke on a server. The method is carried in the transaction
request message itself. Example methods are INVITE and transport layers.
User agent (UA): BYE.
Outbound proxy: A logical entity which can act as both proxy that receives all requests from a user
agent client and user agent
client, even though it is not the server for resolved by the duration of a
dialog.
Request-URI. The role of UAC and UAS as well as outbound proxy and redirect servers are
defined on a transaction-by-transaction basis. For example, sends these requests, after
any local processing, to the user
agent initiating address indicated in the
Request-URI, or to another outbound proxy. Typically, a call acts as UA
is manually configured with its outbound proxy, or can
learn it through auto-configuration protocols.
Parallel search: In a UAC when sending the initial INVITE 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 UAS when receiving sequential search , a BYE request from the callee. parallel search
Various Authors [Page 17] 15]
Internet Draft SIP October 26, 2001
Similarly, the same software can act as a proxy server for one
request and as a redirect server January 28, 2002
issues requests without waiting for the next request.
Proxy, location and registrar servers defined above are logical
entities; implementations MAY combine them into result of previous
requests.
Provisional response: A response used by the server to indicate
progress, but that does not terminate a single application
program.
7 SIP Messages 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 text-based protocol reliable provisional response
Proxy, proxy server: An intermediary entity that acts as both a
server and uses a client for the ISO 10646 character set in
UTF-8 encoding (RFC 2279 [11]). purpose of making requests on
behalf of other clients. A SIP message proxy server primarily plays the
role of routing, which means its job is either to ensure that a
request from is passed on to another entity "closer" to the
targeted user. Proxies are also useful for enforcing policy
(for example, making sure a client user is allowed to make a server, or
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 from when it generates
a server new request to a client.
Both Request (section 7.1) and Response (section 7.2) messages use the generic-message format of RFC 822 [12]. Both types of messages
consist of a start-line, one or more header fields (also known as
"headers"), an empty line indicating URIs in the end of Contact headers in the header fields,
and an optional message-body.
generic-message = start-line
*message-header
CRLF
[ message-body ]
The start-line, each message-header line, and
response.
Redirect Server: A redirect server is a server that generates
3xx responses to requests it receives, directing the empty line MUST be
terminated by client
to contact an alternate URI.
Registrar: A registrar is a carriage-return line-feed sequence (CRLF). Note server that accepts REGISTER
requests, and places the empty line MUST be present even if information it receives in those
requests into the message-body is not.
Except location service for the above difference in character sets, much of SIP's
message and header field syntax domain it
handles.
Regular Transaction: A regular transaction is identical to HTTP/1.1. Rather any transaction
with a method other than
repeating INVITE, ACK, or CANCEL.
Reliable Provisional Response: A provisional response that is
sent reliably from the syntax and semantics here we use [HX.Y] UAS to refer UAC.
Request: A SIP message sent from a client to
Section X.Y of a server, for the current HTTP/1.1 specification (RFC 2616 [8]).
Note, however, that SIP is not an extension
purpose of HTTP.
7.1 Requests invoking a particular operation.
Response: A SIP Requests are distinguished by having message sent from a Request-Line for server to a start-
line. A Request-Line begins with client, for
indicating the status of a method token, followed by request sent from the
Request-URI and client to
the protocol version, and ending with CRLF. The
elements are separated server.
Ringback: Ringback is the signaling tone produced by SP characters. No CR or LF are allowed
except in the end-of-line CRLF sequence. No LWS calling
party's application indicating that a called party is allowed in any of
the elements. being
Various Authors [Page 18] 16]
Internet Draft SIP October 26, 2001
Method Request-URI SIP-Version
o Method
This specification defines six methods : REGISTER for
registering contact information, INVITE, ACK and CANCEL for
setting up sessions, BYE for terminating sessions and OPTIONS
for querying servers about their capabilities. SIP extensions
may define additional methods.
o Request-URI
The Request-URI is January 28, 2002
alerted (ringing).
Route Refresh Request: A route refresh request sent within a SIP URL
dialog is defined as described in Section 21.1 or a
general URI (RFC 2396 [9]). 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 servers MAY support Request-URIs with schemes other than
"sip", for example that can modify the "tel" URI scheme route
set of RFC 2806 [13]. It
MAY translate non-SIP URIs using any mechanism at its
disposal, resulting in either a SIP URI or some other scheme.
o SIP Version
Both request and response messages include the version of SIP dialog.
Server: A server is a network element that receives requests 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,
order to service them and upgrading of version numbers. To
be compliant with this specification, applications sending SIP
messages MUST include a SIP- Version sends back responses to those
requests. Examples of "SIP/2.0". The string
is case-insensitive, but implementations MUST send upper-case.
Unlike HTTP/1.1, SIP treats the version number as a
literal string. In practice, this should make no
difference.
7.2 Responses
SIP Responses servers are distinguished by having a Status-Line for proxies, user agent
servers, redirect servers, and registrars.
Sequential search: In a start-
line. A Status-Line, consists of the protocol version followed by sequential search, a
numeric Status-Code and its associated textual phrase, with proxy server
attempts each
element separated by SP characters. No CR or LF is allowed except contact address in sequence, proceeding to
the final CRLF sequence.
SIP-version Status-Code Reason-Phrase
Various Authors [Page 19]
Internet Draft SIP October 26, 2001
The Status-Code is a 3-digit integer result code that indicates next one only after the
outcome of an attempt to understand and satisfy previous has generated a request. The
Reason-Phrase non-
2xx final response.
Session: From the SDP specification: "A multimedia session is intended to give a short textual description
set of multimedia senders and receivers and the
Status-Code. The Status-Code data
streams flowing from senders to receivers. A multimedia
conference is intended an example of a multimedia session." (RFC
2327 [5]) (A session as defined for use SDP can comprise one or
more RTP sessions.) As defined, a callee can be invited
several times, by automata, whereas different calls, to the Reason-Phrase same session. If
SDP is intended for the human user. A client used, a session is not
required to examine or display defined by the Reason-Phrase.
The first digit concatenation of
the Status-Code defines user name , session id , network type , address type ,
and address elements in the class of response.
The last two digits do not have any categorization role. For this
reason, any response with a status code origin field.
(SIP) transaction: A SIP transaction occurs between 100 and 199 is
referred to as a "1xx response", any response with a status code
between 200 client and 299 as
a "2xx response", server and so on. SIP/2.0 allows 6
values for comprises all messages from the first digit:
1xx: Informational -- request received, continuing to process
the request;
2xx: Success --
sent from the action was successfully received,
understood, and accepted;
3xx: Redirection -- further action needs to be taken in order client 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 up to fulfill an apparently
valid request;
6xx: Global Failure -- a final (non-1xx)
response sent from the request cannot be fulfilled at any
server.
Full definitions of these classes and each registered code appear in
Section 23.
7.3 Header Fields
SIP header fields are similar server to HTTP header fields in both syntax the client, and semantics. In particular, SIP header fields follow the [H4.2]
definitions of syntax ACK
for message-header, the rules for extending
header fields over multiple lines, response in the use of multiple message-header
fields with case the same field-name, 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 the rules regarding ordering of
header fields.
7.3.1 Header Field Format
Header fields follow the same generic header format as arrives once again at that given proxy,
but this time, differs in
Section 3.1 of RFC 822 [12]. Each header field consists of a field
Various Authors [Page 20]
Internet Draft SIP October 26, 2001
name followed by way that will result in a colon (":") and
different processing decision than the field value.
field-name: field-value
Note original request.
Typically, this means that the formal grammar for request's Request-URI
differs from its previous arrival. A spiral is not an error
condition, unlike a message-header specified in
Section 26 allow loop. A typical cause for an arbitrary amount of whitespace on either side
of the colon. No space before 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 colon and
example.com proxy. However, this is not a single space (SP)
between the colon and loop. Since the field-value
request is preferred. That is,
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
are all valid, targeted at a different user, it is considered a
spiral, and equivalent, but the last is a valid condition.
Various Authors [Page 17]
Internet Draft SIP January 28, 2002
Stateful proxy: A logical entity that maintains 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 client and
server transaction state machines defined by this
specification during the whitespace at the beginning processing of the next line are
treated a request. Also
known 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! transaction stateful proxy. The relative order behavior of header fields with different field names a
stateful proxy is not
significant. The relative order of those with the same field name further defined in Section 16. A stateful
proxy is
important. Multiple header fields with not the same field-name may be
present in as a message if and only if the entire field-value for that
header field is call stateful proxy.
Stateless proxy: A logical entity that does not maintain the
client or server transaction state machines defined as in this
specification when it processes requests. A stateless proxy
forwards every request it receives downstream and every
response it receives upstream.
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 comma-separated list (i.e., #(values)).
It MUST be possible transaction
that refers to combine the multiple header fields into one
"field-name: field-value" pair, without changing direction that responses flow from the semantics of
user agent server to user agent client.
URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [10].
User agent client (UAC): A user agent client is a logical entity
that creates a new request, and then uses the
message, by appending each subsequent field-value client
transaction state machinery to send it. The role of UAC
lasts only for the first, each
separated by duration of that transaction. In other
words, if a comma.
Implementations MUST be able to process multiple header fields with piece of software initiates a request, it acts
as a UAC for the same name in any combination duration of that transaction. If it
receives a request later on, it assumes the single-value-per-line or
comma-separated value forms. role of a user
agent server for the processing of that transaction.
UAC Core: The following blocks set of headers are valid and equivalent:
Route: sip:alice@atlanta.com
Subject: Lunch
Route: sip:bob@biloxi.com
Route: sip:carol@chicago.com
Various Authors [Page 21]
Internet Draft SIP October 26, 2001
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 processing functions required of a UAC that
reside above the following blocks transaction and transport layers.
User agent server (UAS): A user agent server is valid but not equivalent a logical entity
that generates a response 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, SIP request. The response
accepts, rejects or a
combination redirects the request. This role lasts
only for the duration of whitespace, tokens, separators, and quoted strings.
Many that transaction. In other words,
if a piece of them will adhere software responds to a request, it acts as a
UAS for the general form duration of that transaction. If it generates a value followed by a
semi-colon separated sequence
request later on, it assumes the role of parameter-name, parameter-value
pairs:
field-name: field-value *(;parameter-name=parameter-value)
When comparing headers, field names are always case-insensitive.
Unless otherwise stated in a user agent
client for the definition processing of that transaction.
UAS Core: The set of processing functions required at a particular header
field, field values, parameter names, UAS that
reside above the transaction and parameter values (tokens in
general) are case-insensitive. Unless specified otherwise, values
expressed as quoted strings are case-sensitive.
The following are equivalent:
Contact: <sip:alice@atlanta.com>;expires=3600
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
Contact-Disposition: session;handling=optional
contact-disposition: Session;HANDLING=OPTIONAL transport layers.
Various Authors [Page 22] 18]
Internet Draft SIP October 26, 2001
The following are not equivalent;
Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE January 28, 2002
User agent (UA): 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. Those header fields logical entity that can appear in either act as both a
request or response 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 called General Header Fields. If
defined on a header
appears in transaction-by-transaction basis. For example, the user
agent initiating a message not matching its category (such call acts as a UAC when sending the initial INVITE
request
header in and as a response), it MUST be ignored. Section 22 defines UAS when receiving a BYE request from the
classification of each header.
7.3.3 Compact Form 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 provides Messages
SIP is a mechanism to represent common header fields text-based protocol and uses the ISO 10646 character set in an
abbreviated form. This may be useful when messages would otherwise
become
UTF-8 encoding (RFC 2279 [11]).
A SIP message is either a request from a client to large a server, or a
response from a server to be carried on a client.
Both Request (section 7.1) and Response (section 7.2) messages use
the transport available to it
(exceeding basic format of RFC 2822 [7], even though the MTU when using UDP for example). These compact forms
are defined syntax differs in Section 22. A compact form MAY
character set and syntax specifics. (SIP allows header fields that
would not be substituted valid RFC 2822 header fields, for the
longer form example.) Both types
of a header name at any time without changing the
semantics messages consist of a the message. Multiple start-line, one or more header fields in a message with
the same header name MAY appear with (also
known as "headers"), an arbitrary mix of its long and
short field name form. Implementations MUST accept both empty line indicating the long and
short forms end of each header name.
7.4 Bodies
Requests, including new requests defined in extensions to this
specification, MAY contain message bodies unless otherwise noted.
For response messages, the request method and the response status
code determine the type header
fields, and interpretation of any message body. All
responses MAY include a body.
7.4.1 Message Body Type an optional message-body.
generic-message = start-line
*message-header
CRLF
[ message-body ]
The Internet media type of start-line, each message-header line, and the message body empty line MUST be given
terminated by a carriage-return line-feed sequence (CRLF). Note that
the
Content-Type header field. If the body has undergone any encoding
(such as compression) then this empty line MUST be indicated by present even if the Content-
Encoding header field, otherwise Content-Encoding MUST be omitted. If
applicable, message-body is not.
Except for the above difference in character set sets, much of the SIP's
message body and header field syntax is indicated as
part 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 Content-Type header-field value. current HTTP/1.1 specification (RFC 2616 [12]).
However, SIP is not an extension of HTTP.
Various Authors [Page 23] 19]
Internet Draft SIP October 26, 2001
The "multipart" MIME type defined in RFC 2046 [14] MAY be used within
the body of the message.
Implementations that send January 28, 2002
7.1 Requests
SIP requests containing multipart message
bodies MUST be able to send are distinguished by having a session description as Request-Line for a non-multipart
message body if start-
line. A Request-Line contains a method name, a Request-URI, and the remote implementation requests this through an
Accept header field.
7.4.2 Message Body Length
protocol version separated by a single space (SP) character. The body length
Request-Line ends with CRLF. No CR or LF are allowed except in bytes the
end-of-line CRLF sequence. No LWS is provided by allowed in any of the Content-Length header
field. 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 22.14 describes 23.1 or a general URI (RFC 2396 [9]). It indicates
the necessary contents of user or service to which this header
in detail. request is being
addressed. The "chunked" transfer encoding of HTTP/1.1 Request-URI MUST NOT contain unescaped
spaces or control characters and MUST NOT be used enclosed in
"<>".
SIP elements MAY support Request-URIs with schemes other
than "sip", for SIP.
(Note: The chunked encoding modifies example the body "tel" URI scheme of a message RFC 2806
[13]. SIP elements MAY translate non-SIP URIs using any
mechanism at their disposal, resulting in order
to transfer it as either a series of chunks, each with its own size
indicator.)
7.5 Framing SIP messages
Unlike HTTP, SIP MAY use UDP URI
or some other unreliable datagram protocols.
Each such datagram carries one scheme.
SIP-Version: Both request or response. Datagrams,
including all headers, SHOULD NOT be larger than the path maximum
transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU
is unknown. However, implementations MUST be able to handle and response messages
up to the maximum datagram packet size. For UDP, this size is 65,535
bytes, including headers.
The MTU of 1500 bytes accommodates encapsulation within include the
"typical" ethernet MTU without IP fragmentation. Recent
studies [15] indicate that an MTU
version of 1500 bytes is a
reasonable assumption. The next lower common MTU values are
1006 bytes for SLIP SIP in use, and 296 for low-delay PPP (RFC 1191
[16]). Thus, another reasonable value would be a message
size of 950 bytes, to accommodate packet headers within the
SLIP MTU without fragmentation.
In the interest 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 robustness, any leading empty line(s) MUST version numbers. To be
ignored. In other words, if the Request or Response message begins compliant with one or more CRLF, CR, or LFs, these characters MUST be ignored.
Likewise, Implementations processing this
specification, applications sending SIP messages over stream
oriented transports MUST ignore noise between messages.
8 General User Agent Behavior
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 24] 20]
Internet Draft SIP October 26, 2001
A user agent represents an end system. It contains January 28, 2002
SIP responses are distinguished from requests by having a User Agent
Client (UAC), which generates requests, and a User Agent Server (UAS)
which responds to them. Status-Line
as their start-line. A UAC is capable Status-Line consists of generating a request
based on some external stimulus (the user clicking a button, or a
signal on the protocol version
followed by a PSTN line), numeric Status-Code and processing its associated textual phrase,
with each element separated by a response. A UAS single SP character. No CR or LF is capable
of receiving a request, and generating response, based on user input,
external stimulus,
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 program execution, or some other
mechanism.
When a UAC sends request. The
Reason-Phrase is intended to give a request, it will pass through some number short textual description of proxy
servers, which forward the request towards the UAS. When the UAS
generates a response, the response
Status-Code. The Status-Code is forwarded towards intended for use by automata, whereas
the UAC.
UAC and UAS procedures depend strongly on two factors. First, whether Reason-Phrase is intended for the request or response human user. A client is inside not
required to examine or outside of a dialog, and second,
based on display 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 Reason-Phrase. While this section, we discuss the method independent rules
specification suggests specific wording for UAC and
UAS behavior when processing of requests that are outside of a
dialog. This includes, of course, the requests which themselves
establish a dialog.
8.1 UAC Behavior
8.1.1 Generating the Request
A valid SIP request formulated by a UAC MUST at a minimum contain reason phrase,
implementations MAY choose other text, e.g., in the
following headers: To, From, CSeq, Call-ID, and Via; all of these
headers are mandatory language
indicated in all SIP messages. These five headers are the
fundamental building blocks of a SIP message, as they jointly provide
for most Accept-Language header field of the critical message routing services including the
addressing request.
The first digit of messages, the routing of responses, ordering of
messages, and Status-Code defines the unique identification of transactions.
Examples of requests send outside class of response. The
last two digits do not have any categorization role. For this reason,
any response with a dialog include an INVITE status code between 100 and 199 is referred to
establish as
a session (Section 13) "1xx response", any response with a status code between 200 and an OPTIONS to query for
capabilities (Section 11).
8.1.1.1 To
The To general-header field first 299
as a "2xx response", and foremost specifies so on. SIP/2.0 allows six values for the desired
"logical" recipient of
first digit:
1xx: Provisional -- request received, continuing to process the request, or
request;
2xx: Success -- the address of record of action was successfully received,
understood, and accepted;
3xx: Redirection -- further action needs to be taken in order to
complete the
user or resource that is request;
4xx: Client Error -- the target of this request. This may request contains bad syntax or may
not cannot
be fulfilled at this server;
5xx: Server Error -- the ultimate recipient of the request. The To header MAY
contain a SIP URI, but it may also make use of other URI schemes (for
example as server failed to fulfill an apparently
valid request;
6xx: Global Failure -- the tel URL [13]) when appropriate. The To request cannot be fulfilled at any
server.
Section 25 defines these classes and describes the individual codes.
7.3 Header Fields
SIP header field fields are similar to HTTP header fields in both syntax
Various Authors [Page 25] 21]
Internet Draft SIP October 26, 2001
allows January 28, 2002
and semantics. In particular, SIP header fields follow the [H4.2]
definitions of syntax for a display name; this is meant to contain a descriptive
version message-header, the rules for extending
header fields over multiple lines, the use of multiple message-header
fields with the URI, same field-name, and is intended to be displayed to a user
interface.
A UAC may learn how to populate the To rules regarding ordering of
header field for a particular
request fields.
7.3.1 Header Field Format
Header fields follow the same generic header format as that given in a number
Section 2.2 of ways. Usually the user will suggest the To RFC 2822 [7]. Each header field through a human interface, perhaps inputting the URI
manually or selecting it from some sort of address book.
A request outside consists of a dialog MUST NOT contain field
name followed by a tag; colon (":") and the tag 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
To field of
name and the colon and use a request identifies single space (SP) between the peer of colon and
the dialog. Since no
dialog is established, no tag is present.
For further information on field-value. Thus,
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
are all valid and equivalent, but the To header see Section 22.37.
The following last is an example of valid To header:
To: Carol <sip:carol@chicago.com>
8.1.1.2 From 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 From general-header field indicates line
break and the logical identity of whitespace at the
initiator beginning of the request, possibly next line are
treated as a single SP character. Thus, the user's address of record. Like following are equivalent:
Subject: I know you're there, pick up the To field, it contains a URI phone and optionally a display name. It is
used by SIP elements to determine processing rules talk to apply me!
Subject: I know you're there,
pick up the phone
and talk to a
request (for example, automatic call rejection). As such, me!
The relative order of header fields with different field names is not
significant. However, it is very
important RECOMMENDED that the URI not contain IP addresses or host names, since
these headers which are not logical names.
The From header field allows
needed for a display name; this is meant to
contain a descriptive version of the URI, proxy processing (Via, Route, Record-Route, Proxy-Require,
Max-Forwards, and is intended to be
displayed to a user interface. A UAC SHOULD use the display name
"Anonymous" if Proxy-Authorization, for example) appear towards
the identity top of the client is message, to remain hidden.
Usually the value that populates the From facilitate rapid parsing. The relative
order of header fields with the same field in requests
generated by a particular user agent name is pre-provisioned by the user
or by the administrators of important.
Multiple header fields with the user's local domain. If a particular
user agent is used by multiple users, it might have switchable
profiles that include same field-name MAY be present in a URI corresponding to the identity of the
profiled user. Recipients of requests can authenticate
message if and only if the originator
of a request in order to ascertain entire field-value for that they are who their From header field claims they are (see Section 20.2 for more on
authentication).
The From field MUST contain a new "tag" parameter, chosen by the UAC.
See Section 21.3 for details on choosing
is defined as a tag. comma-separated list (that is, #(values)). It MUST be
Various Authors [Page 26] 22]
Internet Draft SIP October 26, 2001
For further information on January 28, 2002
possible to combine the From multiple header see Section 22.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.3 Call-ID
The Call-ID general-header field acts as a unique identifier to group
together series fields into one "field-name:
field-value" pair, without changing the semantics of messages. It is always the same for all requests
and responses sent message, by either UA in a dialog. It is also
appending each subsequent field-value to the same in first, each registration from a UA within a single boot cycle.
In a new request created separated by
a UAC outside of any dialog, unless
overridden by method specific behavior, it comma.
Implementations MUST be selected by the
UAC as a a globally unique identifier over space and time; all SIP
user agents must have a means able to guarantee that process multiple header fields with
the Call-ID headers
they produce will not be inadvertently generated by same name in any other user
agent.
Use combination of cryptographically random identifiers [17] in the generation single-value-per-line or
comma-separated value forms.
The following groups of
Call-IDs is RECOMMENDED. Implementations MAY use the form
"localid@host". Call-IDs are case-sensitive and header fields are simply compared
byte-by-byte.
Using cryptographically random identifiers provides some
protection against session hijacking, valid and reduces the
likelihood 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 unintentional Call-ID collisions.
No provisioning or human interface the following blocks is required for valid but not equivalent to the selection
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
the Call-ID a header field value for field-value is defined per header-name. It
will always be either an opaque sequence of TEXT-UTF8 octets, or a request.
For further information on
combination of whitespace, tokens, separators, and quoted strings.
Many existing headers will adhere to the Call-ID header see Section 22.8.
Example:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
8.1.1.4 CSeq 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 27] 23]
Internet Draft SIP October 26, 2001
The Cseq header serves as a way to identify and order transactions.
It consists of a sequence January 28, 2002
Even though an arbitrary number and a method. The method MUST match
that of the request. The sequence number value is arbitrary, but MUST parameter pairs may be expressible as attached to
a 32-bit unsigned integer and header field value, any given parameter-name MUST be less NOT appear more
than
2**31.
As long as it follows once.
All new header fields MUST follow this generic format unless they
have been inherited from other RFC 2822-like specifications.
When comparing header fields, field names are always case-
insensitive. Unless otherwise stated in the above guidelines, definition of a client may use any
mechanism it would like to select CSeq
particular header field, field values. 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 further information on the CSeq header see Section 22.16.
Example:
CSeq: 4711 INVITE
8.1.1.5 Via
The Via header example,
Contact: <sip:alice@atlanta.com>;expires=3600
is used to determine the transport equivalent to use for sending
a request, and for identifying the IP address
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
and port where the
response
Content-Disposition: session;handling=optional
is equivalent to be sent. Rules for setting
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 using the values response header fields,
respectively. If a header appears in
this a message not matching its
category (such as a request header are described field in a response), it MUST be
Various Authors [Page 24]
Internet Draft SIP January 28, 2002
ignored. Section 19.
For further information on 24 defines the Via header see Section 22.40.
8.1.1.6 Contact
The Contact classification of each header field.
7.3.3 Compact Form
SIP provides a SIP URI that can mechanism to represent common header fields in an
abbreviated form. This may be used useful when messages would otherwise
become too large to contact
that specific instance of be carried on the user agent transport available to it
(exceeding the maximum transmission unit (MTU) when using UDP, for subsequent requests. The
Contact header MUST be present in any request that can result
example). These compact forms are defined in Section 24. A compact
form MAY be substituted for the
establishment longer form of a dialog. For header name at any
time without changing the methods 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, that includes only the INVITE request. For these
requests, the scope MAY contain message bodies unless otherwise noted.
The interpretation of the Contact is body depends on the dialog. That is, request method.
For response messages, the
Contact header refers to request method and the URL that response status
code determine the UA would like to receive
requests at, for requests that are part type and interpretation of that dialog only. Only any message body. All
responses MAY include a
single URI MUST be present.
For further information on the Contact header, see Section 22.10.
8.1.1.7 Request-URI body.
7.4.1 Message Body Type
The initial Request-URI Internet media type of the message SHOULD body MUST be set to the value of
the URI in given by the To
Content-Type header field. One notable exception is If the REGISTER
method; behavior for setting body has undergone any encoding
such as compression, then this MUST be indicated by the Request-URI Content-
Encoding header field; otherwise, Content-Encoding MUST be omitted.
If applicable, the character set of register the message body is given indicated as
part of the Content-Type header-field value.
The "multipart" MIME type defined in
Section 10. Another exception is RFC 2046 [14] MAY be used within
the case body of pre-existing Route
headers; in the message. Implementations that case, send requests
containing multipart message bodies MUST send a session description
as a non-multipart message body if the procedures of 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 12.2.1.1 as they 24.14 describes the necessary contents of this header
in detail.
Various Authors [Page 28] 25]
Internet Draft SIP October 26, 2001
pertain to the Request- URI are followed, even though there is no
dialog.
8.1.1.8 Supported and Require
If the UAC supports extensions to SIP that can January 28, 2002
The "chunked" transfer encoding of HTTP/1.1 MUST NOT be applied by the
server to the response, the UAC SHOULD include a Supported header in
the request listing the option tags used for those extensions. SIP.
(Note: 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 chunked encoding modifies the body of a message in order
to
receive service. Extensions defined by experimental and informational
RFCs are explicitly excluded from usage transfer it as a series of chunks, each with its own size
indicator.)
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 Supported header in start-
line [H4.1]
8 General User Agent Behavior
A user agent represents an end system. It contains a request, since they too are often used User Agent
Client (UAC), which generates requests, and a User Agent Server (UAS)
which responds to document vendor defined
extensions.
If the them. A UAC wishes to insist that 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 understand an extension that 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 apply to pass through some number of proxy
servers, which forward the request in order to process towards the request, it
MUST insert a Require header into UAS. When the request listing UAS
generates a response, the option tag
for that extension. If response is forwarded towards the UAC.
UAC wishes to apply an extension to the
request and insist that a proxy understand that extension, it MUST
insert a Proxy-Require header into UAS procedures depend strongly on two factors. First, whether
the request listing the option tag
for that extension.
8.1.1.9 Additional Message Components
After or response is inside or outside of a new request has been created, dialog, and second,
based on the headers described above
have been properly constructed, any additional optional headers method of a request. Dialogs are
added, as discussed thoroughly in
Section 12; they represent a peer-to-peer relationship between user
agents, and are any headers established by specific to the method. SIP requests MAY contain a MIME-encoded message-body. Regardless of methods, such as INVITE.
In this section, we discuss the type of body method independent rules for UAC and
UAS behavior when processing requests that are outside of a request contains, certain headers must be
formulated to characterize the contents dialog.
This includes, of course, the body. For further
information on these headers see Section 7.4.
8.1.2 Sending the Request
The destination for the request is then computed. This can be requests which themselves establish a
preconfigured IP address, port
dialog.
Security procedures for requests and transport responses outside of an outbound proxy, or
it can be determined through DNS procedures applied to the Request-
URI. These procedures a dialog
are described in Section 24, which yield an
ordered set of address, port and transports to attempt. The UAC
SHOULD follow the procedures defined there 22. Specifically, mechanisms exist for stateful elements,
trying each address until a server is contacted. Each try constitutes
a new transaction, the
UAS and therefore a new client transaction MUST be
constructed for each. UAC to mutually authenticate. A limited set of privacy
features are also supported through encryption of bodies using
S/MIME.
Various Authors [Page 29] 26]
Internet Draft SIP October 26, 2001
8.1.3 Processing Responses
Responses are first processed by the transport layer, and then passed
up to the transaction layer. The transaction layer performs its
processing, and then passes it up to the TU. The majority of response
processing in the TU is method specific. However, there are some
general behaviors independent January 28, 2002
8.1 UAC Behavior
This section covers UAC behavior outside of a dialog.
8.1.1 Generating the method.
8.1.3.1 Unrecognized Responses Request
A valid SIP request formulated by a UAC MUST treat any response they do not recognize as being
equivalent to at a minimum contain the x00 response code of that class,
following headers: To, From, CSeq, Call-ID, Max-Forwards, and MUST be able
to process the x00 response code for Via;
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.
8.1.3.2 Vias
If more than one Via header field is present these headers are mandatory in all SIP messages. These six
headers are the fundamental building blocks of a response, SIP message, as they
jointly provide for most of the UAC
SHOULD discard critical message routing services
including the message.
The presence addressing of additional Via header fields that precede messages, the originator routing of the request suggests that the responses,
limiting message was
misrouted or possibly corrupted.
8.1.3.3 Processing 3xx responses
Upon receipt propagation, ordering of a redirection response (e.g. a 3xx response status
code), clients SHOULD use messages, and the URI(s) unique
identification of transactions. These headers are in the Contact header field addition to
formulate a new request.
To do that, the client copies all but
mandatory request line, which contains the "method-param" method, Request-URI and "header"
elements of the addr-spec part
SIP version.
Examples of the Contact header field into the
Request-URI requests sent outside of the request. It uses the "header" parameters a dialog include an INVITE to create
headers
establish a session (Section 13) and an OPTIONS to query for the request, replacing any default headers normally used.
In all other respects, requests sent upon receipt
capabilities (Section 11).
8.1.1.1 Request-URI
The initial Request-URI of a redirect
response the message SHOULD re-use be set to the headers and bodies value of
the original
request.
The Contact values present URI in redirection responses SHOULD NOT be
cached across calls, as they may not represent the most desirable
location To field. One notable exception is the REGISTER
method; behavior for a particular destination address.
8.1.3.4 Processing 4xx responses
Certain 4xx response codes require specific UA processing,
Various Authors [Page 30]
Internet Draft SIP October 26, 2001
independent of setting the method.
If a 401 or 407 response Request-URI of register is given in
Section 10.
Another exception is received, the UAC SHOULD follow case of pre-existing Route headers; in that
case, the
authorization procedures of Section 20.2.2 and Section 20.2.3 12.2.1.1 as they pertain to
retry the request with credentials.
If a 413 response
Request-URI are followed, even though there is received (Section 23.4.11), it means no dialog. Pre-
existing Route headers are an ordered set of URIs that the
request contained identify a body that was longer than the UAS was willing
chain of servers to
accept. If possible, the which outgoing requests from a UAC SHOULD retry the request, either
omitting will be sent.
Commonly, they are configured on the body user agent by a user or using one of service
provider manually, or through some non-SIP mechanism. They are most
often used to identify a smaller length.
If local outbound proxy server through which a 415 response is received (Section 23.4.13), it means 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 will send all requests, which in the response.
If a 420 response is received (Section 23.4.14), it means the request
contained turn allows service providers to
maintain a Require or Proxy-Require header listing an option-tag common point of policy enforcement for
a feature not supported by a proxy or UAS. requests.
8.1.1.2 To
The UAC SHOULD retry the
request, this time omitting any extensions listed in the Unsupported
header in To general-header field first and foremost specifies the response.
In all desired
"logical" recipient of the above cases, retrying the request is accomplished by
creating a new request with the appropriate modifications. This new
request SHOULD have request, or the same value address of the Call-ID, To, and From record of the previous request, but the CSeq should contain a new sequence
number
user or resource that is one higher than the previous.
With other 4xx responses, a retry target of this request. This may or may
not be possible
depending on the method and the use case.
8.2 UAS Behavior
When a request outside of a dialog is processed by a UAS, there are a
set of processing rules which are followed, independent ultimate recipient of the
method. Section 12 gives guidance on how a UAS can tell whether a
request is inside or outside of a dialog.
8.2.1 Authentication/Authorization
A UAS request. The To header MAY authenticate the originator of
contain a request, and this process SIP URI, but it may require the server to issue a challenge for credentials. The
required behavior is independent of the method also make use of other URI schemes (the
tel URL [13], for example) when appropriate. All SIP implementations
MUST support the request, and is
detailed in Section 20.2.
8.2.2 Method Inspection SIP URI. The To header field allows for a display
Various Authors [Page 31] 27]
Internet Draft SIP October 26, 2001
Once January 28, 2002
name.
A UAC may learn how to populate the To header field for a particular
request is authenticated (or no authentication was desired), in a number of ways. Usually the UAS MUST inspect user will suggest the method of To
header field through a human interface, perhaps inputting the request. If URI
manually or selecting it from some sort of address book. Frequently,
the UAS does user will not
support enter a complete URI, but rather, a string of
digits or letters (i.e., "bob"). It is at the method discretion of a request the UA to
choose how to interpret this input. Using it MUST generate to form the user part of
a 405 (Method Not
Allowed) response. Procedures for generation SIP URL implies that the UA wishes the name to be resolved in the
domain the right hand side (RHS) of responses are
described the at-sign in Section 8.2.7. The UAS MUST also add an Allow header to the 405 response. SIP URI (i.e.,
sip:bob@example.com). The Allow header field MUST list RHS will frequently be the set home domain of methods
supported by
the UAS generating user, which allows for the message.
The Allow header home domain to process the outgoing
request. This is presented useful for features like "speed dial" which require
interpretation of the user part in Section 22.5.
If the method home domain. The tel URL is one supported by
used when the server, processing continues.
8.2.3 Header Inspection
If a UAS UA does not understand 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 header field user in an
airport might log in, and send requests through an outbound proxy in a request (i.e.
the
header airport. If they enter "411" (this is not defined in this specification or the phone number for local
directory assistance in any supported
extension), the server MUST ignore United States), that header needs to be
interpreted and continue
processing processed by the message. A UAS SHOULD ignore any malformed headers
which are outbound proxy in the airport, not necessary for processing requests.
8.2.3.1 To and Request-URI
The
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 header field of a request identifies the original recipient peer of the request
designated by the user identified in dialog. Since no
dialog is established, no tag is present.
For further information on the To header see Section 24.41.
The following is an example of valid To header:
To: Carol <sip:carol@chicago.com>
8.1.1.3 From field.
The original
recipient may or may not be From general-header field indicates the UAS processing logical identity of the request, do to
call forwarding or other proxy operations. A UAS MAY apply any policy
it wishes in determination
initiator of whether to accept requests when the To
field is not request, possibly the identity user's address of record. Like
the UAS. However, To field, it is RECOMMENDED that contains a UAS accept requests even if they do not recognize the URI scheme
(e.g., a tel: URI) in the To header, or if the To header does not
address and optionally a known or current user of this UAS. If, on the other hand,
the UAS decides display name. It is
used by SIP elements to determine processing rules to apply to reject the request, it SHOULD generate a response
with a 403 status code and send
request (for example, automatic call rejection). As such, it to the server transaction for
transmission.
However, the Request-URI identifies the UAS that is to process the
request. If the Request-URI does not identify an address very
important that the UAS
is willing to accept requests for, it SHOULD reject From URI not contain IP addresses or the request with
a 404 (Not Found) response. If FQDN of
the Request-URI does not provide
sufficient information for host the UAS to determine whether it UA is willing
to process the request, it SHOULD return a 485 (Ambiguous) response.
This response SHOULD contain a Contact running on, since these are not logical names.
The From header field containing URIs
of new addresses to be tried.
Typically, allows for a UA which uses display name. A UAC SHOULD use the REGISTER method to bind its address of
record to a specific contact address, will see requests whose
Request-URI equals those contact addresses.
Various Authors [Page 32] 28]
Internet Draft SIP October 26, 2001
8.2.3.2 Require
Assuming January 28, 2002
display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:988776a@ahhs.aa), if the UAS decides that it is identity
of the proper element client is to process remain hidden.
Usually the
request, it examines value that populates the Require From header field, if present.
The Require general-header field in requests
generated by a particular user agent is used pre-provisioned by UAC to tell UAS about SIP
extensions that the UAC expects user
or by the UAS to support in order to
properly process administrators of the request. user's local domain. If a UAS does not understand an option
listed in a Require header field, it MUST respond particular
user agent is used by generating a
response with status code 420 (Bad Extension). The UAS MUST add a
Unsupported, and list in it those options multiple users, it does not understand
amongst those in might have switchable
profiles that include a URI corresponding to the Require header identity of the request. Upon receipt
profiled user. Recipients of requests can authenticate the 420 the client SHOULD retry the request, this time without using
those extensions listed in the Unsupported header originator
of a request in the response.
Example:
UACC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: com.example.billing
Payment: sheep_skins, conch_shells
UASS->UAC: SIP/2.0 420 Bad Extension
Unsupported: com.example.billing
This is order to make sure ascertain that the client-server interaction
will proceed without delay when all options they are understood
by both sides, and only slow down if options who their From
header field claims they are not
understood (as in the example above). For a well-matched
client-server pair, the interaction proceeds quickly,
saving (see Section 20 for more on
authentication).
The From field MUST contain a round-trip often required new "tag" parameter, chosen 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.4 Content Processing
Assuming UAC.
See Section 23.3 for details on choosing a tag.
For further information on the UAS understands any extensions required by the client,
the UAS examines the body 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 message, same for all requests
and responses sent by either UA in a dialog. It SHOULD be the headers that
describe it. If there are any bodies whose type (indicated same in
each registration from a UA.
In a new request created by a UAC outside of any dialog, the
Content-Type), language (indicated Call-ID
header MUST be selected by the Content-Language) or
encoding (indicated 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 Content-Encoding) 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 understood, considered new requests, and
that body part is therefore do not optional (as indicated by the Content-
Disposition) header, need new Call-ID
headers; see Section 8.1.4.6.
Use of cryptographically random identifiers [15] in the UAS MUST reject generation of
Call-IDs is RECOMMENDED. Implementations MAY use the request with a 415
(Unsupported Media Type) response. The response MUST contain a Accept form
Various Authors [Page 33] 29]
Internet Draft SIP October 26, 2001
header listing 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 types
likelihood of all bodies it understands, in the event unintentional Call-ID collisions.
No provisioning or human interface is required for the request contained bodies selection 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
with languages not understood by the UAS, the response MUST contain
an Accept-Language Call-ID header indicating the languages understood by the
UAS.
Beyond these checks, body handling is method and type specific. field value for a request.
For further information on the processing of Content-specific headers Call-ID header see Section 7.4.
8.2.5 Applying Extensions
A UAS that wishes 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 apply some extension when generating the
response identify and order transactions.
It consists of a sequence number and a method. The method MUST only do so if support for match
that extension is indicated
in the Supported header in of the request. If For requests outside of a dialog, the desired extension sequence
number value is
not supported, the server SHOULD rely only on baseline SIP arbitrary, but MUST be expressible as a 32-bit
unsigned integer and any
other extensions supported by the client. To ensure that the SHOULD
can MUST be fulfilled, less than 2**31. As long as it follows
the above guidelines, a client may use any specification mechanism it would like to
select CSeq header field values.
Section 12.2.1.1 discusses construction of the CSeq for requests
within a new extension MUST include
discussion of how to gracefully return dialog.
Example:
CSeq: 4711 INVITE
8.1.1.6 Max-Forwards
The Max-Forwards header serves to baseline SIP when the
extension is not present. In rare circumstances, where the server
cannot process limit the number of hops a request without the extension,
can transit on the server MAY send
a 421 (Extension Required) response. This response indicates way to its destination. It consists of an integer
that is decremented by one at each hop. If the
proper response cannot be generated without support of a specific
extension. The needed extension(s) MUST be included in a Require
header in Max-Forwards value
reaches 0 before the response. This behavior is NOT RECOMMENDED, as request reaches its destination, it will
generally break interoperability.
Any extensions applied to a non-421 response MUST be listed in
rejected with a
Require header included in the 483 Too Many Hops error response. Of course, the server
A UAC MUST
NOT apply extensions not listed in the Supported header in the
request. As insert a result of this, the Require Max-Forwards header in a response will
only ever contain option tags defined in standards track RFCs.
8.2.6 Processing the Request
Assuming all of the checks in the previous subsections are passed,
the UAS processing becomes method specific. Section 10 deals with the
REGISTER request, section 11 deals with the OPTIONS request, section
13 deals with the INVITE request, and section 15 deals with the BYE
request.
8.2.7 Generating the Response
When a UAS wishes to construct a response to a request, field into each request it follows
Various Authors [Page 34] 30]
Internet Draft SIP October 26, 2001
these procedures. Additional procedures may be needed depending on
the status code of the response and the circumstances January 28, 2002
originates with a value of its
construction. These additional procedures are documented elsewhere. 70.
8.1.1.7 Via
The From field of Via header is used to indicate the response MUST equal transport used for the From field of
transaction, and to identify the
request. The Call-ID field of location where the response MUST equal the Call-ID
field of is to be
sent.
When the UAC creates a request, it MUST insert a Via into that
request. The Cseq field of protocol and version in the response header MUST equal the
Cseq field of the request. be SIP and 2.0,
respectively. The Via headers in the response header it inserts MUST equal contain a branch
parameter. This parameter is used to uniquely identify the Via headers in
transaction created by that request. This parameter is used by both
the request, client, and the server.
The branch parameter value MUST maintain be unique across time for all
requests sent by the same ordering.
If UA. The exception to this rule is CANCEL. As
discussed below, a CANCEL request contained a To tag in will have the request, same value of the To field in
branch parameter as the
response MUST equal that request it cancels.
The uniqueness property of the request. However, if the To field in 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 request did 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 contain pick such a tag,
value), so that servers receiving the URI in request can determine that the To field
branch ID was constructed in the
response MUST equal fashion described by this
specification (i.e., globally unique). Beyond this requirement, the URI in the To field in the request.
Additionally, the UAS MUST add a tag to
precise format of the To field in branch token is implementation-defined.
The Via header maddr, ttl, and sent-by components will be set when
the response.
This serves to identify request is processed by the UAS that transport layer (Section 19).
Via processing for proxies is responding, possibly
resulting described in a component of a dialog ID. Sections 3 and sec:proxy-
response-processing-via.
8.1.1.8 Contact
The same tag MUST Contact header provides a SIP URI that can be used
for all responses to contact
that request, both provisional and final.
Procedures for generation specific instance of tags are defined in Section 21.3.
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 by
relying on redirection. Redirection allows servers to push routing
information user agent for a subsequent requests. The
Contact header MUST be present in any request back that can result in a response to the client, thereby
taking themselves out
establishment of a dialog. For the loop of further messaging for this
transaction while still aiding methods defined in locating the target of this
specification, that includes only the INVITE request.
When For these
requests, the originator scope of the request receives Contact is the redirection it will
send a new request based on dialog. That is, the routing information it has received.
By propagating routing information from
Various Authors [Page 31]
Internet Draft SIP January 28, 2002
Contact header refers to the core of URI at which the network UA would like to
its edges, redirection allows
receive requests, for considerable network scalability.
A redirect server is logically constituted of a server transaction
layer and a transaction user requests that has access to a location service are part of
some kind (see Section 10 for more on registrars and location
services). This location service is effectively a database containing
mappings between that dialog only.
Only a single URI MUST be present.
For further information on the Contact header, see Section 24.10.
8.1.1.9 Supported and a set of one or more alternative
locations at which Require
If the target of UAC supports extensions to SIP that URI can be found.
A redirect server does not issue any SIP requests of its own. After
receiving a request other than CANCEL, applied by the
server gathers the list of
alternative locations from to the location service and either returns a
final response of class 3xx or it refuses response, the request. For well-
formed CANCEL requests, it UAC SHOULD return include a 2xx response. This
response ends Supported header in
the SIP transaction. The redirect server maintains
transaction state request listing the option tags (Section 23.2) for those
extensions. This includes support for reliability for provisional
responses, which is an entire SIP transaction. It extension even though it is the
responsibility defined within
this specification. The option tag for reliability of clients provisional
responses is 100rel
The option-tags listed MUST only refer to detect forwarding loops between redirect
Various Authors [Page 35]
Internet Draft SIP October 26, 2001
servers.
When a redirect server returns a 3xx response 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, it
populates the list of (one or more) alternative locations into
Contact headers. An "expires" parameter since they too are often used to document vendor-defined
extensions.
If the Contact header may
also be supplied UAC wishes to indicate insist that a UAS understand an extension that
the lifetime of UAC will apply to the Contact data.
The Contact request in order to process the request, it
MUST insert a Require header field contains URIs giving into the new locations or
user names request listing the option tag
for that extension. If the UAC wishes to apply an extension to try, or may simply specify additional transport
parameters. A 301 or 302 response may also give the same location
request and
username insist that was targeted by any proxies that are traversed understand
that extension, it MUST insert a Proxy-Require header into 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.
Note listing the option tag for that extension.
As with the Contact Supported header, the option-tags in the Require header field MAY also
MUST only refer to extensions defined in standards-track RFCs.
A Require header in a different
entity than request with the one originally called. For example, a SIP call
connected option tag 100rel means that
the UAC wishes for all provisional responses to GSTN gateway may need this request to deliver 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 special informational
announcement such as "The number you have dialed new request has been changed."
A Contact response header field can contain any suitable URI
indicating where created, and the called party can be reached, not limited headers described above
have been properly constructed, any additional optional headers are
added, as are any headers specific to the method.
SIP
URIs. For example, it could requests MAY contain URL's for phones, fax, or irc (if
they were defined) or a mailto: (RFC 2368, [18]) URL.
The "expires" parameter MIME-encoded message-body. Regardless of
Various Authors [Page 32]
Internet Draft SIP January 28, 2002
the Contact header field indicates how
long the URI is valid. The parameter is either a number indicating
seconds or a quoted string containing type of body that a SIP-date. If this parameter
is not provided, request contains, certain headers must be
formulated to characterize the value contents of the Expires header field determines how
long body. For further
information on these headers see Sections 24.14, 24.15 and 24.12.
8.1.2 Sending the URI Request
The destination for the request is valid. Implementations then computed. A loose-routing
element MAY treat values larger than
2**32-1 (4294967295 seconds or 136 years) as equivalent use local policy to 2**32-1.
Redirect servers MUST ignore features that are not understood
(including unrecognized headers, Required extensions, or even method
names) determine the IP address, port, and proceed with
transport used to reach the redirection destination. One example of the session in question.
If such a particular extension requires that intermediate devices support
it, 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, the extension MUST destination can be tagged determined by
applying the DNS proceedures described in [8] to the Proxy-Require field as well
(see Section 22.28).
9 Canceling a Request
The previous section has discussed general UA behavior for generating
requests, and processing responses, for requests Request-URI.
These procedures yield an ordered set of all methods. In
this section, we discuss a general purpose method, called CANCEL. address, port, and
transports to attempt. The CANCEL request, as UAC SHOULD follow the name implies, is used to cancel a previous
request sent by procedures defined
there for stateful elements, trying each address until a client. Specifically, it asks the user agent server
to cease processing the request, is
contacted. Each try constitutes a new transaction, and generate an error response to
Various Authors [Page 36]
Internet Draft SIP October 26, 2001
that request. CANCEL has no effect on therefore each
carries a request that has already been
responded to. Because of this, it is most useful to CANCEL requests
which can take different Via header with a long time to respond to. For this reason, CANCEL new branch parameter.
Furthermore, the transport value in the Via header is
most useful for INVITE requests, which can take a long time set to
generate a response. In that usage, a UAS that receives a CANCEL
request whatever
transport was determined 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 servers. Section 15 discusses
under what conditions target server.
8.1.3 Loose Routing Policies
An element MAY apply a UAC would CANCEL an INVITE request, local loose-routing policy when preparing and
Section 16 discusses proxy usage of INVITE.
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
The following procedures are used to construct
sending a CANCEL request. The
Request-URI, Call-ID, To, This policy MAY affect the numeric part of CSeq Request-URI and From Route
header
fields in the CANCEL request MUST be identical to those field values 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 as well as where the request being cancelled. Using the same values for
these headers allows the CANCEL is
sent, and what transport mechanism is used to be matched with the request it
cancels (Section 9.2 indicates how such matching occurs). However, send it.
Elements SHOULD use the method part strict-routing policy of removing the Cseq header MUST have a topmost
value of CANCEL. This
allows it to be identified and processed as from a transaction route set, placing it in its own
right (See Section 17).
Once the CANCEL is constructed, the client SHOULD check whether any
response (provisional or final) has been received for Request-URI and sending 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 location indicated by that URI.
This is the arrival behavior of a
provisional response before sending the request. If the original
request has generated a final response, elements implementing earlier
strict versions of Route/Record-Route.
Where appropriate, elements MAY deviate from the CANCEL SHOULD NOT be
sent, strict-routing
policy as long as it is an effective no-op, since CANCEL has no effect on
requests which have already generated a final response. When the
client decides to send the CANCEL, it creates a client transaction
for following restrictions are met:
8.1.3.1 Modifying the CANCEL, and passes it Route header field
A loose-routing element MAY remove the CANCEL request along with topmost Route header field
value. It MUST remove the
destination address, port and transport. topmost Route header field value if that
value indicates a resource this element is responsible for. The destination address,
port, and transport for the CANCEL
element MUST be identical to those used to
send NOT modify or remove any subsequent Route header field
values. The element MAY place additional Route header field values
into the original request. Route header field before any existing values (effectivly
pushing values onto the top of the Route set).
Various Authors [Page 37] 33]
Internet Draft SIP October 26, 2001
If it was allowed January 28, 2002
A loose-routing element may chose to send not remove the CANCEL before receiving a
response for first
Route header field value. For example, elements configured
to use default outbound proxies in liu of using the previous request DNS
resolution proceedures will leave the server could receive topmost Route header
field value in the CANCEL before message.
When the original request.
Note that both topmost Route header field value indicates a
resource this element is responsible for, the transaction corresponding to message has
reached the original request element indicated by the route, and that value
must be removed from the CANCEL transaction will complete independently. However, a
UAC canceling a request cannot rely on receiving a 487 (Request
Terminated) response for Route header field. This assures
that Route header field values are consumed when the original request, as an RFC 2543-
compliant UAS will not generate such a response.
destination they indicate has been reached.
8.1.3.2 Modifying the Request-URI
If there is no final
response for the original request in 64*T1 seconds for an INVITE
transaction, and T3 seconds for Request-URI identifies a non-INVITE transaction, the client
SHOULD then consider resource for which this element is
responsible, the original transaction cancelled and loose-route policy SHOULD
destroy include modifying the client transaction handling
Request-URI before sending the original request.
9.2 Server Behavior
The CANCEL method requests
This restriction ensures that a Request-URI is modified
once the TU at resource it indicates has been reached.
8.1.3.3 Destination Choice
A loose-routing policy MUST direct the server side cancel a
pending request with to or the same Call-ID, To, From, top Via resource
indicated in the first Route header and
Request-URI and CSeq (sequence number only) field value, or to a proxy it
trusts to ensure this property.
This restriction ensures the resource indicated by the
topmost Route header field values. value is actually visited.
8.1.3.4 Loop Avoidance
The processing Request-URI of a CANCEL request at emitted by a server depends on loose-routing element MUST
differ from the type of
server. A stateless proxy will forward it, a stateful proxy might
respond URI in the first Route header field value.
This restriction is necessary to it and generate some CANCEL requests of its own, and a UAS
will respond avoid triggering false loop
detections in older systems. The following algorithm can be applied
to it. See Section 16.8 for proxy treatment ensure sufficient difference in otherwise matching Request-URIs
and first Route header field values.
For each of CANCEL.
When a UAS receives a CANCEL, it looks for any server transactions
which were created by requests with these items, D is the same To, From, Call-ID, Cseq
numeric value, Request-URI and top Via header. If no matching
transactions are found, address of the CANCEL is responded next hop (which may
or may not be equivalent to with a 481 (Call
Leg/Transaction Does Not Exist). A).
If the transaction for topmost element in the original received Route header field is
Various Authors [Page 34]
Internet Draft SIP January 28, 2002
<sip:a@A>, the outgoing request still exists, will contain
METHOD sip:a@A;maddr=D
Route: <sip:a@A>
If the behavior of topmost element in the UAS on receiving a CANCEL received Route header field is
<sip:a@A;maddr=D>, the outgoing request depends on whether it has already sent a final response for
original request. will contain
METHOD sip:a@A
Route: <sip:a@A;maddr=D>
If it has, the CANCEL topmost element in the received Route header field is
<sip:a@A;maddr=B> and D!=B, the outgoing request has no effect on 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 original request, no effect on any session state,
and no effect on TU is method specific. However, there are some
general behaviors independent of the responses generated for method.
8.1.4.1 Transaction Layer Errors
In some cases, the original request. If response returned by the UAS has transaction layer will
not issued be a final response for the original request, it
immediately responds to the original request with SIP message, but rather a 487 (Request
Terminated). transaction layer event. The CANCEL request itself only
event that the TU will encounter is answered with the timeout event. When the
timeout event is received from the transaction layer, it MUST be
treated as if a 200 (OK) 408 (Request Timeout) status code has been received.
8.1.4.2 Unrecognized Responses
A UAC MUST treat any response in
either case. Once it does not recognize as being
equivalent to the x00 response is constructed it is passed code of that class, and MUST be able
to process the
server transaction x00 response code for the CANCEL request.
10 Registrations
10.1 Overview of Usage
SIP is all classes. For example, if a protocol
UAC receives an unrecognized response code of 431, it can safely
assume that offers there was something wrong with its request and treat the
response as if it had received a discovery capability. For one user to 400 (Bad Request) response code.
Various Authors [Page 38] 35]
Internet Draft SIP October 26, 2001
initiate January 28, 2002
8.1.4.3 Vias
If more than one Via header field is present in a session with another, SIP must discover response, the current
host(s) UAC
SHOULD discard the message.
The presence of additional Via header fields that precede
the called user is reachable at. This discovery process originator of the request suggests that the message was
misrouted or possibly corrupted.
8.1.4.4 Processing Reliable 1xx Responses
A 1xx response that contains a Require header with the option tag
100rel is accomplished by SIP proxy servers, which are responsible for
receiving a request, determining where reliable provisional response. The UA core follows the
procedures in Section 18.2 to send it based on knowledge
of process the location of response, which will result
in the user, and then sending it there. To do this,
proxies consult an abstract service known as generation of a location service ,
which provides address bindings for PRACK request to acknowledge the reliable
provisional response.
8.1.4.5 Processing 3xx responses
Upon receipt of a particular domain. These
address bindings map an incoming SIP URL, sip:bob@Biloxi.com , for 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 SIP URLs which are somehow "closer" to the
desired user, sip:bob@engineering.Biloxi.com , for example.
Ultimately, a proxy will consult a location service which maps a
received URL to new requests based on the current host(s) that a user redirected
request.
If more than one URI is logged present in Contact header fields within the
3xx response, the UA MUST determine an order in to.
There are many ways by which these contact
addresses should be processed. UAs MUST consult the contents "q" parameter
value of the location service can Contact header fields (see Section 22.10) if available.
Contact addresses MUST be established. One way ordered from highest qvalue to lowest. If
no qvalue is administratively. In the above example,
Bob present, a contact address is known considered to be have a member
qvalue of the engineering department through
access 1.0. Note that two or more contact addresses might have an
equal qvalue - these URIs are eligible to a corporate database. SIP provides a mechanism, however,
for a user agent be tried in parallel.
Once an ordered list has been established, UACs MUST try to explicitly create a binding contact
each URI in the location
service of ordered list in turn until a proxy. This mechanism is known as registration.
The server responds. If
there are contact addresses with an equal qvalue, the UAC MAY decide
randomly on an order in which to process of registration entails sending a REGISTER message these addresses, or it MAY
attempt to a
special type process contact addresses of UAS known as 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 registrar. The registrar acts failure, as a
front end defined
in the next paragraph, the element moves to the location service for a domain, reading and writing
mappings based on next address in the contents of
list, until the REGISTER messages. This
location service will then be consulted by a proxy server that list is
responsible for routing requests for that domain.
SIP does not mandate a particular mechanism for implementing exhausted. If the
location service. The only requirement list is that a registrar for some
domain MUST exhausted, then the
request has failed.
Various Authors [Page 36]
Internet Draft SIP January 28, 2002
Failures SHOULD be capable of reading and writing data detected through failure response codes (codes
greater than 399) or network timeouts. Client transaction will report
any transport layer failures to the location
service, and transaction user.
When a proxy failure for that domain MUST be capable of reading that
same data. A registrar MAY be co-located with a particular SIP proxy
server for contact address is recieved, the same domain, allowing usage of an in memory database
for
client SHOULD try the location service. Usage of a shared database is another
implementation choice. The choice depends entirely on the
architectural requirements (redundancy, scalability, etc) of a
particular deployment.
Registration creates bindings in a location service for a particular
domain that associate an "address of record" URI with one or more
"contact addresses". next contact address. This means that when will involve
creating a proxy for that domain
receives new client transaction to deliver a request whose request URI matches the address of record,
the proxy will forward the request new request.
In order to the create a request based on a contact addresses
registered to that address of record. Generally, it only makes sense
to register an address of record at in a location service for 3xx
response, a domain
when requests for that address of record would be routed to that
domain. In most cases, this means that UAC MUST copy the domain of entire URI from the registration
will need to match Contact header into
the domain in 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 address of record.
Various Authors [Page 39]
Internet Draft SIP October 26, 2001
The most important usage of the registration mechanism is "header" parameters to inform a
proxy of create headers for the mapping between new
request, overwriting headers associated with the address of record and redirected request
in accordance with the current
host on which guidelines in Section 23.1.5.
Note that in some instances, headers that have been communicated in
the UA resides. However, contact address may instead append to existing request headers in
the registration process is original redirected request. As a general mechanism for establishing bindings, and can be used for
other purposes (for example, to set up call forwarding).
10.2 Construction of rule, if the REGISTER request
Several operations header can be performed with a REGISTER method with
respect to
accept a registrar. One comma-separated list of these is values, then the basic registration
operation that is described above, which provides a new binding
between an address of record and one or more contact addresses.
Registration on behalf of a particular address of record may header value
MAY be
performed by a third party if they are authorized to do so. A client
may also remove previous bindings, or query appended to determine which
bindings are currently any existing values in place for an address of record.
Aside from the exceptions noted in this and original redirected
request. If the following sections, header does not accept multiple values, the construction of value in
the REGISTER method, and behavior of clients
sending a REGISTER is identical to original redirected request MAY be overwritten by the general UAC behavior described header
value communicated in Section 8.1 and Section 17.1. Regardless of the operation that is
performed by contact address.
For example, if a REGISTER, contact address is returned with the following
value:
sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
Then any Subject header fields MUST be
formulated as follows:
Request-URI: The Request-URI names the domain of in the location
service that original redirected request is
overwritten, but the registration HTTP URL is meant for (e.g.
"chicago.com"). The user name MUST be empty.
To: The To merely appended to any existing
Call-Info header field contains the address of record whose
registration values.
It is to be created or modified. Note RECOMMENDED that the
initial To header field and UAC reuse the Request-URI field SHOULD
therefore be different same To, From, and Call-ID
used in a REGISTER message.
From: The From header field contains the address of record of
the person responsible for original redirected request, but the registration, which UAC MAY be
identical also choose
to update for example the value of the To header field. For third-
party registrations the From 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 To header therefore MUST have a new branch ID in
the top Via field are different.
Call-ID: All registrations from as discussed in Section 8.1.1.7.
In all other respects, requests sent upon receipt of a user agent client redirect
response SHOULD use
the same Call-ID header value, at least within the same
reboot cycle.
If different Call-IDs were used for overlapping
REGISTER messages coming from re-use the same client, headers and bodies of the
registrar might have trouble determining their
ordering. original
Various Authors [Page 40] 37]
Internet Draft SIP October 26, 2001
Contact: REGISTER requests MAY contain one or more January 28, 2002
request.
In some instances, Contact header fields. Contact addresses are presented in values may be cached at UAC
temporarily or permanently depending on the
Contact header fields of REGISTER requests.
Note that user agents MUST NOT send a new registration (containing
new Contact header fields, as opposed to a retransmission) until they
have status code received and
the presence of an expiration interval; see Sections 25.3.2 and
25.3.3.
8.1.4.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 from is received, the registrar for UAC SHOULD follow the previous one.
The following optional Contact header parameters also contain
behavior specific authorization
procedures of Section 20.2 and Section 20.3 to retry the registration process.
action: The "action" parameter has been deprecated. UACs SHOULD
NOT use request with
credentials.
If a 413 (Request Entity Too Large) response is received (Section
25.4.11), the "action" parameter.
expires: The "expires" parameter indicates how long request contained a body that was longer than the UAS
was willing to accept. If possible, the UAC
would like SHOULD retry the binding to be valid. The parameter is request,
either
a number indicating seconds omitting the body or using one of a quoted string containing a
SIP-date. smaller length.
If this parameter a 415 (Unsupported Media Type) response is received (Section
25.4.13), the request contained media types not provided, supported by the value of UAS.
The UAC SHOULD retry sending the Expires request, this time only using
content with types listed in the Accept header field determines how long in the binding is
valid. Implementations MAY treat values larger than 2**32-1
(4294967295 seconds or 136 years) as equivalent to 2**32-1.
10.2.1 Adding Bindings response, with REGISTER
For a simple registration, a REGISTER request sent to a registrar
includes contact addresses to which requests should be forward for
the originating user's address of record. The address of record
itself (i.e. 'sip:carol@chicago.com') MUST populate
encodings listed in the To Accept-Encoding header of in the REGISTER. The Contact header fields of response, and
with languages listed in the request typically
contain SIP URIs that identify particular SIP endpoints (i.e.
'sip:carol@cube2214a.chicago.com'), but they MAY use any Accept-Language in the response.
If a 416 (Unsupported URI scheme;
this way Scheme) response is received (Section
25.4.14, the Request-URI used a SIP UA can choose to register telephone numbers (with URI scheme not supported by the
tel URL, [13]) or email addresses (with
server. The client SHOULD retry the request, this time, using a mailto URL, [18]) as
Contacts for an address of record.
For example, if Carol, whose address of record SIP
URI.
If a 420 (Bad Extension) response is to register with
the registrar associated with received (Section 25.4.15), the location service of chicago.com.
This location service would then be accessed
request contained a Require or Proxy-Require header listing an
option-tag for a feature not supported by a proxy server that
receives requests targeting users or UAS. The UAC
SHOULD retry the request, this time omitting any extensions listed in
the chicago.com domain, and
hence new requests for Carol's address Unsupported header in the response.
In all of record will be routed to
her SIP endpoint.
Once a client has established bindings at the above cases, the request is retried by creating a registrar, it MAY send
subsequent registrations containing new bindings or modifications to
pre-existing bindings as necessary. The 2xx response to
request with the REGISTER
message will 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 (in Contact header fields) a complete list of
bindings new sequence number that have been registered for this address of record at this
registrar.
Various Authors [Page 41]
Internet Draft SIP October 26, 2001
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 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 42] 38]
Internet Draft SIP October 26, 2001
10.2.1.1 Setting the Expiration Interval of Contact Addresses January 28, 2002
case.
8.2 UAS Behavior
When a client sends request outside of a REGISTER request, it MAY suggest an expiration
interval that indicates how long the client would like the
registration to be valid (although as dialog is detailed in Section 10.3,
the registrar has the ultimate say).
There are two ways in which processed by a client can suggest an expiration
interval for UAS, there is a binding: through an Expires header, or an "expires"
Contact header parameter. The latter allows expiration intervals to
be suggested
set of processing rules which are followed, independent of the
method. Section 12 gives guidance on how a per-binding basis when more than one binding UAS can tell whether a
request is
given in inside or outside of a single REGISTER, whereas the former suggests an expiration
interval for all Contact header fields dialog.
Note that do not contain the
"expires" parameter.
If neither mechanism for expressing a suggested expiration time request processing is
present in a REGISTER, atomic. If a default suggestion of one hour request is assumed.
10.2.1.2 Setting Preference among Contact Addresses accepted, all
state changes associated with it MUST be performed. If more than one Contact it is sent in
rejected, all state changes MUST NOT be performed.
8.2.1 Method Inspection
Once a REGISTER, then request is authenticated (or no authentication was desired),
the registering
UA intends to associate all UAS MUST inspect the method of the URIs given in these Contact
headers with request. If the address UAS does not
support the method of record present 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 To field. This 405 (Method Not Allowed) response. The Allow header field MUST
list
can be prioritized with the "q" mechanism.
q: set of methods supported by the UAS generating the message.
The "q" parameter indicates a relative preference for Allow header field is presented in Section 24.5.
If the
particular Contact method is one supported by the server, processing continues.
8.2.2 Header Inspection
If a UAS does not understand a header field compared to other bindings
present in a request (that is,
the header is not defined in this REGISTER message specification or existing within the
location service of in any supported
extension), the registrar. For an example of how a
proxy server uses "q" values, see Section 16.5.
10.2.2 Removing Bindings with REGISTER
Registrations are removed from MUST ignore that header and continue
processing the registrar through an expiration
process; registrations message. A UAS SHOULD ignore any malformed headers
that are soft state not necessary for processing requests.
8.2.2.1 To and need to be refreshed
periodically. A client may attempt to influence Request-URI
The To header field identifies the expiration
intervals selected original recipient of the request
designated by the registrar as described user identified in Section 10.2.1. 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 registering user agent UAS MAY apply any policy
it wishes in determination of whether to accept requests when the immediate removal of a binding
by specifying an expiration interval To
field is not the identity of "0" for that contact address
in a REGISTER. It the UAS. However, it is RECOMMENDED that user agents support this
mechanism so that bindings can be removed
a UAS accept requests even if they do not recognize the URI scheme
(for whatever reason)
before their expiration interval has passed.
The REGISTER-specific Contact example, a tel: URI) in the To header, or if the To header field value
does not address a known or current user of "*" applies this UAS. If, on the
other hand, the UAS decides to
all registrations, but it MUST only be used when reject the Expires header
is present request, it SHOULD generate
a response with a value of "0". 403 (Forbidden) status code and pass it to the
Various Authors [Page 43] 39]
Internet Draft SIP October 26, 2001
Use of January 28, 2002
server transaction layer for transmission.
However, the "*" Contact header field value allows a
registering user agent Request-URI identifies the UAS that is to remove all of its bindings
expediently.
10.2.3 Fetching Bindings with REGISTER process the
request. If no Contact headers are present in the Request-URI uses a REGISTER, then scheme not supported by the UA is UAS,
it SHOULD reject the request with a 416 (Unsupported URI Scheme)
response. If the Request-URI does not
in fact registering any new bindings, and identify an address that the list of bindings
UAS is
therefore left unchanged. As noted above, in a successful response willing to
this REGISTER message, accept requests for, it SHOULD reject the complete list of existing bindings is
returned, and thus a REGISTER without Contact headers serves as request
with a
fetch operation.
10.2.4 Refreshing Registrations
When 404 (Not Found) response. Typically, a 2xx response has been received by UA that uses the client for a
REGISTER
request, the client MUST determine when each method to bind its address of the bindings
enumerated in the response needs record to be refreshed. This may a specific contact
address will see requests whose Request-URI equals those contact
addressess. Other potential sources of received Request-URIs include
bindings
the Contact headers of requests and responses sent by the UA that were registered
establish or refresh dialogs.
8.2.2.2 Merged Requests
If the request has no tag in previous REGISTER the To, the TU checks ongoing
transactions.
Since If the list To, From, Call-ID, CSeq exactly match (including
tags) those of bindings returned 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 REGISTER may
contain bindings 482 (Loop Detected) to the rest of them.
8.2.2.3 Require
Assuming the UAS decides that were not included in this REGISTER transaction, it is the client must correlate Contact header fields in proper element to process the response with
request, it examines the Contact Require header fields it sent in field, if present.
The Require general-header field is used by a UAC to tell a UAS about
SIP extensions that the request UAC expects the UAS to support in order to
establish proper expiration timers. This correlation should be
performed in accordance with
process the URI comparison rules given request properly. Its format is described in Section 21.1.4.
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 registering UA UAS MUST re-register each contact address at least as
often as add an Unsupported header
field, and list in it those options it does not understand amongst
those in the mandated expiration interval. A REGISTER that refreshes
a binding SHOULD have Require header of the same Call-ID as request. Upon receipt of the request which created 420
(Bad Extension) the binding. The CSeq header client SHOULD have a numeric sequence number
that is one higher than retry the value sent request, this time
without using those extensions listed in the last request with Unsupported header field
in the
same Call-ID. response.
Note that a UA Require and Proxy-Require MUST must update its expiration timers for refreshing
each binding every time it receives a response to a registration
request.
Registration refreshes SHOULD NOT be sent to the same address as the
original registration, unless redirected.
10.2.5 Discovering used in a Registrar
Depending on the policy of their administrative domain, SIP UAs can
be configured with the address of CANCEL
request, or in an ACK request sent for a local registrar. Some UAs may non-2xx response. These
headers should be
equipped with protocol tools (outside the scope of SIP) that allow
them to discover their local registrar dynamically. ignored if they are present in these requests.
Various Authors [Page 44] 40]
Internet Draft SIP October 26, 2001
Note that as an alternate means of discovering January 28, 2002
An ACK request for a registrar if no
local registrar is configured 2xx response MUST contain only those Require and
Proxy-Require values that were present in the user agent, clients MAY register
via multicast. Multicast registrations are addressed to the well-
known "all SIP servers" multicast address "sip.mcast.net"
(224.0.1.75). This request MUST be scoped to ensure it is not
forwarded beyond the boundaries of the administrative system. 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
MAY be done with either TTL or administrative scopes (see [19]),
depending on what is implemented in the network. SIP user agents MAY
listen to make sure that address and use it to become aware of the location of
other local users (see [20]); however, they do client-server interaction
will proceed without delay when all options are understood
by both sides, and only slow down if options are not respond to the
request.
Multicast registration may be inappropriate
understood (as in some
environments, for example, if multiple businesses share the
same local area network.
If example above). For a SIP UA knows of an appropriate registrar well-matched
client-server pair, the interaction proceeds quickly,
saving a round-trip often required by negotiation
mechanisms. In addition, it SHOULD attempt to
register with this also removes ambiguity when the
client requires features that the server periodically - management does not
understand. Some features, such as call handling fields,
are only of registration
intervals is detailed below.
10.3 interest to end systems.
8.2.3 Content Processing of REGISTER at
Assuming the Registrar
A registrar is a UAS that responds to a REGISTER request, and stores understands any extensions required by the client,
the information gathered from that request in a location service that
is in turn accessible to proxy servers within its administrative
domain. A registrar handles requests as a UAS (in conformity with
Section 8.2 and Section 17.2) but it accepts only examines the REGISTER method body of the message, and generates only the responses detailed in this section. Note headers that
describe it. If there are any bodies whose type (indicated by the REGISTER method also does not support
Content-Type), language (indicated by the Record-Route Content-Language) or Route
header,
encoding (indicated by the Content-Encoding) are not understood, and
that proxy servers MUST NOT add Record-Route headers to
REGISTER requests.
A registrar must know (through provisioning or some other mechanism) body part is not optional (as indicated by the set if administrative domain(s) for which its associated location
service(s) are responsible. REGISTER requests Content-
Disposition header), the UAS MUST be processed by reject the request with a
registrar 415
(Unsupported Media Type) response. The response MUST contain an
Accept header listing the types of all bodies it understands, in the order that they are received.
Upon
event the arrival request contained bodies of a REGISTER message, types not supported by the registrar UAS.
If the request contained content encodings not understood by the UAS,
the response MUST inspect contain an Accept-Encoding header listing the Request-URI to determine whether it has access to a location
service responsible for
encodings understood by the domain to which this request is
addressed. UAS. If this message is for some other administrative domain,
then if the registrar can act as a proxy server, it SHOULD forward the request to the addressed domain (following contained content
with languages not understood by the general behavior
for proxying messages described in Section 16).
When a registrar receives a REGISTER message, it is RECOMMENDED that UAS, the registrar authenticate response MUST contain
an Accept-Language header indicating the user agent client. Mechanisms for languages understood by the
Various Authors [Page 45]
Internet Draft SIP October 26, 2001
authentication
UAS.
Beyond these checks, body handling depends on the method and type.
For further information on the processing of Content-specific headers
Various Authors [Page 41]
Internet Draft SIP user agents are described in January 28, 2002
see Section 20.2;
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 7.4 as the asserted identity of the
originator of the request.
Once the identity of the registering user has been ascertained, it is
RECOMMENDED well as Section 24.11 through 24.15.
8.2.4 Applying Extensions
A UAS that wishes to apply some extension when generating the registrar determine
response MUST only do so if the authenticated user
agent is authorized to request and/or modify registrations support for this
address of record. For example, a registrar might consult a
authorization database (directly or through an appropriate protocol) that maps credentials or other tokens of identity resulting from
authentication to one or more addresses of record for which this
identity extension is responsible.
Note that indicated
in architectures that support third-party
registration, one entity may be responsible for updating the registrations associated with multiple addresses of
record.
When Supported header in the registrar has determined that request. If the client desired extension is permitted to
make the request, the registrar MUST extract
not supported, the address of record
from server SHOULD rely only on baseline SIP and any
other extensions supported by the client. To header field of the REGISTER. Note ensure that the registrar SHOULD
can be fulfilled, any specification of a new extension MUST extract the entire To header field URI in order include
discussion of how to use it as an
index in return gracefully to baseline SIP when the location service.
Next,
extension is not present. In rare circumstances, where the registrar MUST query its location service (the repository
of previously registered bindings) for server
cannot process the set of bindings associated
with this address of record. If request without the address of record is not valid
for this administrative domain (for example, because extension, the username is
not assigned), then server MAY send
a 421 (Extension Required) response. This response indicates that the registration attempt fails (see below). A
full URI comparison (as described in Section 21.1.4) MUST
proper response cannot be
performed to determine whether a given binding matches this address generated without support of record. a specific
extension. The registrar now needed extension(s) MUST extract all the Contact header fields from the
REGISTER message (note that there may be no Contact included in a Require
header field).
Each contact address in the response. This behavior is NOT RECOMMENDED, as it will
generally break interoperability.
Any extensions applied to a REGISTER non-421 response MUST now be compared to all
existing registrations at this location service according to the
rules listed in Section 21.1.4. Note that URIs other than SIP URIs a
Require header included in
contact addresses the response. Of course, the server MUST be compared according to
NOT apply extensions not listed in the standard URI
equivalency rules for Supported header in the URI schema
request. As a result of this, the Require header in question.
If a match is found among pre-existing registrations, response will
only ever contain option tags defined in standards-track RFCs.
8.2.5 Processing the registrar
MUST copy Request
Assuming all parameters associated with of the current Contact header
field from checks in the REGISTER message into the pre-existing binding in its
Various Authors [Page 46]
Internet Draft SIP October 26, 2001
location service (overwriting with changed values any existing
parameters as necessary, with previous subsections are passed,
the exception of "expires"). Expiration
intervals for this contact address MUST also be reset, based on any
suggested expiration in UAS processing becomes method-specific. Section 10 covers the
REGISTER (remember that this can be "0").
If no match is found among request, section 11 covers the set of pre-existing registrations, OPTIONS request, section 13
covers the
registrar MUST create INVITE request, and section 15 covers the BYE request.
8.2.6 Generating the Response
When a new binding in its location service between UAS wishes to construct a response to a request, it follows
these procedures. Additional procedures may be needed depending on
the address status code of record the response and the current Contact header field. All
Contact header field parameters circumstances of its
construction. These additional procedures are copied verbatim into this new
binding (again with documented elsewhere.
8.2.6.1 Sending a Provisional Response
One largely non-method-specific guideline for the exception generation of "expires"). An expiration
interval
responses is that UASs SHOULD NOT issue a provisional response for a
non-INVITE request. Rather, UASs SHOULD generate a final response to
a non-INVITE request as sooon as possible.
When a 100 (Trying) response is generated, any Timestamp header
present in the request MUST be selected by the registrar, taking copied into account any
suggested expiration for this contact address in the REGISTER.
Allowing the registrar to set the registration interval
protects it against excessively frequent registration
refreshes while limiting the state that it needs to
maintain 100 (Trying)
Various Authors [Page 42]
Internet Draft SIP January 28, 2002
response.
8.2.6.2 Headers and decreasing the likelihood of registrations
going stale. Tags
The expiration interval mandated by From field of the registrar may be either
longer or shorter than response MUST equal the interval suggested by From field of the sender
request. The Call-ID field of the
REGISTER, though response MUST equal the registrar SHOULD abide by Call-ID
field of the registering
client's suggestion.
A server MAY decide to lengthen request. The Cseq field of the expiration interval if response MUST equal the refresh rate
Cseq field of a particular client exceeds a
threshold, for example.
After the expiration interval selected by the registrar for a binding
has passed, if request. The Via headers in the binding has not been refreshed (increasing response MUST equal
the
expiration interval), Via headers in the registrar SHOULD silently discard request and MUST maintain the
binding.
Once all bindings same ordering.
If a request contained a To tag in the location service have been updated to
reflect any changes present to contact addresses in request, the REGISTER
message, To field in the registrar
response MUST remove any bindings equal that expire
immediately.
The REGISTER might have set of the expiration interval for
some bindings to "0" to remove them before their expiration
interval passes.
Finally, request. However, if the registrar must generate To field in
the request did not contain a response. If tag, the address of
record given URI in the To header field of in the REGISTER method is valid
for its administrative domain, then a 200
response MUST be sent,
Various Authors [Page 47]
Internet Draft SIP October 26, 2001
which MUST contain a complete list (within Contact header fields) of equal the currently valid bindings URI in the location service associated with
the address of record contained To field in the request;
additionally, the UAS MUST add a tag to the To field in the response
(with the exception of the REGISTER
request. This list 100 (Trying) response, in which a tag MAY
be empty (in which case present). This serves to identify the 200 would not
contain any Contact headers).
In UAS that is responding,
possibly resulting in a successful response to component of a REGISTER, wherein dialog ID. The same tag MUST
be used for all responses to that request, both final and provisional
(again excepting the bindings 100 (Trying)). Procedures for this
address generation of record
tags are enumerated as described above, the registrar
MUST supply an expiration interval for each contact address defined in either
an "expires" parameter of Section 23.3.
8.2.7 Stateless UAS Behavior
A stateless UAS is a Contact header or an Expires header. This
interval specifies the expiration interval 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 mandated by
the registrar (taking into account the registering UA's suggestion). sent. If a
stateless UAS receives a retransmission of a request, it regenerates
the registration failed because response and resends it, just as if it were the address of record contained in replying to the To field
first instance of the REGISTER is request. Stateless UASs do not valid use a
transaction layer; they receive requests directly from the transport
layer amd send responses directly to the transport layer.
The stateless UAS role is needed primarily to handle unauthenticated
requests for this domain, 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 halt call processing in a 404
MUST be sent.
11 Querying UAS,
effectively creating a denial of service condition; for Capabilities more
information see Section 22.1.5.
The most important behaviors of a stateless UAS are the following:
o A stateless UAS MUST NOT send provisional (1xx) responses.
o A stateless UAS MUST NOT retransmit responses.
o A stateless UAS MUST ignore ACK requests.
Various Authors [Page 43]
Internet Draft SIP method OPTIONS allows January 28, 2002
o A stateless UAS MUST ignore CANCEL requests.
o To header tags MUST be generated for responses in a client to query another client or
server as to its capabilities. This allows stateless
manner - in a client to discover
information about manner that will generate the methods, content types, extensions, codecs etc.
supported without actually "ringing" same tag for the other party.
same request consistently. For example,
before a client inserts information on tag
construction see Section 23.3.
In all other respects, a Require header field into an INVITE listing
an option that it is not certain the destination stateless UAS supports, the
client can query behaves in the destination same manner as
a stateful UAS. A UAS with an OPTIONS to see if this
option is returned can operate in either a Supported header field.
The target of stateful or stateless
mode for each new request.
8.3 Redirect Servers
In some architectures it may be desirable to reduce the OPTIONS request is identified processing
load on proxy servers that are responsible for routing requests, and
improve signaling path robustness, by the Request-URI,
which could identify another User Agent or a SIP Server.
Alternatively, relying on redirection.
Redirection allows servers to push routing information for a server receiving an OPTIONS request with
back in a Max-
Forwards header value of 0 MAY respond response to the request regardless client, thereby taking themselves out of
the Request-URI.
This behavior is common with HTTP/1.1.
An OPTIONS request sent as part loop of an established dialog does not
have any impact on further messaging for this transaction while still aiding
in locating the dialog.
11.1 Construction target of OPTIONS Request
An OPTIONS the request. When the originator of the
request is constructed using receives the standard rules for redirection, it will send a SIP new request as discussed Section 8.1.1.
A Contact header field MAY be present in an OPTIONS.
Various Authors [Page 48]
Internet Draft SIP October 26, 2001
OPEN ISSUE #197: What is based on
the semantic of this Contact
An Accept header field SHOULD be included to indicate URI it has received. By propagating URIs from the type core of
message body the UAC wishes
network to receive in the response.
Example OPTIONS request:
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=23411513a6
Via: SIP/2.0/UDP 10.1.3.3:5060
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3
CSeq: 63104 OPTIONS
Contact: <sip:alice@10.1.3.3>
Accept: application/sdp
Contact-Length: 0
11.2 Processing its edges, redirection allows for considerable network
scalability.
A redirect server is logically constituted of OPTIONS Request
The response a server transaction
layer and a transaction user that has access to an OPTIONS is constructed using the standard rules
for a SIP response as discussed in location service of
some kind (see Section 8.2.7. The response code
chosen 10 for more on registrars and location
services). This location service is the same that would have been chosen had the request been
an INVITE. That is, effectively a 200 (OK) would be returned if the UAS is ready
to accept database containing
mappings between a call, single URI and a 486 (Busy Here) would be returned if the UAS is
busy, etc. This allows an OPTIONS request to be used to determine the
basic state set of a UAS, one or more alternative
locations at which the target of that URI can be an indication found.
A redirect server does not issue any SIP requests of whether its own. After
receiving a request other than CANCEL, the UAC
will accept an INVITE request.
Note that this use of OPTIONS has limitations due server gathers the differences in
proxy handling list of OPTIONS
alternative locations from the location service and INVITE requests. While a forked INVITE
can result in multiple 200 OK responses being returned, a forked
OPTIONS will only result in either returns a single 200 OK response, since
final response of class 3xx or it is
treated by proxies using refuses the non-INVITE handling. See Section 13.2.1 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 normative details.
Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
fields SHOULD be present in
responsibility of clients to detect forwarding loops between redirect
servers.
When a 200 OK redirect server returns a 3xx response to an OPTIONS request.
A Contact header field MAY be present in a 200 OK response.
A Warning request, it
populates the list of (one or more) alternative locations into
Contact headers. An "expires" parameter to the Contact header field MAY be present.
A message body MAY may
also be sent, supplied to indicate the type lifetime of which is determined by the
Accept Contact data.
The Contact header in field contains URIs giving the OPTIONS request. new locations or
Various Authors [Page 49] 44]
Internet Draft SIP October 26, 2001
Example OPTIONS response (corresponding January 28, 2002
user names to the request in Section
11.1):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=23411513a6
Via: SIP/2.0/UDP 10.1.3.3:5060
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@10.1.3.3
CSeq: 63104 OPTIONS
Contact: <sip:carol@10.3.6.6>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Contact-Length: 274
v=0
o=carol 28908764872 28908764872 IN IP4 10.3.6.6
s=-
t=0 0
c=IN IP4 10.3.6.6
m=audio 0 RTP/AVP 0 1 3 99
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
a=rtpmap:99 SX7300/8000
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
12 Dialogs
A key concept for a user agent is that of a dialog. try, or may simply specify additional transport
parameters. 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 301 (Moved Permanently) or 302 (Moved Temporarily)
response may also give the user agents, and proper routing of requests
between both them. The dialog represents a context in which to
interpret SIP messages. The previous section discussed method
independent UA processing for requests same location and responses outside of username that was
targeted by the initial request but specify additional transport
parameters such as a
dialog. This section discusses how those requests and responses are
used different server or multicast address to construct a dialog, and then how subsequent requests and
responses are sent within a dialog.
Various Authors [Page 50]
Internet Draft SIP October 26, 2001
A dialog is identified at each UA with try, or
a dialog ID, which consists change of SIP transport from UDP to TCP or vice versa.
However, redirect servers MUST NOT redirect a Call-ID value, a local URI and local tag (together called the local
address), and request to a remote URI and remote tag (together called equal
to the remote
address). The dialog ID at each UA involved one in the dialog is not the
same. Specifically, Request-URI; instead, provided that the local URI and local tag at one UA are
identical does
not point to itself, the remote URI and remote tag at redirect server SHOULD proxy the peer UA. The tags
are opaque tokens that facilitate request to
the generation of unique dialog
IDs.
A dialog ID destination URI.
If a client is also associated with all responses, using an outbound proxy, and with any
request that contains proxy
actually redirects requests, a tag in the To field. The rules potential arises for computing
infinite redirection loops.
Note that the dialog ID of Contact header field MAY also refer to a message depend on whether the different
entity is a UAC or
UAS. than the one originally called. For example, a UAC, the Call-ID value of the dialog ID is set to the
Call-ID of the message, the remote address is set SIP call
connected to the To field of
the message, and the local address is set GSTN gateway may need to the From deliver a special informational
announcement such as "The number you have dialed has been changed."
A Contact response header field of can contain any suitable URI
indicating where the
message (these rules apply called party can be reached, not limited to both requests and responses). As one
would expect, SIP
URIs. For example, it could contain URIs for phones, fax, or irc (if
they were defined) or a UAS, mailto: (RFC 2368, [16]) URL.
The "expires" parameter of the Call-ID Contact header field indicates how
long the URI is valid. The value of the dialog ID parameter is set to a number
indicating seconds. If this parameter is not provided, the Call-ID value of
the message, Expires header field determines how long the remote address URI is set 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 From
field redirection of the message, and session in question.
If a particular extension requires that intermediate devices support
it, the local address is set to extension MUST be tagged in the To Proxy-Require field of
the message.
A dialog contains certain pieces of state needed as well
(see Section 24.29).
9 Canceling a Request
The previous section has discussed general UA behavior for further message
transmissions within the dialog. This state consists generating
requests, and processing responses, for requests of the Call-ID, all methods. In
this section, we discuss a local sequence number (used to order requests from general purpose method, called CANCEL.
The CANCEL request, as the UA name implies, is used to its
peer), cancel a remote sequence number (used to order requests from its peer 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 UA), request and to generate an error response to that
request. CANCEL has no effect on a route set, request to which is an ordered list a UAS has already
responded. Because of URIs. The
route set this, it is the set of servers that need most useful to be traversed CANCEL requests to send
which can take a
request long time to the peer. A dialog can also be in the "early" state, which
occurs when it respond. For this reason, CANCEL is created with
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 provisional response, would "stop
ringing", and then
transition respond to the "established" state when the final response comes.
12.1 Creation of a Dialog
Dialogs are created through the generation of non-failure responses
to requests INVITE with a specific methods. Within this specification, only
the 2xx error
response (a 487).
CANCEL requests can be constructed and 1xx responses to INVITE establish a dialog. A dialog
established sent by any type of client,
including both proxies and user agent clients. Section 15 discusses
under what conditions a non-final response to a request is called UAC would CANCEL 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 request, and
Section 16.9 discusses proxy usage of dialog state that is
not dependent on the method.
12.1.1 UAS
When CANCEL.
Because a UAS stateful proxy can generate its own CANCEL, a stateful
proxy also responds to a request with CANCEL, rather than simply forwarding a
response that establishes it would receive from a
dialog (such downstream element. For that reason,
CANCEL is referred to as a 2xx "hop-by-hop" request, since it is
responded to INVITE), the UAS MUST copy all Record-Route
headers from the at each stateful proxy hop.
9.1 Client Behavior
A CANCEL request into the response, and MUST maintain 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
order numeric part of those headers. This includes the URIs, URI parameters, CSeq and
Various Authors [Page 51]
Internet Draft SIP October 26, 2001
any Record-Route From header parameters, whether they are known or unknown
to
fields in the UAS. The UAS CANCEL request MUST add a Contact header field be identical to those in the response.
The Contact header field contains an address where
request being cancelled, including tags. A CANCEL constructed by a
client MUST have only a single Via header, whose value matches the UAS would like
to be contacted for subsequent requests
top Via in the dialog (which includes request being cancelled. Using the ACK same values for a 2xx response in
these headers allows the case of an INVITE). Generally, CANCEL to be matched with the
host portion of this URI is request it
cancels (Section 9.2 indicates how such matching occurs). However,
the IP address method part of the host, or its FQDN.
The URI provided in the Contact Cseq header MUST be have a SIP URL.
The UAS then constructs the state value of the dialog. CANCEL. This state MUST
allows it to be
maintained for the duration of identified and processed as a transaction in its own
right (See Section 17). If the dialog. First, request being cancelled contains
Route header fields, the route set CANCEL request MUST
be computed by following include these steps:
1. 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 list of URIs in CANCEL request MUST NOT contain any Require or Proxy-Require
header fields.
Once the Record-Route headers in CANCEL is constructed, the
request, if present, are taken, including client SHOULD check whether any URI
parameters.
2. The URI in
response (provisional or final) has been received for the Contact header from request
being cancelled (herein referred to as the "original request"). The
CANCEL request MUST NOT be sent if present,
is taken, including any URI parameters. The URI is appended
to no provisional response has been
received, rather, the bottom of client MUST wait for the list arrival of URIs from a
provisional response before sending the previous step.
Contact was not mandatory in RFC2543. Thus, if request. If the UAS original
request has generated a final response, the CANCEL SHOULD NOT be
sent, as it is talking to an older UAC, the UAC might not effective no-op, since CANCEL has no effect on
requests that have
inserted already generated a final response. When the Contact header.
3. The resulting list of URIs is called
client decides to send the route set
These rules clearly imply that CANCEL, it creates a UA MUST be able to parse client transaction
for the CANCEL and process Record-Route header fields. This is a change
from RFC2543, where all record-route passes it the CANCEL request along with the
destination address, port, and route processing
was optional for user agents.
It is possible transport. The destination address,
port, and transport for the route set to CANCEL MUST be empty. This will occur if
neither Record-Route headers nor identical to those used to
send the original request.
If it was allowed to send the CANCEL before receiving a Contact header were present in
response for the previous request, the server could receive
the CANCEL before the original request. The UAS MUST also remember whether
Note that both the bottom-most entry in transaction corresponding to the route set was constructed from original request
and the CANCEL transaction will complete independently. However, a Contact header or not. This is
effectively
UAC canceling a boolean value, which we refer to request cannot rely on receiving a 487 (Request
Terminated) response for the original request, as CONTACT_SET. This an RFC 2543-
compliant UAS will not generate such a response. If there is needed in order no
final response for the UA to determine whether the bottom most
value can be updated from subsequent requests; if it was constructed
from a Contact, it can be updated.
The remote sequence number sequence number MUST be set to original request in 64*T1 seconds (T1 is
defined in Section 17.1.1.1), the value
of client SHOULD then consider the sequence number in
original transaction cancelled and SHOULD destroy the Cseq header of client
transaction handling the original request.
9.2 Server Behavior
The local
sequence number MUST be empty. The call identifier component of CANCEL method requests that the
dialog ID MUST be set TU at the server side cancel a
pending transaction. The transaction to be canceled is determined by
taking the value of CANCEL request, and then assuming that the Call-ID in request method
were anything but CANCEL, apply the request. The
local address component transaction matching procedures
of Section 17.2.3. The matching transaction is the dialog ID MUST be set one to be
canceled.
The processing of a CANCEL request at a server depends on the To field
in the response 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 (which therefore includes according to the tag), general UAS
Various Authors [Page 52] 47]
Internet Draft SIP October 26, 2001 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 remote address component of 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 dialog ID MUST be set CANCEL did not find a matching transaction according to the
From field in
procedure above, the request. A UAS MUST CANCEL SHOULD be prepared responded to receive a
request without with a tag in 481 (Call
Leg/Transaction Does Not Exist). If the From field, in which case transaction for the tag is
considered to effectively have a value original
request still exists, the behavior of null.
This is to maintain backwards compatibility with RFC2543,
which did not mandate From tags.
12.1.2 UAC
When the UAS on receiving a UAC receives CANCEL
request depends on whether it has already sent a final response that establishes a dialog, it
constructs for
the state of original request. If it has, the dialog. This state MUST be maintained for CANCEL request has no effect on
the duration processing of the dialog. First, the route set MUST be computed by
following these steps:
1. The list of URIs present in the Record-Route headers in the
response are taken, if present, including all URI
parameters, original request, no effect on any session
state, and their order is reversed.
2. The URI in no effect on the Contact header from responses generated for the response, if
present, is taken, including all URI parameters, and
appended to original
request. If the end of UAS has not issued a final response for the list from original
request, its behavior depends on the previous step.
3. The list method of URIs resulting from the above two operations is
referred to as original request.
If the route set
It is possible for original request was an INVITE, the route set UAS SHOULD immediately
respond to be empty. This will occur if
neither Record-Route headers nor a Contact header were present in the
response. INVITE with a 487 (Request Terminated). The UAC MUST also remember whether the bottom-most entry in
the route set was constructed from behavior
upon reception of a Contact header or not. This CANCEL request for any other method defined in
this specification is effectively a boolean value, which we refer to as CONTACT_SET. This
is needed in order for the UA no-op. Extensions to determine whether the bottom most
value can be updated from subsequent requests; if it was constructed
from a Contact, it can be updated.
The local sequence number sequence number this
specification that define new methods MUST be set to define the value behavior of
the sequence number in the Cseq header a
UAS upon reception 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 CANCEL for those methods.
Regardless of the
dialog ID MUST be set to the value method of the Call-ID in original request, as long as the request. The
local address component of
CANCEL matched an existing transaction, the dialog ID MUST be set to CANCEL request itself is
answered with a 200 (OK) response. This response is constructed
following the From
field procedures described in Section 8.2.6 noting that the request, and the remote address component
To tag of the dialog
ID MUST be set response to the To field of CANCEL and the response. A UAC MUST be
prepared to receive a response without a To tag in the To field, in
which case response
to the tag is considered original request SHOULD be the same. The response to effectively have a value of null.
This CANCEL is
passed to maintain backwards compatibility with RFC2543,
which did not mandate To tags.
Various Authors [Page 53]
Internet Draft the server transaction for transmission.
10 Registrations
10.1 Overview
SIP October 26, 2001
12.2 Requests within offers a Dialog
Once discovery capability. If a dialog has been established between two UAs either of them MAY user wants to initiate new transactions as needed within the dialog. However, a
dialog imposes some restrictions on
session with another user, SIP must discover 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 current host(s) that dialog.
OPEN ISSUE #113: Should we relax
the constraint on non-
overlapping regular transactions?
A refresh request sent within a dialog destination user is defined as a request that
can modify reachable at. This discovery process is
accomplished by SIP proxy servers, which are responsible for
receiving a request, determining where to send it based on knowledge
of the route set location of the dialog. For dialogs that have been
established with user, and then sending it there. To do this,
proxies consult an INVITE, 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 are somehow "closer" to the only refresh request defined is re-
INVITE (see Section 14). Other extensions may define different
refresh requests
desired user, sip:bob@engineering.Biloxi.com , for dialogs established example.
Ultimately, a proxy will consult a location service which maps a
received URI to the current host(s) that a user is logged in other ways.
Note to.
Various Authors [Page 48]
Internet Draft SIP January 28, 2002
Registration creates bindings in a location service for a particular
domain that associate an ACK is NOT address-of-record URI with one or more
contact addresses. This means that when a refresh request.
12.2.1 UAC Behavior
12.2.1.1 Generating the Request
A request within proxy for that domain
receives a dialog is constructed by using many of the
components of request whose request URI matches the state stored as part of address-of-record,
the dialog.
The To header field of proxy will forward the request MUST be set to the remote address,
and the From header field MUST contact addresses
registered to that address-of-record. Generally, it only makes sense
to register an address-of-record at a location service for a domain
when requests for that address-of-record would be set routed to that
domain. In most cases, this means that the local address (both
including tags, assuming the tags are not null).
The Call-ID domain of the request MUST be set registration
will need to match the Call-ID of the dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one) domain in each direction. Therefore, if the local sequence number is not
empty, the value URI of the local sequence number MUST be incremented address-of-record.
There are many ways 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 which the
guidelines contents of Section 8.1.1.4. The method field in the Cseq header
MUST match the method of location service can
be established. One way is administratively. In the request.
With above example,
Bob is known to be a length member of 32 bits, a client could generate, within the engineering department through
access to a
single call, one request corporate database. SIP provides a second mechanism, however,
for about 136 years
before needing a user agent to wrap around. The initial value of the
Various Authors [Page 54]
Internet Draft SIP October 26, 2001
sequence number explicitly create a binding. This mechanism is chosen so that subsequent requests
within the same call will not wrap around. A non-zero
initial value allows clients
known as registration.
Registration entails sending a REGISTER request to use a time-based initial
sequence number. A client could, for example, choose the 31
most significant bits special type of a 32-bit second clock
UAS known as an
initial sequence number. a registrar. The Request-URI of requests is determined according registrar acts as a front end to the following
rules:
The UAC takes the list of URI in the route set inserted into
location service for a domain, reading and writing mappings based on
the
request URI contents of the request, including all URI parameters. Any URI
parameters not allowed in the request URI MUST REGISTER requests. This location service will
then be stripped. Each
of the remaining URIs (if any) from consulted by a proxy server that is responsible for routing
requests for that domain.
SIP does not mandate a particular mechanism for implementing the route set , including all URI
parameters,
location service. The only requirement is that a registrar for some
domain MUST be placed into a Route header field into the
request, in order.
A TU SHOULD follow the rules just mentioned able to read and write data to build the Request-URI 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 request, regardless of whether same domain.
10.2 Constructing the UA uses REGISTER Request
REGISTER requests add, remove and query bindings. A REGISTER request
may add a new binding between an outbound proxy
server address-of-record and one or not. However, in some instances, more
contact addresses. Registration on behalf of a UA particular address-
of-record may not be willing performed by a suitably authorized third party. A
client may also remove previous bindings, or
capable of sending the request query to the top element determine which
bindings are currently in place for an address-of-record.
Except as noted, the route set is
not capable construction of DNS, and therefore may not be able to follow those
procedures. In these cases, the UA MAY send REGISTER request and the
behavior of clients sending a REGISTER request is identical to a local
outbound server. In this case, it MUST NOT remove the top Route
header.
In dialogs created by an INVITE, if the UA is
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 caller,
it sets domain of the Request-URI to location
Various Authors [Page 49]
Internet Draft SIP January 28, 2002
service that the same value it used registration is meant for the
initial request, (e.g.,
"sip:chicago.com"). The "userinfo" and sends it to its local outbound server.
Bug#161: Which Request-URI does "@" components of
the callee use?
A UAC SHOULD include a Contact SIP URI MUST NOT be present.
To: The To header in any refresh requests within
a dialog, and unless there field contains the address of record whose
registration is a need to change it, the URI SHOULD be created, queried or modified. The To
header field and the same Request-URI field typically differ, as used in previous requests within
the dialog. As discussed
in Section 12.2.2, a Contact header in former contains a refresh request updates the
route set. user name. This allows a UA to provide address-of-record
MUST be a new contact address, should
its address change during SIP URI.
From: The From header field contains the duration address-of-record of
the dialog.
However, requests that are not refresh requests do not affect the
route set person responsible for the dialog.
Once the request has been constructed, registration. The value is
the address of same as the server is
computed and To header field unless 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
Various Authors [Page 55]
Internet Draft SIP October 26, 2001
The UAC will receives responses to the request
third-party registration.
Call-ID: All registrations from the transaction
layer.
The behavior of a UAC that receives a 3xx response user agent client SHOULD use
the same Call-ID header value for a request registrations sent
within to a dialog is
particular registrar.
If the same as if the client were to use different Call-ID
values, a registrar could not detect whether a delayed
REGISTER request would might have been sent
outside a dialog. This behavior is described in Section 13.2.2.
Note however that when the UAC tries alternative locations
it still uses arrived out of order.
CSeq: The CSeq value guarantees proper ordering of REGISTER
requests. A UA MUST increment the route set CSeq value by one for
each REGISTER request with the dialog to build the
Route same Call-ID.
Contact: REGISTER requests contain zero or more Contact header of the request.
If a UAC has
fields, containing address bindings.
User agents MUST NOT send a route set for new registration (i.e., containing new
Contact header fields, as opposed to a dialog, and receives retransmission) until they
have received a 2xx final response to
a refresh it sent, from the registrar for the previous
one or the previous REGISTER request has timed out.
The following Contact header field of parameters have a special meaning in
REGISTER requests:
action: The "action" parameter from RFC 2543 has been
deprecated. UACs SHOULD NOT use the response is
examined. If not present, "action" parameter.
expires: The "expires" parameter indicates how long the route set remains unchanged. If UA would
like the
response had binding to be valid. The value is a Contact header field, and the boolean variable
CONTACT_SET number
indicating seconds. If this parameter is false, not provided, the URL in
value of the Contact Expires header field in the
response is added used instead.
Implementations MAY treat values larger than 2**32-1
(4294967295 seconds or 136 years) as equivalent to the bottom of the route set , and CONTACT_SET is
set 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 true. If the refresh 3600.
10.2.1 Adding Bindings
The REGISTER request response had sent to a Contact header
field, and CONTACT_SET is true, registrar includes contact addresses
to which SIP requests for the URL address-of-record should be forwarded.
The address-of-record is included in the Contact To header field of the response to
REGISTER request.
The Contact header fields of the refresh request replaces the bottom value in 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 route set is responded with tel URL,
[13]) or email addresses (with a non-2xx final response the route
set remains unchanged mailto URL, [16]) as if no refresh request had been issued.
If the response Contacts 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. an
address-of-record.
For INVITE initiated dialogs terminating example, Carol, with address-of-record "sip:carol@chicago.com",
would register with the dialog
consists SIP registrar of sending a BYE.
12.2.2 UAS behavior
The UAS will receive the request from the transaction layer. If the
request has domain chicago.com. Her
registrations would then be used by a tag proxy server in the To header field, the UAS core computes the
dialog identifier corresponding chicago.com
domain to the request and compares route requests for Carol's address-of-record to her SIP
endpoint.
Once a client has established bindings at a registrar, it with MAY send
subsequent registrations containing new bindings or modifications to
existing dialogs. If there is bindings as necessary. The 2xx response to the REGISTER
request will contain, in Contact header fields, a match, complete list of
bindings that have been registered for this is address-of-record at this
registrar.
Registrations do not need to update all bindings. Typically, a mid-dialog request.
In that case, UA
only updates its own SIP URI as well as any non-SIP URIs.
10.2.1.1 Setting the same processing rules for requests outside Expiration Interval of Contact Addresses
When a
dialog, discussed 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 8.2, are applied by the UAS once 10.3, the
request is received from
registrar selects the transaction layer.
Requests that do not change actual time interval based on its local
policy.)
There are two ways in any way the state of which a dialog may be
received within client can suggest an expiration
interval for a dialog (e.g., binding: through an OPTIONS request). They are
processed as if they had been received outside the dialog.
Requests within Expires header field, or an
"expires" Contact header parameter. The latter allows expiration
intervals to be suggested on a dialog MAY contain Record-Route and 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. However, requests fields that are not refresh requests do
not update
the route set for contain the dialog. This specification only defines one
refresh request: re-INVITE (see Section 14). "expires" parameter.
Various Authors [Page 56] 52]
Internet Draft SIP October 26, 2001
Special rules apply when updated Record-Route or Contact header
fields are received inside a refresh request. January 28, 2002
If a UAS has a route
set neither mechanism for expressing a dialog, and receives suggested expiration time is
present in a 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 REGISTER, a default suggestion of one hour is
true, the assumed.
10.2.1.2 Preferences among Contact header field Addresses
If more than one Contact is sent in a REGISTER request, the request (if present) replaces
registering UA intends to associate all of the last entry URIs given in these
Contact headers with the route set address-of-record present in the UAS MUST add To field.
This list can be prioritized with the URL "q" parameter in the Contact
header field in fields. The "q" parameter indicates a relative preference for
the re- INVITE particular Contact header field compared to other bindings
present in this REGISTER message or existing within the bottom location
service of the route set
, registrar. Section 16.5 describes how a proxy server
uses this preference indication.
10.2.2 Removing Bindings
Registrations are soft state and then set CONTACT_SET expire unless refreshed, but can
also be explicitly removed. A client can attempt to true. If influence the request did not contain
expiration interval selected by the registrar as described in Section
10.2.1. A user agent requests the immediate removal of a binding by
specifying an expiration interval of "0" for that contact address in
a REGISTER request. User agents SHOULD support this mechanism so that
bindings can be removed before their expiration interval has passed.
The REGISTER-specific Contact header field, the route-set at the UAS remains unchanged.
If the remote sequence number is empty, field value of "*" applies to
all registrations, but it MUST only be set to used when the Expires header
field is present with a value of "0".
Use of the sequence number in the Cseq "*" Contact header in the request. field value allows a
registering user agent to remove all of its bindings
without knowing their precise values.
If no Contact header fields are present in a REGISTER request, the
remote sequence number was not empty, but the sequence number
list of the
request bindings is lower than left unchanged.
10.2.3 Fetching Bindings
A success response to any REGISTER request contains the remote sequence number, complete list
of existing bindings, regardless of whether the request is out
of order and MUST be rejected with contained a 500 response. If
Contact header field or not.
10.2.4 Refreshing Bindings
Each UA is responsible to refresh the remote
sequence number was not empty, and 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 sequence number registrar contains a list of Contact
fields enumerating all current bindings. The UA compares each contact
address to see if it created the request
is greater than contact address, using. comparison
rules in Section 23.1.4. If so, it updates the remote sequence number, expiration time
interval according to the expires parameter or, if absent, the
Expires field value. The UA then issues a REGISTER request is in order.
It is possible for each
of its bindings before the CSeq header to be higher than expiration interval has elapsed. It MAY
combine several updates into one REGISTER request.
A UA SHOULD use the remote
sequence number by more than one. This is not an error condition, and same Call-ID for all registrations during a UAS
single boot cycle. Registration refreshes SHOULD be prepared sent to receive and process requests with CSeq
values more than one higher than the previous received request. The
UAS MUST then set same
network address as the remote sequence number to original registration, unless redirected.
10.2.5 Setting the value of Internal Clock
If the
sequence number in response for REGISTER request contains a Date header, the Cseq
client MAY use this header in field to learn the request.
12.3 Termination of current time in order
to set any internal clocks.
10.2.6 Discovering a Dialog
Dialogs Registrar
UAs can end use three ways to determine the address to send registrations
to: by configuration, using the address-of-record and multicast. A UA
can be configured, in several different ways, depending on ways beyond the method.
When a dialog is established with INVITE, it is terminated scope of this specification,
with a
BYE. No other means registrar address. If there is no configured registrar
address, the UA SHOULD use the host part of the address-of-record as
the Request-URI and address the request there, using the normal SIP
server location mechanisms [8]. For example, the UA for the user
"sip:carol@chicago.com" addresses the REGISTER request to terminate
"chicago.com".
Finally, a dialog are described in this
specification, but extensions UA can define other ways.
13 Initiating a Session
13.1 Overview
When a user agent client desires be configured to initiate a session (for example,
audio, video, or a game), it formulates an INVITE request. The INVITE
request asks a server use multicast. Multicast
registrations are addressed to establish a session. 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 by proxies, eventually arriving at one or more UAS which
can potentially accept the invitation. These UAS's will frequently
need to query the user about whether to accept the invitation. After
some time, those UAS can accept beyond the invitation (meaning boundaries of the session
is to
administrative system. This MAY be established) by sending a 2xx response. If the invitation is
not accepted, a 3xx,4xx,5xx done with either TTL or 6xx response is sent,
administrative scopes (see [17]), depending on what is implemented in
the
reason for the rejection. Before sending a final response, the UAS
can also send a provisional response (1xx) network. SIP user agents MAY listen to advise that address and use it to
become aware of the UAC location of
progress other local users (see [18]);
however, they do not respond to the request.
Multicast registration may be inappropriate in contacting some
environments, for example, if multiple businesses share the called user.
same local area network.
Various Authors [Page 57] 54]
Internet Draft SIP October 26, 2001
After possibly receiving one or more provisional responses, January 28, 2002
10.2.7 Transmitting a Request
Once the UA
will get one or more 2xx responses or one non-2xx final response.
Because of REGISTER method has been constructed, and the protracted amount destination of time it can take
the message identified, UACs should follow the procedures described
in Section 8.1.2 to receive final
responses hand off the REGISTER to INVITE, the reliability mechanisms for INVITE
transactions differ from those of other requests (like OPTIONS). Once
it receives transaction layer.
If the transaction layer returns a final timeout error because the REGISTER
yielded no response, the UAC needs send an ACK for every
final response 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 receives. The procedure for sending this ACK
depends on MAY
retry the type of response. For final responses between 300 and
699, registration after making the ACK processing is done expiration interval of all
contact addresses in the transaction layer, and follows
one set of rules (See Section 17). For 2xx responses, REGISTER request equal to or greater than
the ACK is
generated by expiration interval within the UAC core. Min-Expires header of the 423
(Registration Too Brief) response.
10.3 Processing REGISTER Requests
A 2xx response to an INVITE establishes a session, and it also
creates registrar is a dialog between the UA UAS that issued the INVITE responds to REGISTER requests and the UA maintains
a list of bindings that generated the 2xx response. Therefore, when multiple 2xx
responses are received from different remote UAs (because the INVITE
forked), each 2xx establishes 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 different dialog. All these dialogs
are part of the same call.
This section provides details on the establishment of registrar listens
at a session using
INVITE.
13.2 Caller Processing
13.2.1 Creating the Initial INVITE
Since the initial INVITE represents multicast interface, it MAY redirect multicast REGISTER requests
to its own unicast interface with a 302 (Moved Temporarily) response.
A REGISTER request outside of a dialog,
its construction follows MUST NOT contain Record-Route or Route header
fields; registrars MUST ignore them if they appear.
A registrar must know (e.g., through configuration) the procedures set of Section 8.1.1. Additional
processing is required
domain(s) for the specific case of INVITE.
An Allow header field (Section 22.5) SHOULD which it maintains bindings. REGISTER requests MUST be present
processed by a registrar in the
INVITE. It indicates what methods can order that they are received.
REGISTER requests MUST also be invoked within a dialog, on
the UA sending the INVITE, for the duration of the dialog. For
example, a UA capable processed atomically, meaning that
REGISTER requests are either processed completely or not at all. Each
REGISTER message must be processed independently of any other
registration or binding changes.
When receiving INFO requests within a dialog [21]
SHOULD include an Allow header listing the INFO method.
A Supported header field (Section 22.35) SHOULD be present in the
INVITE. It enumerates all the extensions understood by the UAC.
An Accept (Section 22.1) header field MAY be present in REGISTER request, a registrar follows these steps:
1. The registrar inspects the INVITE.
It indicates which content-types are acceptable Request-URI to determine whether
it has access to bindings for the UA, domain identified in both the response received by it,
Request-URI. If not and in any subsequent requests sent to
it within dialogs established by if 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 22.19) to limit server also acts as a proxy
server, the
validity of server SHOULD forward the invitation. If request to the time indicated in
addressed domain, following the Expires general behavior for
proxying messages described in Section 16.
Various Authors [Page 58] 55]
Internet Draft SIP October 26, 2001 January 28, 2002
2. To guarantee that the registrar supports any necessary
extensions, the registrar processes Require header field is reached and no final answer fields
as described for UASs in Section 8.2.2.
3. A registrar SHOULD authenticate the INVITE has been
received UAC. Mechanisms for the UAC core SHOULD generate a CANCEL request
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
original INVITE.
A UAC registrar MAY also find useful to add, among others, Subject (Section
22.34), Organization (Section 22.24) and User-Agent (Section 22.39)
header fields. They all contain useful information related to take the
INVITE.
The UAC MAY choose to add a message body to From
address as the INVITE. Section
8.1.1.9 deals with how to construct asserted identity of the header fields- Content-Type
among others- needed to describe originator of the message body.
There are special rules
request.
4. The registrar SHOULD determine if the authenticated user is
authorized to modify registrations for message bodies that contain this address-of-
record. For example, a session
description - their corresponding Content-Disposition is "session".
SIP uses an offer/answer model where one UA sends registrar might consult a session
description, called the offer, which contains
authorization database that maps user names to a proposed description list of
addresses-of-record for which this identity is authorized
to modify bindings. If not, the session. 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 offer indicates registrar extracts the desired communications means
(audio, video, games), parameters address-of-record from the To
header field of those means (such as codec
types) and addresses request. If the address-of-record is not
valid for receiving media from the offerer. The other
UA responds with another session description, called domain in the answer,
which indicates which communications means are accepted, Request-URI, the
parameters which apply to those means, registrar
sends a 404 (Not Found) response and addresses for receiving
media from skips the answerer. remaining
steps. The offer/answer model can be mapped into URI MUST then converted to a canonical form. To
do that, all URI parameters are removed (including the INVITE transaction in two ways. user
param), and any escaped characters are converted to their
unescaped form. The first, which is result serves as an index into the most
intuitive, is that list
of bindings.
6. The registrar checks whether the INVITE request contains any
Contact header fields. If not, it skips to the offer, last step.
Next, the 2xx response registrar checks if there is one Contact field
that contains the answer, special value "*" and no session description is provided in a Expires field. If
the
ACK. In this model, request has additional Contact fields or an expiration
time other than zero, the UAC request is invalid and the offerer, server
returns 400 (Invalid Request) and skips the UAS is remaining
steps. If not, the
answerer. A second model is that registrar checks whether the INVITE contains no session
description, Call-ID
agrees with the 2xx response contains value stored for each binding. If not, it
removes the offer, and binding. If it does agree, it only removes the ACK
contains
binding if the answer. In this model, CSeq in the UAS request is higher than the offerer, value
Various Authors [Page 56]
Internet Draft SIP January 28, 2002
stored for that binding and leaves the
UAC binding as is
otherwise. It then skips to the answerer. last step.
7. The second model is useful for gateways from
H.323v1 to SIP, where registrar now processes each contact address in the H.323 media characteristics are not known
until
Contact header field in turn. For each address, it
determines the call expiration interval as follows:
- If the field value has an "expires" parameter, that value
is established. This used.
- If there is also useful for sessions no such parameter, but the request has an
Expires header field, that
use third-party call control. As value is used.
- If there is neither, a result of these models, locally-configured default value
is used.
The registrar MAY shorten the expiration interval. If and
only if the
INVITE contains expiration interval is greater than zero AND
smaller than one hour AND less than a session description, registrar-configured
minimum, the ACK MUST NOT contain one.
Conversely, if registrar MAY reject the caller chooses 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 omit
honor. It then skips the session description in remaining steps.
Allowing the INVITE, registrar to set the ACK MUST contain one (if 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 2xx response registration is frequently used in the creation of
services. An example is received).
2xx responses to an INVITE MUST always contain a session description.
All follow-me service, where the
user agents that support INVITE MUST support both models.
The Session Description Protocol (SDP) [6] MUST may only be supported by all
user agents as available at a means to describe sessions, and its usage terminal for
construction offers and answers MUST follow a brief
period. Therefore, registrars should accept brief
registrations; a request should only be rejected if
the procedures defined in
[22].
Note interval is so short that the restrictions of refreshes would
degrade registrar performance.
For each address, it then searches the offer-answer model (session
description only in list of current
bindings using the INVITE OR in URI comparison rules. If the ACK, but binding
does not in both) just
Various Authors [Page 59]
Internet Draft SIP October 26, 2001
described only apply to bodies whose Content-Disposition header field
is "session". Therefore, exist, it is possible that both tentatively added. If the INVITE and binding
does exist, the
ACK contain a body message (e.g., registrar checks the INVITE carries a photo
(Content-Disposition: render) Call-ID value. If the
existing binding has the same Call-ID value differs from
the request, the binding is removed if the expiration time
is zero and updated otherwise. If they are the ACK a session description
(Content-Disposition: session) ). same, the
registrar compares the CSeq value. If the Content-Disposition header field value is missing, bodies higher
than that of Content-Type application/sdp imply the disposition
"session", while other content types imply "render".
Once existing binding, it updates or removes
Various Authors [Page 57]
Internet Draft SIP January 28, 2002
the INVITE has been created, binding as above. If not, the UAC follows update is aborted and the procedures
defined for sending requests outside of a dialog (Section 8).
request fails.
This
results in the construction of a client transaction algorithm ensures that will
ultimately send out-of-order requests from
the request same UA are ignored.
Each binding record records the Call-ID and deliver responses CSeq values
from the request.
The binding updates are committed (i.e., made visible to
the UAC. proxy) if and only if all binding updates and additions
succeed. If a UA A sends an INVITE any one of them fails, the request to B fails with
500 (Server Error) response and receives 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 INVITE request
from B before it has received "expires"
parameter indicating its expiration interval chosen by the
registrar. The response to its request from B, A
MAY return a 500 (Internal Server Error), which SHOULD include a
Retry- After Date header field specifying when the request should be
resubmitted.
13.2.2 Processing INVITE Responses
Once the INVITE has been passed to the INVITE client trasaction, the
UAC waits
field.
11 Querying for responses for the INVITE. Responses are matched Capabilities
The SIP method OPTIONS allows a UA to
their corresponding INVITE because they have the same Call-ID, the
same From header field, the same To header field, excluding query another UA or a proxy
server as to its capabilities. This allows a client to discover
information about the tag,
and methods, content types, extensions, codecs etc.
supported without actually "ringing" the same CSeq. Rules for comparisons of these headers are
described in Section 22.
13.2.2.1 1xx responses
Zero, one or multiple provisional responses may arrive other party. For example,
before one or
more final responses are received. Provisional responses for an
INVITE request can create "early dialogs". If a provisional response
has client inserts a tag in Require header field into an INVITE listing
an option that it is not certain the To field, and if destination UAS supports, the dialog ID of
client can query the response does
not match destination UAS with an existing dialog, one OPTIONS to see if this
option is constructed using the procedures
defined returned in Section 12.1.0.2. a Supported header field.
The early dialog will only be needed if target of the UAC needs to send a OPTIONS request to its peer within is identified by the dialog before Request-URI,
which could identify another User Agent or a SIP Server. If the initial INVITE
transaction completes. Header fields present in
OPTIONS is addressed to a provisional
response are applicable for proxy server, the duration of Request-URI is set
without a user part, similar to the early dialog (e.g., way a Request-URI is set for a
REGISTER request. Alternatively, a server receiving an Allow header field in OPTIONS
request with a provisional response contains Max-Forwards header value of 0 MAY respond to the methods
that
request regardless of the Request-URI.
This behavior is common with HTTP/1.1. This behavior can be
used in as a "traceroute" functionality to check the early dialog).
13.2.2.2 3xx responses
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 60] 58]
Internet Draft SIP October 26, 2001
A 3xx response may contain January 28, 2002
return a Contact header field providing new
addresses where the callee might be reachable. Depending on the
status code of timeout error if the 3xx response (see Section 23.3) OPTIONS yields no response. This may
indicate that the UAC target is unreachable and hence unavailable.
An OPTIONS request MAY choose be sent as part of an established dialog to try those new addresses.
13.2.2.3 4xx, 5xx and 6xx responses
A single non-2xx final response
query the peer on capabilities that may be received for utilized later in the INVITE. 4xx,
5xx and 6xx responses may contain
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 indicating
the location where additional information about the error can MAY be
found.
All early dialogs are considered terminated upon reception of the
non-2xx final response.
After having received present in an OPTIONS.
An Accept header field SHOULD be included to indicate the non-2xx final response type of
message body the UAC core
considers the INVITE transaction completed. The INVITE client
transaction handles generation of ACKs for wishes to receive in the response (see Section
17).
13.2.2.4 2xx responses
Multiple 2xx responses may arrive at the UAC for a single INVITE
request due response. Typically,
this is set to a forking proxy. Each response format that is distinguished by the
tag parameter in used to describe the To header field, and each represents a distinct
dialog, with media
capabilities of a distinct dialog identifier.
If the dialog identifier in the 2xx UA, such as SDP (application/sdp).
The response matches the dialog
identifier of to an existing dialog, the dialog MUST be transitioned OPTIONS request is assumed to
the "established", and the route set for the dialog MUST be
recomputed based on the 2xx response using scoped to the procedures of Section
12.1.0.2. Otherwise, a new established dialog is constructed
Request-URI in the
same fashion.
The route set original request. However, only when an OPTIONS 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
sent as part of the dialog, since mid-dialog an established dialog is it guaranteed that future
requests may have been sent within will be received by the early call leg,
modifying server which generated the sequence numbers, for example. 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
Contact: <sip:alice@192.0.2.4>
Accept: application/sdp
Content-Length: 0
11.2 Processing of OPTIONS Request
The UAC core MUST generate response to an ACK request for each 2xx received from
the transaction layer. The header fields of the ACK are OPTIONS is constructed
in using the same way as standard rules
for any request sent within a dialog (see SIP response as discussed in Section
12) with the exception of the CSeq. 8.2.6. The sequence number of the CSeq
header field MUST be</