From: sip:watson@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 3 REGISTER
Contact: sip:tawatson@example.com
Now, the server will forward any request for Watson to the server at
example.com, using the Request-URI tawatson@example.com. For the
server at example.com to reach Watson, he will need to send a
REGISTER there, or inform the server of his current location through
some other means.
It is possible to use third-party registration. Here, the secretary
jon.diligent registers his boss, T. Watson:
C->S: REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP pluto.bell-tel.com
From: sip:jon.diligent@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 17320@pluto.bell-tel.com
CSeq: 1 REGISTER
Contact: sip:tawatson@example.com
The request could be sent to either the registrar at bell-tel.com or
the server at example.com. In the latter case, the server at
example.com would proxy the request to the address indicated in the
Request-URI. Then, Max-Forwards header could be used to restrict the
registration to that server.
16.2 Invitation to a Multicast Conference
The first example invites schooler@vlsi.cs.caltech.edu to a multicast
session. All examples use the Session Description Protocol (SDP) (RFC
2327 [6]) as the session description format.
16.2.1 Request
C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu>
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
Subject: SIP will be discussed, too
Content-Type: application/sdp
Content-Length: 187
v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0
The From request header above states that the request was initiated
by mjh@isi.edu and addressed to schooler@caltech.edu (From header
fields). The Via fields list the hosts along the path from invitation
initiator (the last element of the list) towards the callee. In the
example above, the message was last multicast to the administratively
scoped group 239.128.16.254 with a ttl of 16 from the host
csvax.cs.caltech.edu. The second Via header field indicates that it
was originally sent from the host north.east.isi.edu. The Request-URI
indicates that the request is currently being being addressed to
schooler@cs.caltech.edu, the local address that csvax looked up for
the callee.
In this case, the session description is using the Session
Description Protocol (SDP), as stated in the Content-Type header.
The header is terminated by an empty line and is followed by a
message body containing the session description.
16.2.2 Response
The called user agent, directly or indirectly through proxy servers,
indicates that it is alerting ("ringing") the called party:
S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
A sample response to the invitation is given below. The first line of
the response states the SIP version number, that it is a 200 (OK)
response, which means the request was successful. The Via headers are
taken from the request, and entries are removed hop by hop as the
response retraces the path of the request. A new authentication field
MAY be added by the invited user's agent if required. The Call-ID is
taken directly from the original request, along with the remaining
fields of the request message. The original sense of From field is
preserved (i.e., it is the session initiator).
In addition, the Contact header gives details of the host where the
user was located, or alternatively the relevant proxy contact point
which should be reachable from the caller's host.
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
;maddr=239.128.16.254;ttl=16
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 INVITE
Contact: sip:es@jove.cs.caltech.edu
The caller confirms the invitation by sending an ACK request to the
location named in the Contact header:
C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0
Via: SIP/2.0/UDP north.east.isi.edu
From: Mark Handley <sip:mjh@isi.edu>
To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
Call-ID: 2963313058@north.east.isi.edu
CSeq: 1 ACK
16.3 Two-party Call
For two-party Internet phone calls, the response must contain a
description of where to send the data. In the example below, Bell
calls Watson. Bell indicates that he can receive RTP audio codings 0
(PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4).
C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com>
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
s=Mr. Watson, come here.
c=IN IP4 kton.bell-tel.com
m=audio 3456 RTP/AVP 0 3 4 5
S->C: SIP/2.0 100 Trying
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 182 Queued, 2 callers ahead
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 182 Queued, 1 caller ahead
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Content-Length: 0
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Contact: sip:watson@boston.bell-tel.com
Content-Type: application/sdp
Content-Length: ...
v=0
o=watson 4858949 4858949 IN IP4 192.1.2.3
s=I'm on my way
c=IN IP4 boston.bell-tel.com
m=audio 5004 RTP/AVP 0 3
The example illustrates the use of informational status responses.
Here, the reception of the call is confirmed immediately (100), then,
possibly after some database mapping delay, the call rings (180) and
is then queued, with periodic status updates.
Watson can only receive PCMU and GSM. Note that Watson's list of
codecs may or may not be a subset of the one offered by Bell, as each
party indicates the data types it is willing to receive. Watson will
send audio data to port 3456 at c.bell-tel.com, Bell will send to
port 5004 at boston.bell-tel.com.
By default, the media session is one RTP session. Watson will receive
RTCP packets on port 5005, while Bell will receive them on port 3457.
Since the two sides have agreed on the set of media, Bell confirms
the call without enclosing another session description:
C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 ACK
16.4 Terminating a Call
To terminate a call, caller or callee can send a BYE request:
C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 2 BYE
If the callee wants to abort the call, it simply reverses the To and
From fields. Note that it is unlikely that a BYE from the callee will
traverse the same proxies as the original INVITE.
16.5 Forking Proxy
In this example, Bell (a.g.bell@bell-tel.com) (C), currently seated
at host c.bell-tel.com wants to call Watson (t.watson@ieee.org). At
the time of the call, Watson is logged in at two workstations,
t.watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has
registered with the IEEE proxy server (P) called sip.ieee.org. The
IEEE server also has a registration for the home machine of Watson,
at watson@h.bell-tel.com (H), as well as a permanent registration at
watson@acm.org (A). For brevity, the examples omit the session
description and Via header fields.
Bell's user agent sends the invitation to the SIP server for the
ieee.org domain:
C->P: INVITE sip:t.watson@ieee.org SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
The SIP server at ieee.org tries the four addresses in parallel. It
sends the following message to the home machine:
P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
This request immediately yields a 404 (Not Found) response, since
Watson is not currently logged in at home:
H->P: SIP/2.0 404 Not Found
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
The proxy ACKs the response so that host H can stop retransmitting
it:
P->H: ACK sip:watson@h.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=1
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=87454273
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
Also, P attempts to reach Watson through the ACM server:
P->A: INVITE sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
In parallel, the next attempt proceeds, with an INVITE to X and Y:
P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
As it happens, both Watson at X and a colleague in the other lab at
host Y hear the phones ringing and pick up. Both X and Y return 200s
via the proxy to Bell.
X->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=3
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> ;tag=192137601
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Contact: sip:t.watson@x.bell-tel.com
Y->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=4
Via: SIP/2.0/UDP c.bell-tel.com
Contact: sip:t.watson@y.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org> ;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Both responses are forwarded to Bell, using the Via information. At
this point, the ACM server is still searching its database. P can now
cancel this attempt:
P->A: CANCEL sip:watson@acm.org SIP/2.0
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 CANCEL
The ACM server gladly stops its neural-network database search and
responds with a 200. The 200 will not travel any further, since P is
the last Via stop.
A->P: SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.ieee.org ;branch=2
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>
Call-ID: 31415@c.bell-tel.com
CSeq: 1 CANCEL
Bell gets the two 200 responses from X and Y in short order. Bell's
reaction now depends on his software. He can either send an ACK to
both if human intelligence is needed to determine who he wants to
talk to or he can automatically reject one of the two calls. Here, he
acknowledges both, separately and directly to the final destination:
C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=192137601
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 1 ACK
After a brief discussion between Bell with X and Y, it becomes clear
that Watson is at X. (Note that this is not a three-way call; only
Bell can talk to X and Y, but X and Y cannot talk to each other.)
Thus, Bell sends a BYE to Y, which is replied to:
C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 2 BYE
Y->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=35253448
Call-ID: 31415@c.bell-tel.com
CSeq: 2 BYE
16.6 Redirects
Replies with status codes 301 (Moved Permanently) or 302 (Moved
Temporarily) specify another location using the Contact field.
Continuing our earlier example, the server P at ieee.org decides to
redirect rather than proxy the request:
P->C: SIP/2.0 302 Moved temporarily
Via: SIP/2.0/UDP c.bell-tel.com
From: A. Bell <sip:a.g.bell@bell-tel.com>
To: T. Watson <sip:t.watson@ieee.org>;tag=72538263
Call-ID: 31415@c.bell-tel.com
CSeq: 1 INVITE
Contact: sip:watson@h.bell-tel.com,
sip:watson@acm.org, sip:t.watson@x.bell-tel.com,
sip:watson@y.bell-tel.com
CSeq: 1 INVITE
As another example, assume Alice (A) wants to delegate her calls to
Bob (B) while she is on vacation until July 29th, 1998. Any calls
meant for her will reach Bob with Alice's To field, indicating to him
what role he is to play. Charlie (C) calls Alice (A), whose server
returns:
A->C: SIP/2.0 302 Moved temporarily
From: Charlie <sip:charlie@caller.com>
To: Alice <sip:alice@anywhere.com> ;tag=2332462
Call-ID: 27182@caller.com
Contact: sip:bob@anywhere.com
Expires: Wed, 29 Jul 1998 9:00:00 GMT
CSeq: 1 INVITE
Charlie then sends the following request to the SIP server of the
anywhere.com domain. Note that the server at anywhere.com forwards
the request to Bob based on the Request-URI.
C->B: INVITE sip:bob@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: sip:alice@anywhere.com
Call-ID: 27182@caller.com
CSeq: 2 INVITE
In the third redirection example, we assume that all outgoing
requests are directed through a local firewall F at caller.com, with
Charlie again inviting Alice:
C->F: INVITE sip:alice@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 1 INVITE
The local firewall at caller.com happens to be overloaded and thus
redirects the call from Charlie to a secondary server S:
F->C: SIP/2.0 302 Moved temporarily
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 1 INVITE
Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>
Based on this response, Charlie directs the same invitation to the
secondary server spare.caller.com at port 5080, but maintains the
same Request-URI as before:
C->S: INVITE sip:alice@anywhere.com SIP/2.0
From: sip:charlie@caller.com
To: Alice <sip:alice@anywhere.com>
Call-ID: 27182@caller.com
CSeq: 2 INVITE
16.7 Negotiation
An example of a 606 (Not Acceptable) response is:
S->C: SIP/2.0 606 Not Acceptable
From: sip:mjh@isi.edu
To: <sip:schooler@cs.caltech.edu> ;tag=7434264
Call-ID: 14142@north.east.isi.edu
CSeq: 1 INVITE
Contact: sip:mjh@north.east.isi.edu
Warning: 370 "Insufficient bandwidth (only have ISDN)",
305 "Incompatible media format",
330 "Multicast not available"
Content-Type: application/sdp
Content-Length: 50
v=0
s=Let's talk
b=CT:128
c=IN IP4 north.east.isi.edu
m=audio 3456 RTP/AVP 5 0 7
m=video 2232 RTP/AVP 31
In this example, the original request specified a bandwidth that was
higher than the access link could support, requested multicast, and
requested a set of media encodings. The response states that only 128
kb/s is available and that (only) DVI, PCM or LPC audio could be
supported in order of preference.
The response also states that multicast is not available. In such a
case, it might be appropriate to set up a transcoding gateway and
re-invite the user.
16.8 OPTIONS Request
A caller Alice can use an OPTIONS request to find out the
capabilities of a potential callee Bob, without "ringing" the
designated address. Bob returns a description indicating that he is
capable of receiving audio encodings PCM Ulaw (payload type 0), 1016
(payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic
payload type 99), and video encodings H.261 (payload type 31) and
H.263 (payload type 34).
C->S: OPTIONS sip:bob@example.com SIP/2.0
From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com>
Call-ID: 6378@host.anywhere.org
CSeq: 1 OPTIONS
Accept: application/sdp
S->C: SIP/2.0 200 OK
From: Alice <sip:alice@anywhere.org>
To: Bob <sip:bob@example.com> ;tag=376364382
Call-ID: 6378@host.anywhere.org
Content-Length: 81
Content-Type: application/sdp
v=0
m=audio 0 RTP/AVP 0 1 3 99
m=video 0 RTP/AVP 31 34
a=rtpmap:99 SX7300/8000
A Minimal Implementation
A.1 Client
All clients MUST be able to generate the INVITE and ACK requests.
Clients MUST generate and parse the Call-ID, Content-Length,
Content-Type, CSeq, From and To headers. Clients MUST also parse the
Require header. A minimal implementation MUST understand SDP (RFC
2327, [6]). It MUST be able to recognize the status code classes 1
through 6 and act accordingly.
The following capability sets build on top of the minimal
implementation described in the previous paragraph. In general, each
capability listed below builds on the ones above it:
Basic: A basic implementation adds support for the BYE method to
allow the interruption of a pending call attempt. It includes a
User-Agent header in its requests and indicates its preferred
language in the Accept-Language header.
Redirection: To support call forwarding, a client needs to be able to
understand the Contact header, but only the SIP-URL part, not
the parameters.
Firewall-friendly: A firewall-friendly client understands the Route
and Record-Route header fields and can be configured to use a
local proxy for all outgoing requests.
Negotiation: A client MUST be able to request the OPTIONS method and
understand the 380 (Alternative Service) status and the Contact
parameters to participate in terminal and media negotiation. It
SHOULD be able to parse the Warning response header to provide
useful feedback to the caller.
Authentication: If a client wishes to invite callees that require
caller authentication, it MUST be able to recognize the 401
(Unauthorized) status code, MUST be able to generate the
Authorization request header and MUST understand the WWW-
Authenticate response header.
If a client wishes to use proxies that require caller authentication,
it MUST be able to recognize the 407 (Proxy Authentication Required)
status code, MUST be able to generate the Proxy-Authorization request
header and understand the Proxy-Authenticate response header.
A.2 Server
A minimally compliant server implementation MUST understand the
INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also
understand CANCEL. It MUST parse and generate, as appropriate, the
Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-
Forwards, Require, To and Via headers. It MUST echo the CSeq and
Timestamp headers in the response. It SHOULD include the Server
header in its responses.
A.3 Header Processing
Table 6 lists the headers that different implementations support. UAC
refers to a user-agent client (calling user agent), UAS to a user-
agent server (called user-agent).
The fields in the table have the following meaning. Type is as in
Table 4 and 5. "-" indicates the field is not meaningful to this
system (although it might be generated by it). "m" indicates the
field MUST be understood. "b" indicates the field SHOULD be
understood by a Basic implementation. "r" indicates the field SHOULD
be understood if the system claims to understand redirection. "a"
indicates the field SHOULD be understood if the system claims to
support authentication. "e" indicates the field SHOULD be understood
if the system claims to support encryption. "o" indicates support of
the field is purely optional. Headers whose support is optional for
all implementations are not shown.
type UAC proxy UAS registrar
_____________________________________________________
Accept R - o m m
Accept-Encoding R - - m m
Accept-Language R - b b b
Allow 405 o - - -
Authorization R a o a a
Call-ID g m m m m
Content-Encoding g m - m m
Content-Length g m m m m
Content-Type g m - m m
CSeq g m m m m
Encryption g e - e e
Expires g - o o m
From g m o m m
Hide R - m - -
Contact R - - - m
Contact r r r - -
Max-Forwards R - b - -
Proxy-Authenticate 407 a - - -
Proxy-Authorization R - a - -
Proxy-Require R - m - -
Require R m - m m
Response-Key R - - e e
Route R - m - -
Timestamp g o o m m
To g m m m m
Unsupported r b b - -
User-Agent g b - b -
Via g m m m m
WWW-Authenticate 401 a - - -
Table 6: Header Field Processing Requirements
B Usage of the Session Description Protocol (SDP)
This section describes the use of the Session Description Protocol
(SDP) (RFC2327 [6]).
B.1 Configuring Media Streams
The caller and callee align their media descriptions so that the nth
media stream ("m=" line) in the caller's session description
corresponds to the nth media stream in the callee's description.
All media descriptions SHOULD contain "a=rtpmap" mappings from RTP
payload types to encodings.
This allows easier migration away from static payload
types.
If the callee wants to neither send nor receive a stream offered by
the caller, the callee sets the port number of that stream to zero in
its media description.
There currently is no other way than port zero for the
callee to refuse a bidirectional stream offered by the
caller. Both caller and callee need to be aware what media
tools are to be started.
For example, assume that the caller Alice has included the following
description in her INVITE request. It includes an audio stream and
two bidirectional video streams, using H.261 (payload type 31) and
MPEG (payload type 32).
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
c=IN IP4 host.anywhere.com
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
The callee, Bob, does not want to receive or send the first video
stream, so it returns the media description below:
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
c=IN IP4 host.example.com
m=audio 47920 RTP/AVP 0 1
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
B.2 Setting SDP Values for Unicast
If a session description from a caller contains a media stream which
is listed as send (receive) only, it means that the caller is only
willing to send (receive) this stream, not receive (send). The same
is true for the callee.
For receive-only and send-or-receive streams, the port number and
address in the session description indicate where the media stream
should be sent to by the recipient of the session description, either
caller or callee. For send-only streams, the address and port number
have no significance and SHOULD be set to zero.
The list of payload types for each media stream conveys two pieces of
information, namely the set of codecs that the caller or callee is
capable of sending or receiving, and the RTP payload type numbers
used to identify those codecs. For receive-only or send-and-receive
media streams, a caller SHOULD list all of the codecs it is capable
of supporting in the session description in an INVITE or ACK. For
send-only streams, the caller SHOULD indicate only those it wishes to
send for this session. For receive-only streams, the payload type
numbers indicate the value of the payload type field in RTP packets
the caller is expecting to receive for that codec type. For send-only
streams, the payload type numbers indicate the value of the payload
type field in RTP packets the caller is planning to send for that
codec type. For send-and-receive streams, the payload type numbers
indicate the value of the payload type field the caller expects to
both send and receive.
If a media stream is listed as receive-only by the caller, the callee
lists, in the response, those codecs it intends to use from among the
ones listed in the request. If a media stream is listed as send-only
by the caller, the callee lists, in the response, those codecs it is
willing to receive among the ones listed in the the request. If the
media stream is listed as both send and receive, the callee lists
those codecs it is capable of sending or receiving among the ones
listed by the caller in the INVITE. The actual payload type numbers
in the callee's session description corresponding to a particular
codec MUST be the same as the caller's session description.
If caller and callee have no media formats in common for a particular
stream, the callee MUST return a session description containing the
particular "m=" line, but with the port number set to zero, and no
payload types listed.
If there are no media formats in common for all streams, the callee
SHOULD return a 400 response, with a 304 Warning header field.
B.3 Multicast Operation
The interpretation of send-only and receive-only for multicast media
sessions differs from that for unicast sessions. For multicast,
send-only means that the recipient of the session description (caller
or callee) SHOULD only send media streams to the address and port
indicated. Receive-only means that the recipient of the session
description SHOULD only receive media on the address and port
indicated.
For multicast, receive and send multicast addresses are the same and
all parties use the same port numbers to receive media data. If the
session description provided by the caller is acceptable to the
callee, the callee can choose not to include a session description or
MAY echo the description in the response.
A callee MAY, in the response, return a session description with some
of the payload types removed, or port numbers set to zero (but no
other value). This indicates to the caller that the callee does not
support the given stream or media types which were removed. A callee
MUST NOT change whether a given stream is send-only, receive-only, or
send-and-receive.
If a callee does not support multicast at all, it SHOULD return a 400
status response and include a 330 Warning.
B.4 Delayed Media Streams
In some cases, a caller may not know the set of media formats which
it can support at the time it would like to issue an invitation. This
is the case when the caller is actually a gateway to another protocol
which performs media format negotiation after call setup. When this
occurs, a caller MAY issue an INVITE with a session description that
contains no media lines. The callee SHOULD interpret this to mean
that the caller wishes to participate in a multimedia session
described by the session description, but that the media streams are
not yet known. The callee SHOULD return a session description
indicating the streams and media formats it is willing to support,
however. The caller MAY update the session description either in the
ACK request or in a re-INVITE at a later time, once the streams are
known.
B.5 Putting Media Streams on Hold
If a party in a call wants to put the other party "on hold", i.e.,
request that it temporarily stops sending one or more media streams,
a party re-invites the other by sending an INVITE request with a
modified session description. The session description is the same as
in the original invitation (or response), but the "c" destination
addresses for the media streams to be put on hold are set to zero
(0.0.0.0).
B.6 Subject and SDP "s=" Line
The SDP "s=" line and the SIP Subject header field have different
meanings when inviting to a multicast session. The session
description line describes the subject of the multicast session,
while the SIP Subject header field describes the reason for the
invitation. The example in Section 16.2 illustrates this point. For
invitations to two-party sessions, the SDP "s=" line MAY be left
empty.
B.7 The SDP "o=" Line
The "o=" line is not strictly necessary for two-party sessions, but
MUST be present to allow re-use of SDP-based tools.
C Summary of Augmented BNF
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) similar to that
used by RFC822 [9]. Implementors will need to be familiar with the
notation in order to understand this specification. The augmented BNF
includes the following constructs:
name = definition
The name of a rule is simply the name itself (without any enclosing
"<" and ">") and is separated from its definition by the equal "="
character. White space is only significant in that indentation of
continuation lines is used to indicate a rule definition that spans
more than one line. Certain basic rules are in uppercase, such as SP,
LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within
definitions whenever their presence will facilitate discerning the
use of rule names.
"literal"
Quotation marks surround literal text. Unless stated otherwise, the
text is case-insensitive.
rule1 | rule2
Elements separated by a bar ("|") are alternatives, e.g., "yes | no"
will accept yes or no.
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element.
Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo
elem" and "elem bar elem".
*rule
The character "*" preceding an element indicates repetition. The full
form is "<n>*<m>element" indicating at least <n> and at most <m>
occurrences of element. Default values are 0 and infinity so that
"*(element)" allows any number, including zero; "1*element" requires
at least one; and "1*2element" allows one or two.
[rule]
Square brackets enclose optional elements; "[foo bar]" is equivalent
to "*1(foo bar)".
N rule
Specific repetition: "<n>(element)" is equivalent to
"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
alphabetic characters.
#rule
A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m> element" indicating at least <n>
and at most <m> elements, each separated by one or more commas (",")
and OPTIONAL linear white space (LWS). This makes the usual form of
lists very easy; a rule such as
( *LWS element *( *LWS "," *LWS element ))
can be shown as 1# element. Wherever this construct is used, null
elements are allowed, but do not contribute to the count of elements
present. That is, "(element), , (element)" is permitted, but counts
as only two elements. Therefore, where at least one element is
required, at least one non-null element MUST be present. Default
values are 0 and infinity so that "#element" allows any number,
including zero; "1#element" requires at least one; and "1#2element"
allows one or two.
; comment
A semi-colon, set off some distance to the right of rule text, starts
a comment that continues to the end of line. This is a simple way of
including useful notes in parallel with the specifications.
implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear white space (LWS) can be included
between any two adjacent words (token or quoted-string), and between
adjacent tokens and separators, without changing the interpretation
of a field. At least one delimiter (LWS and/or separators) MUST exist
between any two tokens (for the definition of "token" below), since
they would otherwise be interpreted as a single token.
C.1 Basic Rules
The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set
is defined by ANSI X3.4-1986.
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
alpha = lowalpha | upalpha
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
alphanum = alpha | digit
CTL = <any US-ASCII control character
(octets 0 -- 31) and DEL (127)>
CR = %d13 ; US-ASCII CR, carriage return character
LF = %d10 ; US-ASCII LF, line feed character
SP = %d32 ; US-ASCII SP, space character
HT = %d09 ; US-ASCII HT, horizontal tab character
CRLF = CR LF ; typically the end of a line
The following are defined in RFC2396 [12] for the SIP URI:
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'"
| "(" | ")"
escaped = "%" hex hex
SIP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream.
LWS = [CRLF] 1*( SP | HT ) ; linear whitespace
The TEXT-UTF8 rule is only used for descriptive field contents and
values that are not intended to be interpreted by the message parser.
Words of *TEXT-UTF8 contain characters from the UTF-8 character set
(RFC2279 [21]). In this regard, SIP differs from HTTP, which uses
the ISO 8859-1 character set.
TEXT-UTF8 = <any UTF-8 character encoding, except CTLs,
but including LWS>
A CRLF is allowed in the definition of TEXT-UTF8 only as part of a
header field continuation. It is expected that the folding LWS will
be replaced with a single SP before interpretation of the TEXT-UTF8
value.
Hexadecimal numeric characters are used in several protocol elements.
hex = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | digit
Many SIP header field values consist of words separated by LWS or
special characters. These special characters MUST be in a quoted
string to be used within a parameter value.
token = 1*< any CHAR except CTL's or separators>
separators = "(" | ")" | "<" | ">" | "@" |
"," | ";" | ":" | "\" | <"> |
"/" | "[" | "]" | "?" | "=" |
"{" | "}" | SP | HT
Comments can be included in some SIP header fields by surrounding the
comment text with parentheses. Comments are only allowed in fields