. 116
( 132 .)


9.5.3 SIP messages

Basic SIP performs all its functionality with only six basic message types called methods,
as de¬ned in RFC 3261, but supports a growing number of extensions covered by other
RFCs or Internet drafts. The main methods are as shown in Table 9.2.
INVITE and ACK are used for basic SIP call setup. INVITE initiates the call and
ACK is used to acknowledge the ¬nal response to the original INVITE. BYE is used to
terminate a call when one of the parties hangs up. CANCEL is used to terminate a call that
is currently being established. For example, if the called party™s phone is ringing and the
caller hangs up, CANCEL can be used to indicate that the INVITE is no longer requested.
REGISTER is used by a UA wishing to indicate their location and availability to
the registrar server. Registration will occur on UA start-up as well as when the user is
relocating to another network domain (for example when roaming in a visited network).
OPTIONS allows a UA to determine the capabilities (for example, which CODECs are
supported) of either the UA being called or a proxy server.
The INFO request carries application signalling which does not affect the state of the
SIP call. Examples of this signalling could be dual tone multi-frequency (DTMF) digits,
account balance information or mid-call PSTN signalling between gateways.
PRACK (provisional acknowledgement) is an extra message allowing for the provi-
sional response messages to be acknowledged. Usually 1xx messages (see Section 9.5.4)
are carried in an unreliable manner. This message allows provisional responses to be
delivered reliably and is used in UMTS to ensure the delivery of responses such as 180
RINGING (indicating that the called UA is alerting the user).
The UPDATE method is used to allow modi¬cation of media information about the ses-
sion before it has been fully established. It is used principally to indicate QoS parameters
that have been successfully negotiated for the session.

Table 9.2 SIP methods
Method Function RFC or draft
INVITE Call setup RFC 3261
ACK Acknowledgement for response
BYE Call termination
CANCEL Cancel call
REGISTER Register URL with SIP server
OPTIONS Check for capabilities
INFO Midcall signaling RFC 2976
PRACK Provisional acknowledgement RFC 3262
UPDATE Modify session information RFC 3311
REFER Transfer user to a URL Draft-ietf-sip-
SUBSCRIBE Requests noti¬cation of an RFC 3265
NOTIFY Event noti¬cation RFC 3265
MESSAGE Transports instant message RFC 3428

The REFER message is used to instruct a UA to establish a session with a third
party. It can be used to support various supplementary services such as call transfer or
The SUBSCRIBE and NOTIFY methods support event noti¬cation. Events can be used,
for example, to indicate new incoming email or a SIP UA becoming available after being
busy. Event handling can also be used for presence detection for an instant messaging
application. A SUBSCRIBE message is sent by a UA to another UA; within the request
is a series of events that the sender wants to be noti¬ed of. The NOTIFY message is used
to indicate the occurrence of the event to the listening UA.
Finally, the MESSAGE method is used to support instant messaging. It allows a short
message to be sent from UA to UA without the need for session establishment. The
messages are presented in multi-part MIME format (similar to email) and can contain
multimedia as attachments. Instant messages in SIP can be delivered directly to their
destination or via a message relay. In the latter case, again very much like email, the
message is stored before being forwarded at a later time.

9.5.4 SIP responses
For each method, a SIP entity can respond to a request with a range of response codes
organized into six classes, as shown in Table 9.3.
The 1xx provisional or informational responses are sent back when a request has been
received and is being processed to indicate something about the progression of the call.
For example, 180 RINGING tells the UA that the called party™s phone is ringing; 100
TRYING indicates that the server is trying to contact the called party. All the other codes
(2xx“6xx) are referred to as ¬nal response codes and indicate the end of the transaction.
Each provisional response is expected at some later time to be followed up by a ¬nal
response code.
The 2xx success responses indicate that the command has been successful. Currently
there is only one 2xx response, 200 OK. 3xx responses are sent to indicate that the client
should try to recontact the called party at a different location, as indicated in the response.
For example, response 301 tells the calling party the new contact address is permanent,

Table 9.3 SIP response code classes
Class Description Examples

