As per Relevance of the word initiation, we have this rfc below:
Network Working Group M.
Request for Comments: 2543
Category: Standards Track H.
Columbia U
E.
Cal
J.
Bell
March 1999
SIP: Session Initiation
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
IESG
The IESG intends to charter, in the near future, one or more
groups to produce standards for "name lookup", where such names
include electronic mail addresses and telephone numbers, and
result of such a lookup would be a list of attributes
characteristics of the user or terminal associated with the name
Groups which are in need of a "name lookup" protocol should
the development of these new working groups rather than using SIP
this function. In addition it is anticipated that SIP will
towards using such protocols, and SIP implementors are advised
monitor these efforts
The Session Initiation Protocol (SIP) is an application-layer
(signaling) protocol for creating, modifying and terminating
with one or more participants. These sessions include
multimedia conferences, Internet telephone calls and
distribution. Members in a session can communicate via multicast
via a mesh of unicast relations, or a combination of these
Handley, et al. Standards Track [Page 1]
RFC 2543 SIP: Session Initiation Protocol March 1999
SIP invitations used to create sessions carry session
which allow participants to agree on a set of compatible media types
SIP supports user mobility by proxying and redirecting requests
the user's current location. Users can register their
location. SIP is not tied to any particular conference
protocol. SIP is designed to be independent of the lower-
transport protocol and can be extended with additional capabilities
Table of
1 Introduction ........................................ 7
1.1 Overview of SIP Functionality ....................... 7
1.2 Terminology ......................................... 8
1.3 Definitions ......................................... 9
1.4 Overview of SIP Operation ........................... 12
1.4.1 SIP Addressing ...................................... 12
1.4.2 Locating a SIP Server ............................... 13
1.4.3 SIP Transaction ..................................... 14
1.4.4 SIP Invitation ...................................... 15
1.4.5 Locating a User ..................................... 17
1.4.6 Changing an Existing Session ........................ 18
1.4.7 Registration Services ............................... 18
1.5 Protocol Properties ................................. 18
1.5.1 Minimal State ....................................... 18
1.5.2 Lower-Layer-Protocol Neutral ........................ 18
1.5.3 Text-Based .......................................... 20
2 SIP Uniform Resource Locators ....................... 20
3 SIP Message Overview ................................ 24
4 Request ............................................. 26
4.1 Request-Line ........................................ 26
4.2 Methods ............................................. 27
4.2.1 INVITE .............................................. 28
4.2.2 ACK ................................................. 29
4.2.3 OPTIONS ............................................. 29
4.2.4 BYE ................................................. 30
4.2.5 CANCEL .............................................. 30
4.2.6 REGISTER ............................................ 31
4.3 Request-URI ......................................... 34
4.3.1 SIP Version ......................................... 35
4.4 Option Tags ......................................... 35
4.4.1 Registering New Option Tags with IANA ............... 35
5 Response ............................................ 36
5.1 Status-Line ......................................... 36
5.1.1 Status Codes and Reason Phrases ..................... 37
6 Header Field Definitions ............................ 39
6.1 General Header Fields ............................... 41
6.2 Entity Header Fields ................................ 42
6.3 Request Header Fields ............................... 43
Handley, et al. Standards Track [Page 2]
RFC 2543 SIP: Session Initiation Protocol March 1999
6.4 Response Header Fields .............................. 43
6.5 End-to-end and Hop-by-hop Headers ................... 43
6.6 Header Field Format ................................. 43
6.7 Accept .............................................. 44
6.8 Accept-Encoding ..................................... 44
6.9 Accept-Language ..................................... 45
6.10 Allow ............................................... 45
6.11 Authorization ....................................... 45
6.12 Call-ID ............................................. 46
6.13 Contact ............................................. 47
6.14 Content-Encoding .................................... 50
6.15 Content-Length ...................................... 51
6.16 Content-Type ........................................ 51
6.17 CSeq ................................................ 52
6.18 Date ................................................ 53
6.19 Encryption .......................................... 54
6.20 Expires ............................................. 55
6.21 From ................................................ 56
6.22 Hide ................................................ 57
6.23 Max-Forwards ........................................ 59
6.24 Organization ........................................ 59
6.25 Priority ............................................ 60
6.26 Proxy-Authenticate .................................. 60
6.27 Proxy-Authorization ................................. 61
6.28 Proxy-Require ....................................... 61
6.29 Record-Route ........................................ 62
6.30 Require ............................................. 63
6.31 Response-Key ........................................ 63
6.32 Retry-After ......................................... 64
6.33 Route ............................................... 65
6.34 Server .............................................. 65
6.35 Subject ............................................. 65
6.36 Timestamp ........................................... 66
6.37 To .................................................. 66
6.38 Unsupported ......................................... 68
6.39 User-Agent .......................................... 68
6.40 Via ................................................. 68
6.40.1 Requests ............................................ 68
6.40.2 Receiver-tagged Via Header Fields ................... 69
6.40.3 Responses ........................................... 70
6.40.4 User Agent and Redirect Servers ..................... 70
6.40.5 Syntax .............................................. 71
6.41 Warning ............................................. 72
6.42 WWW-Authenticate .................................... 74
7 Status Code Definitions ............................. 75
7.1 Informational 1xx ................................... 75
7.1.1 100 Trying .......................................... 75
7.1.2 180 Ringing ......................................... 75
Handley, et al. Standards Track [Page 3]
RFC 2543 SIP: Session Initiation Protocol March 1999
7.1.3 181 Call Is Being Forwarded ......................... 75
7.1.4 182 Queued .......................................... 76
7.2 Successful 2xx ...................................... 76
7.2.1 200 OK .............................................. 76
7.3 Redirection 3xx ..................................... 76
7.3.1 300 Multiple Choices ................................ 77
7.3.2 301 Moved Permanently ............................... 77
7.3.3 302 Moved Temporarily ............................... 77
7.3.4 305 Use Proxy ....................................... 77
7.3.5 380 Alternative Service ............................. 78
7.4 Request Failure 4xx ................................. 78
7.4.1 400 Bad Request ..................................... 78
7.4.2 401 Unauthorized .................................... 78
7.4.3 402 Payment Required ................................ 78
7.4.4 403 Forbidden ....................................... 78
7.4.5 404 Not Found ....................................... 78
7.4.6 405 Method Not Allowed .............................. 78
7.4.7 406 Not Acceptable .................................. 79
7.4.8 407 Proxy Authentication Required ................... 79
7.4.9 408 Request Timeout ................................. 79
7.4.10 409 Conflict ........................................ 79
7.4.11 410 Gone ............................................ 79
7.4.12 411 Length Required ................................. 79
7.4.13 413 Request Entity Too Large ........................ 80
7.4.14 414 Request-URI Too Long ............................ 80
7.4.15 415 Unsupported Media Type .......................... 80
7.4.16 420 Bad Extension ................................... 80
7.4.17 480 Temporarily Unavailable ......................... 80
7.4.18 481 Call Leg/Transaction Does Not Exist ............. 81
7.4.19 482 Loop Detected ................................... 81
7.4.20 483 Too Many Hops ................................... 81
7.4.21 484 Address Incomplete .............................. 81
7.4.22 485 Ambiguous ....................................... 81
7.4.23 486 Busy Here ....................................... 82
7.5 Server Failure 5xx .................................. 82
7.5.1 500 Server Internal Error ........................... 82
7.5.2 501 Not Implemented ................................. 82
7.5.3 502 Bad Gateway ..................................... 82
7.5.4 503 Service Unavailable ............................. 83
7.5.5 504 Gateway Time-out ................................ 83
7.5.6 505 Version Not Supported ........................... 83
7.6 Global Failures 6xx ................................. 83
7.6.1 600 Busy Everywhere ................................. 83
7.6.2 603 Decline ......................................... 84
7.6.3 604 Does Not Exist Anywhere ......................... 84
7.6.4 606 Not Acceptable .................................. 84
8 SIP Message Body .................................... 84
8.1 Body Inclusion ...................................... 84
Handley, et al. Standards Track [Page 4]
RFC 2543 SIP: Session Initiation Protocol March 1999
8.2 Message Body Type ................................... 85
8.3 Message Body Length ................................. 85
9 Compact Form ........................................ 85
10 Behavior of SIP Clients and Servers ................. 86
10.1 General Remarks ..................................... 86
10.1.1 Requests ............................................ 86
10.1.2 Responses ........................................... 87
10.2 Source Addresses, Destination Addresses
Connections ......................................... 88
10.2.1 Unicast UDP ......................................... 88
10.2.2 Multicast UDP ....................................... 88
10.3 TCP ................................................. 89
10.4 Reliability for BYE, CANCEL, OPTIONS,
Requests ............................................ 90
10.4.1 UDP ................................................. 90
10.4.2 TCP ................................................. 91
10.5 Reliability for INVITE Requests ..................... 91
10.5.1 UDP ................................................. 92
10.5.2 TCP ................................................. 95
10.6 Reliability for ACK Requests ........................ 95
10.7 ICMP Handling ....................................... 95
11 Behavior of SIP User Agents ......................... 95
11.1 Caller Issues Initial INVITE Request ................ 96
11.2 Callee Issues Response .............................. 96
11.3 Caller Receives Response to Initial Request ......... 96
11.4 Caller or Callee Generate Subsequent Requests ....... 97
11.5 Receiving Subsequent Requests ....................... 97
12 Behavior of SIP Proxy and Redirect Servers .......... 97
12.1 Redirect Server ..................................... 97
12.2 User Agent Server ................................... 98
12.3 Proxy Server ........................................ 98
12.3.1 Proxying Requests ................................... 98
12.3.2 Proxying Responses .................................. 99
12.3.3 Stateless Proxy: Proxying Responses ................. 99
12.3.4 Stateful Proxy: Receiving Requests .................. 99
12.3.5 Stateful Proxy: Receiving ACKs ...................... 99
12.3.6 Stateful Proxy: Receiving Responses ................. 100
12.3.7 Stateless, Non-Forking Proxy ........................ 100
12.4 Forking Proxy ....................................... 100
13 Security Considerations ............................. 104
13.1 Confidentiality and Privacy: Encryption ............. 104
13.1.1 End-to-End Encryption ............................... 104
13.1.2 Privacy of SIP Responses ............................ 107
13.1.3 Encryption by Proxies ............................... 108
13.1.4 Hop-by-Hop Encryption ............................... 108
13.1.5 Via field encryption ................................ 108
13.2 Message Integrity and Access Control
Authentication ...................................... 109
Handley, et al. Standards Track [Page 5]
RFC 2543 SIP: Session Initiation Protocol March 1999
13.2.1 Trusting responses .................................. 112
13.3 Callee Privacy ...................................... 113
13.4 Known Security Problems ............................. 113
14 SIP Authentication using HTTP Basic and
Schemes ............................................. 113
14.1 Framework ........................................... 113
14.2 Basic Authentication ................................ 114
14.3 Digest Authentication ............................... 114
14.4 Proxy-Authentication ................................ 115
15 SIP Security Using PGP .............................. 115
15.1 PGP Authentication Scheme ........................... 115
15.1.1 The WWW-Authenticate Response Header ................ 116
15.1.2 The Authorization Request Header .................... 117
15.2 PGP Encryption Scheme ............................... 118
15.3 Response-Key Header Field for PGP ................... 119
16 Examples ............................................ 119
16.1 Registration ........................................ 119
16.2 Invitation to a Multicast Conference ................ 121
16.2.1 Request ............................................. 121
16.2.2 Response ............................................ 122
16.3 Two-party Call ...................................... 123
16.4 Terminating a Call .................................. 125
16.5 Forking Proxy ....................................... 126
16.6 Redirects ........................................... 130
16.7 Negotiation ......................................... 131
16.8 OPTIONS Request ..................................... 132
A Minimal Implementation .............................. 134
A.1 Client .............................................. 134
A.2 Server .............................................. 135
A.3 Header Processing ................................... 135
B Usage of the Session Description Protocol (SDP)...... 136
B.1 Configuring Media Streams ........................... 136
B.2 Setting SDP Values for Unicast ...................... 138
B.3 Multicast Operation ................................. 139
B.4 Delayed Media Streams ............................... 139
B.5 Putting Media Streams on Hold ....................... 139
B.6 Subject and SDP "s=" Line ........................... 140
B.7 The SDP "o=" Line ................................... 140
C Summary of Augmented BNF ............................ 141
C.1 Basic Rules ......................................... 143
D Using SRV DNS Records ............................... 146
E IANA Considerations ................................. 148
F Acknowledgments ..................................... 149
G Authors' Addresses .................................. 149
H Bibliography ........................................ 150
I Full Copyright Statement ............................ 153
Handley, et al. Standards Track [Page 6]
RFC 2543 SIP: Session Initiation Protocol March 1999
1
1.1 Overview of SIP
The Session Initiation Protocol (SIP) is an application-layer
protocol that can establish, modify and terminate multimedia
or calls. These multimedia sessions include multimedia conferences
distance learning, Internet telephony and similar applications.
can invite both persons and "robots", such as a media
service. SIP can invite parties to both unicast and
sessions; the initiator does not necessarily have to be a member
the session to which it is inviting. Media and participants can
added to an existing session
SIP can be used to initiate sessions as well as invite members
sessions that have been advertised and established by other means
Sessions can be advertised using multicast protocols such as SAP
electronic mail, news groups, web pages or directories (LDAP),
others
SIP transparently supports name mapping and redirection services
allowing the implementation of ISDN and Intelligent Network
subscriber services. These facilities also enable personal mobility
In the parlance of telecommunications intelligent network services
this is defined as: "Personal mobility is the ability of end users
originate and receive calls and access subscribed
services on any terminal in any location, and the ability of
network to identify end users as they move. Personal mobility
based on the use of a unique personal identity (i.e.,
number)." [1]. Personal mobility complements terminal mobility, i.e.,
the ability to maintain communications when moving a single
system from one subnet to another
SIP supports five facets of establishing and terminating
communications
User location: determination of the end system to be used
communication
User capabilities: determination of the media and media parameters
be used
User availability: determination of the willingness of the
party to engage in communications
Call setup: "ringing", establishment of call parameters at
called and calling party
Handley, et al. Standards Track [Page 7]
RFC 2543 SIP: Session Initiation Protocol March 1999
Call handling: including transfer and termination of calls
SIP can also initiate multi-party calls using a multipoint
unit (MCU) or fully-meshed interconnection instead of multicast
Internet telephony gateways that connect Public Switched
Network (PSTN) parties can also use SIP to set up calls between them
SIP is designed as part of the overall IETF multimedia data
control architecture currently incorporating protocols such as
(RFC 2205 [2]) for reserving network resources, the real-
transport protocol (RTP) (RFC 1889 [3]) for transporting real-
data and providing QOS feedback, the real-time streaming
(RTSP) (RFC 2326 [4]) for controlling delivery of streaming media
the session announcement protocol (SAP) [5] for
multimedia sessions via multicast and the session
protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions
However, the functionality and operation of SIP does not depend
any of these protocols
SIP can also be used in conjunction with other call setup
signaling protocols. In that mode, an end system uses SIP
to determine the appropriate end system address and protocol from
given address that is protocol-independent. For example, SIP could
used to determine that the party can be reached via H.323 [7],
the H.245 [8] gateway and user address and then use H.225.0 [9]
establish the call
In another example, SIP might be used to determine that the callee
reachable via the PSTN and indicate the phone number to be called
possibly suggesting an Internet-to-PSTN gateway to be used
SIP does not offer conference control services such as floor
or voting and does not prescribe how a conference is to be managed
but SIP can be used to introduce conference control protocols.
does not allocate multicast addresses
SIP can invite users to sessions with and without
reservation. SIP does not reserve resources, but can convey to
invited system the information necessary to do this
1.2
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [10]
and indicate requirement levels for compliant SIP implementations
Handley, et al. Standards Track [Page 8]
RFC 2543 SIP: Session Initiation Protocol March 1999
1.3
This specification uses a number of terms to refer to the
played by participants in SIP communications. The definitions
client, server and proxy are similar to those used by the
Transport Protocol (HTTP) (RFC 2068 [11]). The terms and
syntax of URI and URL are defined in RFC 2396 [12]. The
terms have special significance for SIP
Call: A call consists of all participants in a conference invited
a common source. A SIP call is identified by a globally
call-id (Section 6.12). Thus, if a user is, for example,
to the same multicast session by several people, each of
invitations will be a unique call. A point-to-point
telephony conversation maps into a single SIP call. In
multiparty conference unit (MCU) based call-in conference,
participant uses a separate call to invite himself to the MCU
Call leg: A call leg is identified by the combination of Call-ID,
and From
Client: An application program that sends SIP requests. Clients
or may not interact directly with a human user. User agents
proxies contain clients (and servers).
Conference: A multimedia session (see below), identified by a
session description. A conference can have zero or more
and includes the cases of a multicast conference, a full-
conference and a two-party "telephone call", as well
combinations of these. Any number of calls can be used
create a conference
Downstream: Requests sent in the direction from the caller to
callee (i.e., user agent client to user agent server).
Final response: A response that terminates a SIP transaction,
opposed to a provisional response that does not. All 2xx, 3xx
4xx, 5xx and 6xx responses are final
Initiator, calling party, caller: The party initiating a
invitation. Note that the calling party does not have to be
same as the one creating the conference
Invitation: A request sent to a user (or service)
participation in a session. A successful SIP invitation
of two transactions: an INVITE request followed by an
request
Handley, et al. Standards Track [Page 9]
RFC 2543 SIP: Session Initiation Protocol March 1999
Invitee, invited user, called party, callee: The person or
that the calling party is trying to invite to a conference
Isomorphic request or response: Two requests or responses are
to be isomorphic for the purposes of this document if they
the same values for the Call-ID, To, From and CSeq
fields. In addition, isomorphic requests have to have the
Request-URI
Location server: See location service
Location service: A location service is used by a SIP redirect
proxy server to obtain information about a callee's
location(s). Location services are offered by location servers
Location servers MAY be co-located with a SIP server, but
manner in which a SIP server requests location services
beyond the scope of this document
Parallel search: In a parallel search, a proxy issues
requests to possible user locations upon receiving an
request. Rather than issuing one request and then waiting
the final response before issuing the next request as in
sequential search , a parallel search issues requests
waiting for the result of previous requests
Provisional response: A response used by the server to
progress, but that does not terminate a SIP transaction. 1
responses are provisional, other responses are considered final
Proxy, proxy server: An intermediary program that acts as both
server and a client for the purpose of making requests on
of other clients. Requests are serviced internally or by
them on, possibly after translation, to other servers. A
interprets, and, if necessary, rewrites a request message
forwarding it
Redirect server: A redirect server is a server that accepts a
request, maps the address into zero or more new addresses
returns these addresses to the client. Unlike a proxy server ,
it does not initiate its own SIP request. Unlike a user
server , it does not accept calls
Registrar: A registrar is a server that accepts REGISTER requests.
registrar is typically co-located with a proxy or
server and MAY offer location services
Handley, et al. Standards Track [Page 10]
RFC 2543 SIP: Session Initiation Protocol March 1999
Ringback: Ringback is the signaling tone produced by the
client's application indicating that a called party is
alerted (ringing).
Server: A server is an application program that accepts requests
order to service requests and sends back responses to
requests. Servers are either proxy, redirect or user
servers or registrars
Session: From the SDP specification: "A multimedia session is a
of multimedia senders and receivers and the data streams
from senders to receivers. A multimedia conference is an
of a multimedia session." (RFC 2327 [6]) (A session as
for SDP can comprise one or more RTP sessions.) As defined,
callee can be invited several times, by different calls, to
same session. If SDP is used, a session is defined by
concatenation of the user name , session id , network type ,
address type and address elements in the origin field
(SIP) transaction: A SIP transaction occurs between a client and
server and comprises all messages from the first request
from the client to the server up to a final (non-1xx)
sent from the server to the client. A transaction is
by the CSeq sequence number (Section 6.17) within a single
leg. The ACK request has the same CSeq number as
corresponding INVITE request, but comprises a transaction of
own
Upstream: Responses sent in the direction from the user agent
to the user agent client
URL-encoded: A character string encoded according to RFC 1738,
Section 2.2 [13].
User agent client (UAC), calling user agent: A user agent client is
client application that initiates the SIP request
User agent server (UAS), called user agent: A user agent server is
server application that contacts the user when a SIP request
received and that returns a response on behalf of the user.
response accepts, rejects or redirects the request
User agent (UA): An application which contains both a user
client and user agent server
An application program MAY be capable of acting both as a client
a server. For example, a typical multimedia conference
application would act as a user agent client to initiate calls or
Handley, et al. Standards Track [Page 11]
RFC 2543 SIP: Session Initiation Protocol March 1999
invite others to conferences and as a user agent server to
invitations. The properties of the different SIP server types
summarized in Table 1.
property redirect proxy user agent
server server
__________________________________________________________________
also acts as a SIP client no yes no
returns 1xx status yes yes yes
returns 2xx status no yes yes
returns 3xx status yes yes yes
returns 4xx status yes yes yes
returns 5xx status yes yes yes
returns 6xx status no yes yes
inserts Via header no yes no
accepts ACK yes yes yes
Table 1: Properties of the different SIP server
1.4 Overview of SIP
This section explains the basic protocol functionality and operation
Callers and callees are identified by SIP addresses, described
Section 1.4.1. When making a SIP call, a caller first locates
appropriate server (Section 1.4.2) and then sends a SIP
(Section 1.4.3). The most common SIP operation is the
(Section 1.4.4). Instead of directly reaching the intended callee,
SIP request may be redirected or may trigger a chain of new
requests by proxies (Section 1.4.5). Users can register
location(s) with SIP servers (Section 4.2.6).
1.4.1 SIP
The "objects" addressed by SIP are users at hosts, identified by
SIP URL. The SIP URL takes a form similar to a mailto or telnet URL
i.e., user@host. The user part is a user name or a telephone number
The host part is either a domain name or a numeric network address
See section 2 for a detailed discussion of SIP URL's
A user's SIP address can be obtained out-of-band, can be learned
existing media agents, can be included in some mailers'
headers, or can be recorded during previous invitation interactions
In many cases, a user's SIP URL can be guessed from their
address
Handley, et al. Standards Track [Page 12]
RFC 2543 SIP: Session Initiation Protocol March 1999
A SIP URL address can designate an individual (possibly located
one of several end systems), the first available person from a
of individuals or a whole group. The form of the address,
example, sip:sales@example.com , is not sufficient, in general,
determine the intent of the caller
If a user or service chooses to be reachable at an address that
guessable from the person's name and organizational affiliation,
traditional method of ensuring privacy by having an unlisted "phone
number is compromised. However, unlike traditional telephony,
offers authentication and access control mechanisms and can
itself of lower-layer security mechanisms, so that client
can reject unauthorized or undesired call attempts
1.4.2 Locating a SIP
When a client wishes to send a request, the client either sends it
a locally configured SIP proxy server (as in HTTP), independent
the Request-URI, or sends it to the IP address and port
to the Request-URI
For the latter case, the client must determine the protocol, port
IP address of a server to which to send the request. A client
follow the steps below to obtain this information, but MAY follow
alternative, optional procedure defined in Appendix D. At each step
unless stated otherwise, the client SHOULD try to contact a server
the port number listed in the Request-URI. If no port number
present in the Request-URI, the client uses port 5060. If
Request-URI specifies a protocol (TCP or UDP), the client
the server using that protocol. If no protocol is specified,
client tries UDP (if UDP is supported). If the attempt fails, or
the client doesn't support UDP but supports TCP, it then tries TCP
A client SHOULD be able to interpret explicit network
(such as ICMP messages) which indicate that a server is
reachable, rather than relying solely on timeouts. (For socket-
programs: For TCP, connect() returns ECONNREFUSED if the client
not connect to a server at that address. For UDP, the socket needs
be bound to the destination address using connect() rather
sendto() or similar so that a second write() fails with
if there is no server listening) If the client finds the server
not reachable at a particular address, it SHOULD behave as if it
received a 400-class error response to that request
The client tries to find one or more addresses for the SIP server
querying DNS. The procedure is as follows
Handley, et al. Standards Track [Page 13]
RFC 2543 SIP: Session Initiation Protocol March 1999
1. If the host portion of the Request-URI is an IP address
the client contacts the server at the given address
Otherwise, the client proceeds to the next step
2. The client queries the DNS server for address records
the host portion of the Request-URI. If the DNS
returns no address records, the client stops, as it
been unable to locate a server. By address record, we
A RR's, AAAA RR's, or other similar address records,
according to the client's network protocol capabilities
There are no mandatory rules on how to select a host
for a SIP server. Users are encouraged to name their
servers using the sip.domainname (i.e., sip.example.com
convention, as specified in RFC 2219 [16]. Users may
know an email address instead of a full SIP URL for
callee, however. In that case, implementations may be
to increase the likelihood of reaching a SIP server
that domain by constructing a SIP URL from that
address by prefixing the host name with "sip.". In
future, this mechanism is likely to become unnecessary
better DNS techniques, such as the one in Appendix D
become widely available
A client MAY cache a successful DNS query result. A successful
is one which contained records in the answer, and a server
contacted at one of the addresses from the answer. When the
wishes to send a request to the same host, it MUST start the
as if it had just received this answer from the name server.
client MUST follow the procedures in RFC1035 [15] regarding DNS
invalidation when the DNS time-to-live expires
1.4.3 SIP
Once the host part has been resolved to a SIP server, the
sends one or more SIP requests to that server and receives one
more responses from the server. A request (and its retransmissions
together with the responses triggered by that request make up a
transaction. All responses to a request contain the same values
the Call-ID, CSeq, To, and From fields (with the possible addition
a tag in the To field (section 6.37)). This allows responses to
matched with requests. The ACK request following an INVITE is
part of the transaction since it may traverse a different set
hosts
Handley, et al. Standards Track [Page 14]
RFC 2543 SIP: Session Initiation Protocol March 1999
If TCP is used, request and responses within a single SIP
are carried over the same TCP connection (see Section 10).
SIP requests from the same client to the same server MAY use the
TCP connection or MAY use a new connection for each request
If the client sent the request via unicast UDP, the response is
to the address contained in the next Via header field (Section 6.40)
of the response. If the request is sent via multicast UDP,
response is directed to the same multicast address and
port. For UDP, reliability is achieved using retransmission (
10).
The SIP message format and operation is independent of the
protocol
1.4.4 SIP
A successful SIP invitation consists of two requests, INVITE
by ACK. The INVITE (Section 4.2.1) request asks the callee to join
particular conference or establish a two-party conversation.
the callee has agreed to participate in the call, the caller
that it has received that response by sending an ACK (Section 4.2.2)
request. If the caller no longer wants to participate in the call,
sends a BYE request instead of an ACK
The INVITE request typically contains a session description,
example written in SDP (RFC 2327 [6]) format, that provides
called party with enough information to join the session.
multicast sessions, the session description enumerates the
types and formats that are allowed to be distributed to that session
For a unicast session, the session description enumerates the
types and formats that the caller is willing to use and where
wishes the media data to be sent. In either case, if the
wishes to accept the call, it responds to the invitation by
a similar description listing the media it wishes to use. For
multicast session, the callee SHOULD only return a
description if it is unable to receive the media indicated in
caller's description or wants to receive data via unicast
The protocol exchanges for the INVITE method are shown in Fig. 1
a proxy server and in Fig. 2 for a redirect server. (Note that
messages shown in the figures have been abbreviated slightly.)
Fig. 1, the proxy server accepts the INVITE request (step 1),
contacts the location service with all or parts of the address (
2) and obtains a more precise location (step 3). The proxy
then issues a SIP INVITE request to the address(es) returned by
location service (step 4). The user agent server alerts the
(step 5) and returns a success indication to the proxy server (
Handley, et al. Standards Track [Page 15]
RFC 2543 SIP: Session Initiation Protocol March 1999
6). The proxy server then returns the success result to the
caller (step 7). The receipt of this message is confirmed by
caller using an ACK request, which is forwarded to the callee (
8 and 9). Note that an ACK can also be sent directly to the callee
bypassing the proxy. All requests and responses have the same Call
ID
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning | :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ 4: INVITE 5: ring :
: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
: <........................( )<.........( ) :
: : 7: 200 OK : ( )6: 200 OK ( ) :
: : : ( work ) ( lab ) :
: : 8: ACK : ( )9: ACK ( ) :
: ========================>(~~~~~~)=========>(~~~~~~) :
+.....................+ +...............................+
====> SIP request
....> SIP response
^
| non-SIP protocols
|
Figure 1: Example of SIP proxy
The redirect server shown in Fig. 2 accepts the INVITE request (
1), contacts the location service as before (steps 2 and 3) and
instead of contacting the newly found address itself, returns
address to the caller (step 4), which is then acknowledged via an
Handley, et al. Standards Track [Page 16]
RFC 2543 SIP: Session Initiation Protocol March 1999
request (step 5). The caller issues a new request, with the
call-ID but a higher CSeq, to the address returned by the
server (step 6). In the example, the call succeeds (step 7).
caller and callee complete the handshake with an ACK (step 8).
The next section discusses what happens if the location
returns more than one possible alternative
1.4.5 Locating a
A callee may move between a number of different end systems
time. These locations can be dynamically registered with the
server (Sections 1.4.7, 4.2.6). A location server MAY also use one
more other protocols, such as finger (RFC 1288 [17]), rwhois (
2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20]
operating-system dependent mechanisms to actively determine the
system where a user might be reachable. A location server MAY
several locations because the user is logged in at several
simultaneously or because the location server has (temporarily
inaccurate information. The SIP server combines the results to
a list of a zero or more locations
The action taken on receiving a list of locations varies with
type of SIP server. A SIP redirect server returns the list to
client as Contact headers (Section 6.13). A SIP proxy server
sequentially or in parallel try the addresses until the call
successful (2xx response) or the callee has declined the call (6
response). With sequential attempts, a proxy server can implement
"anycast" service
If a proxy server forwards a SIP request, it MUST add itself to
beginning of the list of forwarders noted in the Via (Section 6.40)
headers. The Via trace ensures that replies can take the same
back, ensuring correct operation through compliant firewalls
avoiding request loops. On the response path, each host MUST
its Via, so that routing internal information is hidden from
callee and outside networks. A proxy server MUST check that it
not generate a request to a host listed in the Via sent-by, via
received or via-maddr parameters (Section 6.40). (Note: If a host
several names or network addresses, this does not always work. Thus
each host also checks if it is part of the Via list.)
A SIP invitation may traverse more than one SIP proxy server. If
of these "forks" the request, i.e., issues more than one request
response to receiving the invitation request, it is possible that
client is reached, independently, by more than one copy of
Handley, et al. Standards Track [Page 17]
RFC 2543 SIP: Session Initiation Protocol March 1999
invitation request. Each of these copies bears the same Call-ID.
user agent MUST return the same status response returned in the
response. Duplicate requests are not an error
1.4.6 Changing an Existing
In some circumstances, it is desirable to change the parameters of
existing session. This is done by re-issuing the INVITE, using
same Call-ID, but a new or different body or header fields to
the new information. This re INVITE MUST have a higher CSeq than
previous request from the client to the server
For example, two parties may have been conversing and then want
add a third party, switching to multicast for efficiency. One of
participants invites the third party with the new multicast
and simultaneously sends an INVITE to the second party, with the
multicast session description, but with the old call identifier
1.4.7 Registration
The REGISTER request allows a client to let a proxy or
server know at which address(es) it can be reached. A client MAY
use it to install call handling features at the server
1.5 Protocol
1.5.1 Minimal
A single conference session or call involves one or more
request-response transactions. Proxy servers do not have to
state for a particular call, however, they MAY maintain state for
single SIP transaction, as discussed in Section 12. For efficiency,
server MAY cache the results of location service requests
1.5.2 Lower-Layer-Protocol
SIP makes minimal assumptions about the underlying transport
network-layer protocols. The lower-layer can provide either a
or a byte stream service, with reliable or unreliable service
In an Internet context, SIP is able to utilize both UDP and TCP
transport protocols, among others. UDP allows the application to
carefully control the timing of messages and their retransmission,
perform parallel searches without requiring TCP connection state
each outstanding request, and to use multicast. Routers can
readily snoop SIP UDP packets. TCP allows easier passage
existing firewalls
Handley, et al. Standards Track [Page 18]
RFC 2543 SIP: Session Initiation Protocol March 1999
+....... cs.columbia.edu .......+
: :
: (~~~~~~~~~~) :
: ( location ) :
: ( service ) :
: (~~~~~~~~~~) :
: ^ | :
: | hgs@lab :
: 2| 3| :
: | | :
: henning| :
+.. cs.tu-berlin.de ..+ 1: INVITE : | | :
: : henning@cs.col: | \/ :
: cz@cs.tu-berlin.de =======================>(~~~~~~) :
: | ^ | <.......................( ) :
: | . | : 4: 302 Moved : ( ) :
: | . | : hgs@lab : ( work ) :
: | . | : : ( ) :
: | . | : 5: ACK : ( ) :
: | . | =======================>(~~~~~~) :
: | . | : : :
+.......|...|.........+ : :
| . | : :
| . | : :
| . | : :
| . | : :
| . | 6: INVITE hgs@lab.cs.columbia.edu (~~~~~~) :
| . ==================================================> ( ) :
| ..................................................... ( ) :
| 7: 200 OK : ( lab ) :
| : ( ) :
| 8: ACK : ( ) :
======================================================> (~~~~~~) :
+...............................+
====> SIP request
....> SIP response
^
| non-SIP protocols
|
Figure 2: Example of SIP redirect
Handley, et al. Standards Track [Page 19]
RFC 2543 SIP: Session Initiation Protocol March 1999
When TCP is used, SIP can use one or more connections to attempt
contact a user or to modify parameters of an existing conference
Different SIP requests for the same SIP call MAY use different
connections or a single persistent connection, as appropriate
For concreteness, this document will only refer to
protocols. However, SIP MAY also be used directly with
such as ATM AAL5, IPX, frame relay or X.25. The necessary
conventions are beyond the scope of this document. User agents
implement both UDP and TCP transport. Proxy, registrar, and
servers MUST implement both UDP and TCP transport
1.5.3 Text-
SIP is text-based, using ISO 10646 in UTF-8 encoding throughout.
allows easy implementation in languages such as Java, Tcl and Perl
allows easy debugging, and most importantly, makes SIP flexible
extensible. As SIP is used for initiating multimedia
rather than delivering media data, it is believed that the
overhead of using a text-based protocol is not significant
2 SIP Uniform Resource
SIP URLs are used within SIP messages to indicate the
(From), current destination (Request-URI) and final recipient (To)
a SIP request, and to specify redirection addresses (Contact). A
URL can also be embedded in web pages or other hyperlinks to
that a particular user or service can be called via SIP. When used
a hyperlink, the SIP URL indicates the use of the INVITE method
The SIP URL scheme is defined to allow setting SIP request-
fields and the SIP message-body
This corresponds to the use of mailto: URLs. It makes
possible, for example, to specify the subject, urgency
media types of calls initiated through a web page or
part of an email message
A SIP URL follows the guidelines of RFC 2396 [12] and has the
shown in Fig. 3. The syntax is described using Augmented Backus-
Form (See Section C). Note that reserved characters have to
escaped and that the "set of characters reserved within any given
component is defined by that component. In general, a character
reserved if the semantics of the URI changes if the character
replaced with its escaped US-ASCII encoding" [12].
Handley, et al. Standards Track [Page 20]
RFC 2543 SIP: Session Initiation Protocol March 1999
SIP-URL = "sip:" [ userinfo "@" ]
url-parameters [ headers ]
userinfo = user [ ":" password ]
user = *( unreserved |
| "&" | "=" | "+" | "$" | "," )
password = *( unreserved |
| "&" | "=" | "+" | "$" | "," )
hostport = host [ ":" port ]
host = hostname | IPv4
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" )
toplabel = alpha | alpha *( alphanum | "-" )
IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*
port = *
url-parameters = *( ";" url-parameter )
url-parameter = transport-param | user-param | method-
| ttl-param | maddr-param | other-
transport-param = "transport=" ( "udp" | "tcp" )
ttl-param = "ttl="
ttl = 1*3DIGIT ; 0 to 255
maddr-param = "maddr="
user-param = "user=" ( "phone" | "ip" )
method-param = "method="
tag-param = "tag="
UUID = 1*( hex | "-" )
other-param = ( token | ( token "=" ( token | quoted-string )))
headers = "?" header *( "&" header )
header = hname "="
hname = 1*
hvalue = *
uric = reserved | unreserved |
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
digits = 1*
Figure 3: SIP URL
The URI character classes referenced above are described in
C
The components of the SIP URI have the following meanings
Handley, et al. Standards Track [Page 21]
RFC 2543 SIP: Session Initiation Protocol March 1999
telephone-subscriber = global-phone-number | local-phone-
global-phone-number = "+" 1*phonedigit [isdn-subaddress
[post-dial
local-phone-number = 1*(phonedigit | dtmf-digit |
pause-character) [isdn-subaddress]
[post-dial
isdn-subaddress = ";isub=" 1*
post-dial = ";postd=" 1*(phonedigit | dtmf-
| pause-character
phonedigit = DIGIT | visual-
visual-separator = "-" | "."
pause-character = one-second-pause | wait-for-dial-
one-second-pause = "p
wait-for-dial-tone = "w
dtmf-digit = "*" | "#" | "A" | "B" | "C" | "D
Figure 4: SIP URL syntax; telephone
user: If the host is an Internet telephony gateway, the user
MAY also encode a telephone number using the notation
telephone-subscriber (Fig. 4). The telephone number is a
case of a user name and cannot be distinguished by a BNF. Thus
a URL parameter, user, is added to distinguish telephone
from user names. The phone identifier is to be used
connecting to a telephony gateway. Even without this parameter
recipients of SIP URLs MAY interpret the pre-@ part as a
number if local restrictions on the name space for user
allow it
password: The SIP scheme MAY use the format "user:password" in
userinfo field. The use of passwords in the userinfo is
RECOMMENDED, because the passing of authentication
in clear text (such as URIs) has proven to be a security risk
almost every case where it has been used
host: The mailto: URL and RFC 822 email addresses require
numeric host addresses ("host numbers") are enclosed in
brackets (presumably, since host names might be numeric),
host numbers without brackets are used for all other URLs.
SIP URL requires the latter form, without brackets
The issue of IPv6 literal addresses in URLs is being looked
elsewhere in the IETF. SIP implementers are advised to keep up
date on that activity
Handley, et al. Standards Track [Page 22]
RFC 2543 SIP: Session Initiation Protocol March 1999
port: The port number to send a request to. If not present,
procedures outlined in Section 1.4.2 are used to determine
port number to send a request to
URL parameters: SIP URLs can define specific parameters of
request. URL parameters are added after the host component
are separated by semi-colons. The transport parameter
the the transport mechanism (UDP or TCP). UDP is to be
when no explicit transport parameter is included. The
parameter provides the server address to be contacted for
user, overriding the address supplied in the host field.
address is typically a multicast address, but could also be
address of a backup server. The ttl parameter determines
time-to-live value of the UDP multicast packet and MUST only
used if maddr is a multicast address and the transport
is UDP. The user parameter was described above. For example,
specify to call j.doe@big.com using multicast to 239.255.255.1
with a ttl of 15, the following URL would be used
sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
The transport, maddr, and ttl parameters MUST NOT be used in the
and To header fields and the Request-URI; they are ignored
present
Headers: Headers of the SIP request can be defined with the "?"
mechanism within a SIP URL. The special hname "body"
that the associated hvalue is the message-body of the SIP
request. Headers MUST NOT be used in the From and To
fields and the Request-URI; they are ignored if present.
and hvalue are encodings of a SIP header name and value
respectively. All URL reserved characters in the header
and values MUST be escaped
Method: The method of the SIP request can be specified with
method parameter. This parameter MUST NOT be used in the
and To header fields and the Request-URI; they are ignored
present
Table 2 summarizes where the components of the SIP URL can be
and what default values they assume if not present
Examples of SIP URLs are
Handley, et al. Standards Track [Page 23]
RFC 2543 SIP: Session Initiation Protocol March 1999
default Req.-URI To From Contact
user -- x x x x
password -- x x x
host mandatory x x x x
port 5060 x x x x
user-param ip x x x x
method INVITE x
maddr-param -- x
ttl-param 1 x
transp.-param -- x
headers -- x
Table 2: Use and default values of URL components for SIP headers
Request-URI and
sip:j.doe@big.
sip:j.doe:secret@big.com;transport=
sip:j.doe@big.com?subject=
sip:+1-212-555-1212:1234@gateway.com;user=
sip:1212@gateway.
sip:alice@10.1.2.3
sip:alice@example.
sip:alice%40example.com@gateway.
sip:alice@registrar.com;method=
Within a SIP message, URLs are used to indicate the source
intended destination of a request, redirection addresses and
current destination of a request. Normally all these fields
contain SIP URLs
SIP URLs are case-insensitive, so that for example the two
sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent.
URL parameters are included when comparing SIP URLs for equality
SIP header fields MAY contain non-SIP URLs. As an example, if a
from a telephone is relayed to the Internet via SIP, the SIP
header field might contain a phone URL
3 SIP Message
SIP is a text-based protocol and uses the ISO 10646 character set
UTF-8 encoding (RFC 2279 [21]). Senders MUST terminate lines with
CRLF, but receivers MUST also interpret CR and LF by themselves
line terminators
Handley, et al. Standards Track [Page 24]
RFC 2543 SIP: Session Initiation Protocol March 1999
Except for the above difference in character sets, much of
message syntax is and header fields are identical to HTTP/1.1;
than repeating the syntax and semantics here we use [HX.Y] to
to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [11]).
In addition, we describe SIP in both prose and an augmented Backus
Naur form (ABNF). See section C for an overview of ABNF
Note, however, that SIP is not an extension of HTTP
Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple
transactions can be carried in a single TCP connection or
datagram. UDP datagrams, including all headers, SHOULD NOT be
than the path maximum transmission unit (MTU) if the MTU is known,
1500 bytes if the MTU is unknown
The 1500 bytes accommodates encapsulation within
"typical" ethernet MTU without IP fragmentation.
studies [22] indicate that an MTU of 1500 bytes is
reasonable assumption. The next lower common MTU values
1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
[23]). Thus, another reasonable value would be a
size of 950 bytes, to accommodate packet headers within
SLIP MTU without fragmentation
A SIP message is either a request from a client to a server, or
response from a server to a client
SIP-message = Request |
Both Request (section 4) and Response (section 5) messages use
generic-message format of RFC 822 [24] for transferring entities (
body of the message). Both types of messages consist of a start-line
one or more header fields (also known as "headers"), an empty
(i.e., a line with nothing preceding the carriage-return line-
(CRLF)) indicating the end of the header fields, and an
message-body. To avoid confusion with similar-named headers in HTTP
we refer to the headers describing the message body as
headers. These components are described in detail in the
sections
generic-message = start-
*message-
Handley, et al. Standards Track [Page 25]
RFC 2543 SIP: Session Initiation Protocol March 1999
[ message-body ]
start-line = Request-Line | ;Section 4.1
Status-Line ;Section 5.1
message-header = ( general-
| request-
| response-
| entity-header )
In the interest of robustness, any leading empty line(s) MUST
ignored. In other words, if the Request or Response message
with one or more CRLF, CR, or LFs, these characters MUST be ignored
4
The Request message format is shown below
Request = Request-Line ; Section 4.1
*( general-
| request-
| entity-header )
[ message-body ] ; Section 8
4.1 Request-
The Request-Line begins with a method token, followed by
Request-URI and the protocol version, and ending with CRLF.
elements are separated by SP characters. No CR or LF are
except in the final CRLF sequence
Request-Line = Method SP Request-URI SP SIP-Version
Handley, et al. Standards Track [Page 26]
RFC 2543 SIP: Session Initiation Protocol March 1999
general-header = Accept ; Section 6.7
| Accept-Encoding ; Section 6.8
| Accept-Language ; Section 6.9
| Call-ID ; Section 6.12
| Contact ; Section 6.13
| CSeq ; Section 6.17
| Date ; Section 6.18
| Encryption ; Section 6.19
| Expires ; Section 6.20
| From ; Section 6.21
| Record-Route ; Section 6.29
| Timestamp ; Section 6.36
| To ; Section 6.37
| Via ; Section 6.40
entity-header = Content-Encoding ; Section 6.14
| Content-Length ; Section 6.15
| Content-Type ; Section 6.16
request-header = Authorization ; Section 6.11
| Contact ; Section 6.13
| Hide ; Section 6.22
| Max-Forwards ; Section 6.23
| Organization ; Section 6.24
| Priority ; Section 6.25
| Proxy-Authorization ; Section 6.27
| Proxy-Require ; Section 6.28
| Route ; Section 6.33
| Require ; Section 6.30
| Response-Key ; Section 6.31
| Subject ; Section 6.35
| User-Agent ; Section 6.39
response-header = Allow ; Section 6.10
| Proxy-Authenticate ; Section 6.26
| Retry-After ; Section 6.32
| Server ; Section 6.34
| Unsupported ; Section 6.38
| Warning ; Section 6.41
| WWW-Authenticate ; Section 6.42
Table 3: SIP
4.2
The methods are defined below. Methods that are not supported by
proxy or redirect server are treated by that server as if they
an OPTIONS method and forwarded accordingly. Methods that are
Handley, et al. Standards Track [Page 27]
RFC 2543 SIP: Session Initiation Protocol March 1999
supported by a user agent server or registrar cause a 501 (
Implemented) response to be returned (Section 7). As in HTTP,
Method token is case-sensitive
Method = "INVITE" | "ACK" | "OPTIONS" | "BYE
| "CANCEL" | "REGISTER
4.2.1
The INVITE method indicates that the user or service is being
to participate in a session. The message body contains a
of the session to which the callee is being invited. For two-
calls, the caller indicates the type of media it is able to
and possibly the media it is willing to send as well as
parameters such as network destination. A success response
indicate in its message body which media the callee wishes to
and MAY indicate the media the callee is going to send
Not all session description formats have the ability
indicate sending media
A server MAY automatically respond to an invitation for a
the user is already participating in, identified either by the
Call-ID or a globally unique identifier within the
description, with a 200 (OK) response
If a user agent receives an INVITE request for an existing call
with a higher CSeq sequence number than any previous INVITE for
same Call-ID, it MUST check any version ide