1xx Provisional/ Request received processing response 100 TRYING
informational 180 RINGING
2xx Success Request successful 200 OK
3xx Redirection Redirect client to try another location 301 Moved permanently
302 Moved temporarily
4xx Client error Bad syntax in message, client should 407 Proxy unauthorized
rephrase request 404 Not found
5xx Server error Problem with server 503 Service unavailable
6xx Global error Error information about called party 603 Decline

302 is used for temporary redirection (when a user is roaming in a visited network). 4xx,
5xx and 6xx responses indicate certain error conditions. 4xx are sent back if there is a
problem with the request from the client. For example, 407 proxy unauthorized indicates
that authentication information is required with the request; 404 not found indicates that
the user does not exist at the domain given. 5xx server responses indicate an error at the
server. A server replies with 503 service unavailable to indicate that it cannot satisfy the
request at this time. The client is expected to try another server or re-try the request at a
later time. Finally, the 6xx global errors indicate error information about the called party.
For example, 603 decline indicates that the called user was not willing to accept the call.

9.5.5 SIP transaction handling
Each SIP transaction consists of a request followed by one or more provisional responses
(1xx) and then one or more ¬nal responses (2xx, 3xx, 4xx, 5xx or 6xx). Since SIP can
use user datagram protocol (UDP) or transmission control protocol (TCP) for transport, a
reliability mechanism must be included so that messages are not lost. For SIP messages
over UDP the message is retransmitted if a response is not received within a given time
interval. The time interval starts off set to T1 (default value 500 ms), and after each
retransmission the timeout interval is doubled up to a maximum value of T2 (default
4 s). For all requests apart from INVITE, the retransmission will continue until the ¬nal
response is received. This ensures that the ¬nal response is received by the initiator of
the SIP transaction. For the INVITE request the retransmission stops as soon as the ¬rst
provisional response is received; in this case the use of the extra ACK message ensures
delivery of the ¬nal response. The special use of the ACK message is covered in more
detail later.
In certain circumstances it is important to deliver provisional responses reliably. In a
telecommunications network it is important that call progression messages such as 180
RINGING or 183 CALL PROGRESS are always delivered. To ensure this takes place
the sender of the provisional response sets the require header of the response message
as follows:
Require: 100rel

When the UA receives the response it is expected to acknowledge it. This is done using
PRACK, which in turn will also require a ¬nal response, which, assuming there is no
error condition, will be 200 OK.

9.5.6 SIP message transport
All SIP elements must support both TCP and UDP; for security transport layer security
(TLS) can be used over TCP. TCP provides reliability but introduces an extra overhead
in terms of connection establishment prior to sending the message. The reliability for
TCP however is not needed since SIP provides its own retransmission mechanism. UDP
transport has a lower overhead but does not provide congestion and ¬‚ow control.

9.5.7 SIP server discovery
For the UA to gain service from the network, it must ¬rst establish the IP address and port
number of the local proxy or registrar server to send the request to. The address of these
can be con¬gured manually or discovered dynamically. The dynamic host con¬guration
protocol (DHCP) can be used to allocate the address of SIP servers on the attached network
(RFC 3361). If the address returned by DHCP is a domain name then the domain name
system (DNS) can be used to resolve this still further. The facilities of the local server
(registrar, proxy, etc.) can be discovered by use of the SIP options request.
In dynamic server discovery (RFC 3263), the DNS naming authority pointer (NAPTR)
mechanism is used to discover the URIs of SIP servers in a given domain. This allows
messages to be forwarded from the outgoing proxy to the destination given in the request™s
URI. These URIs are then resolved into IP address and port number using the DNS SRV
(server) resolution mechanism. If no port number is de¬ned in the DNS resource record
then the default values of 5060 for TCP or UDP and 5061 for TLS are used.
The source port number for the requests originating from the UA is assigned by the UA
when the message is generated. The proxy server is expected to send responses back to
the same port. The port number for requests terminated at the UA can be de¬ned as part
of the user™s contact address URI. Again, the values 5060 and 5061 are used as default
if no port number is speci¬ed.
Finally, an extra mechanism is available for registrars. These servers can be addressed
by the multicast address sip.mcast.net (; the port number will be 5060.
In summary, DHCP and DNS can be used to con¬gure the local SIP server (proxy and
registrar) addresses for a UA. DNS NAPTR and SRV records are then used by proxies
to discover the address and port numbers of remote SIP servers where requests should
be forwarded.

9.5.8 SIP headers
Table 9.4 shows a SIP request INVITE message. The format of the initial line is METHOD
Request-URI SIP-Version (the format is similar for the response message but with the
request method replaced by the response code). The current version of SIP is 2.0.
Each line of the request is followed by a carriage return (CR) and line feed (LF). After
the initial request line comes a series of ¬elds or headers which act as parameters to
the method. Via
Every time a message is received by a SIP server, it adds its own address to the beginning
of the list in the Via header before forwarding the message. This information allows the
response to be sent back along the same route as the original request. As the response
is routed back each proxy along the route removes its own Via header from the top of
the list; it then sends the response back to the address indicated by the new value at the
beginning of the list.

Table 9.4 SIP INVITE example
Message line Description
INVITE sip:seb@orbitage.com SIP/2.0 Request to start call to seb in domain
Via: SIP/2.0 TCP Who this request is directly from
To: seb@orbitage.com Destination of INVITE
From: jeff@orbitage.com Source of INVITE
Call-ID 12323121212: Random integer plus source host (globally
Max-forwards Integer giving maximum number of times the
request can be forwarded by a server
Cseq: 314159 INVITE Sequence number
Content-Length : 100 Length of SDP data
Empty line
v=0 SDP version number
O = sebcoope 345667 345668 IN IP4 o = originator of session
S = sales meeting s = subject heading
I = Sales meeting about new VoIP product i = information about session
U = www.orbitage.com/sales/conf1.html u = url for session
T = 456789 458900 t = time limits for session
C = IN IP4 c = contact address
e = seb@orbitage.com e = email contact address
m = video 45670 RTP/AVP 31 m = media descriptor
b = 20 b = bandwidth requirements
Empty line

Each Via header also contains a branch parameter, which must be globally unique for
each transaction. One common way of calculating the value is to perform a cryptographic
hash on the values in the following headers: To, From, Call-ID, the Request-URI, the
topmost Via header, Cseq, Proxy-Require and Proxy-Authorization. For RFC 3261 all
branch values must start with z9hG4bK. This is to distinguish them from branch values
generated by implementations compliant with the earlier SIP speci¬cation RFC 2543
(which does not require global uniqueness). The branch value is used as a transaction ID.
For a UA or stateful proxy it allows responses to be matched with requests. It can also
be used by SIP proxies in routing loop detection. Record-route and route
The record-route header can be used by a proxy to request that future requests for a given
dialogue will be sent via this proxy. This is different from the Via header in three ways:
its use is optional, it is used to route requests (not responses) and its lifespan is over
a given SIP session, not just one transaction. The route header is used to enforce the
route of the message over a set of proxies. Here is an example of its use. First the call
is established with an INVITE message from sebcoope to jsmith. The INVITE received
is as follows:

INVITE sip:jsmith@vodafone.net SIP/2.0
Contact: sip:sebcoope@orbitage.com
Record-Route: <sip:proxy.vodafone.net>
Record-Route: <sip:proxy.maxis.net>
Record-Route: <sip:proxy.orbitage.com>
to which jsmith responds with a 200 OK. Later, jsmith terminates the call using a BYE
request as follows, which it sends to proxy.vodafone.com, the ¬rst in the list:
BYE sip:sebcoope@orbitage.com SIP/2.0
Route: <sip:proxy.vodafone.net>
Route: <sip:proxy.maxis.net>
Route: <sip:proxy.orbitage.com>
The proxy at vodafone.net will strip out its route header and forward the request to the
next in the list (the proxy at maxis). The BYE will now look like this:
BYE sip:sebcoope@orbitage.com SIP/2.0
Route: <sip:proxy.maxis.net>
Route: <sip:proxy.orbitage.com>
The use of route and record-route is important for proxies that need to be informed
about both the start and end of a session. For example, a proxy accounting for usage in a
visited network would need to be informed when the session was terminated so that the
CDR can be updated correctly. To and from
To and from are the ¬nal destination and source of the SIP request. Unlike the URI in the
¬rst line of the SIP message, these ¬elds are not modi¬ed as the message is forwarded
between the SIP servers.


. 116
( 132 .)