. 119
( 132 .)


the message reliability mechanism must be provided for each of the messages sent down
a different branch. As more than one 200 OK message can be received, the originating
UA needs to be able to distinguish between calls to different UAs belonging to the same
user (i.e. registered with the same SIP URI).
To achieve this distinction the For and To headers carry a 32-bit random identi¬er
called a tag. The tag on the To header is to distinguish between different UAs responding
to the same INVITE. On the From header, the tag is used to separate different UAs using
the same SIP URI as a source address. The format of the tag is as follows:

From: <sip:kjones@sip.org>; tag = 34231234
To: <sip:seb@vodafone.com>; tag = a5bfcc789

If a UA receives a provisional response (e.g. 180 RINGING) from more than one des-
tination it can choose which user to talk to by dropping other calls using the CANCEL
command. However, if a UA receives more than one 200 OK response from different
destinations the UA must acknowledge each with the ACK message (otherwise the ter-
minating UA will keep sending the 200 OK). For users that the UA does not want to talk
to the call can be then terminated using the BYE message. SIP routing with path header (RFC 3327)
The use of the path header allows calls routed from the home network to the UA to follow
a ¬xed path. The use of the path header is very much like the record-route in that each
proxy server that wants to be included on the path between the sender and receiver will

Home network

UAx Proxy A Proxy B

path : proxy A
path : proxy A
path : proxy B

Route: <sip:proxy B>,<sip:proxy A>

Figure 9.17 Use of path header

add a path header containing their own address. The difference is that the path header is
only used with registration requests and is valid for all SIP messages being routed from
the user™s home network to the SIP user for the lifetime of that registration. This process
is illustrated in Figure 9.17. User x sends a registration request to the home network.
The proxies along the route both add path headers to the request before forwarding it.
The home registrar then stores the contact for the SIP user as well as the associated path
information. When an INVITE for the user arrives at the home proxy, it is forwarded via
the intermediary proxies using the route header.

9.5.16 Provision of QoS with SIP
When SIP is used to set up multimedia streams across the network there is a requirement
for QoS to be also provided. In fact, SIP itself does not provide QoS mechanisms but
it does provide information via the SDP content about the service requirements. Each
proxy server in the call path, by looking at the SDP content in the INVITE and 200 OK
messages, can determine the required bandwidth and request the QoS in its part of the
network. A number of extensions to SDP have been proposed to allow the UAs to signal
their media streams™ QoS requirements. These are outlined in RFC 3312.
However, there is a problem establishing QoS with the standard SIP INVITE transac-
tion. The QoS requirements cannot be determined until the answer to the SDP offer in the
INVITE has been returned in the response coming from the called party (e.g. 180 RING-
ING or 200 OK response). At this point the called party™s UA will already be ringing.
If the QoS request is rejected then the initiating UA will CANCEL the call; however,
in the meantime, there may be ˜ghost™ ringing at the called party™s UA. This problem
is illustrated in Figure 9.18. The dif¬culty is that the destination UA should not proceed
with alerting the end user until QoS has been established for the call. What is needed is
a system to precondition the link before the remote UA starts to alert the user.
A mechanism for enabling QoS preconditioning with SIP is described in RFC 3312
˜Integration of Resource Management and Session Initiation Protocol (SIP)™. The process
operates in very much the same manner that media options are negotiated in a basic SIP

SIP proxy
SIP User Agent SIP User Agent
200 OK
200 OK
Phone rings
QoS is now known, is but no
negotiated and rejected answer yet

Figure 9.18 Ghost ringing problem

call, i.e. by using an offer/answer model, but in this case the handshake will usually be

1. UAa offers UAb a range of media streams; QoS is also requested.
2. UAb replies with answer con¬rming which media streams it would like to use as
well as its QoS requirements.
3. UAa and UAb perform QoS reservation; UAa con¬rms QoS reservation to UAb, and
UAb alerts user B.

The call ¬‚ow for this example is shown in Figure 9.19. For step 1, the original offer
is sent in the INVITE message; the SDP also contains the request for the QoS. The SDP
for the answer in step 2 is sent using the 183 session progress response, SDP2. Since this
message is crucial to the call, it must be sent reliably, and to achieve this the provisional
acknowledgement message PRACK is used.
The 183 response will be retransmitted until a PRACK is received by UAb. Once the
183 message has been received by UAa, it can request the QoS from its own access
network. When UAa receives local con¬rmation of its QoS request, it sends the UPDATE
message containing SDP3. This contains the con¬rmed QoS provision. This UPDATE
message (RFC 3311) is designed to allow details about the media stream to be updated
without modifying the SIP call state. As well as QoS provision, UPDATE can be used
to control early media streams (for example when sending call progression signalling in-
band). At UAb, as soon as the local QoS request is con¬rmed and the UPDATE message
received, the user can be alerted and the call proceeds as normal.
Table 9.5 shows the format of the SDP QoS parameters used in the call.


request QoS

183 Session Progress (SDP2)

request QoS

200 OK (for PRACK)

confirm QoS
confirm QoS

200 OK (for UPDATE)(SDP4)


200 OK (for INVITE)


RTP multimedia session

Figure 9.19 SIP call with QoS establishment

Table 9.5 SDP QoS parameters
Parameter Description
Mode This can be send, receive, sendrecv or none. This indicates the direction of the
¬‚ow of media for the QoS. For none, this indicates that no QoS has been
established for the stream to date.
The type can be local, remote or e2e (or end-to-end). This parameter refers to the
network in which the QoS is to be requested. For each UA, local means the
UA™s local access network and remote means its peer™s local access network.
e2e is used if the QoS can be established by either UA across the whole link as
one request.
Strength This indicates how critical the establishment of QoS is for the progress of the
call. Possible values here are none, optional and mandatory. For a call to
proceed, all mandatory QoS requests have to be satis¬ed. The optional strength
allows the UA to request QoS establishment but the call may proceed if even if
the request is denied.

For each SDP message two attributes are de¬ned;
a = curr:qos the current status of the QoS.
a = des:qos the desired status of the QoS indicating the parties™ QoS requirements

The QoS requirement is de¬ned by three parameters “ mode, strength and type “ which
are described in Table 9.5.
The parties negotiate the desired status (indicated by a = des:qos) in the initial exchange
(i.e. INVITE/183 session progress). For each exchange, the UA is allowed to upgrade but
not downgrade the QoS requirements of the call by modifying the a = des:qos ¬eld. If
UAa sends a = des:qos remote none this indicates that it has no requirement for QoS in
the remote network; UAb could reply with a = des:qos mandatory sendrecv, indicating
that QoS is a mandatory requirement for both sending and receiving. Note that the use
of local and remote is with respect to the message sender.
The current status of the QoS establishment is also agreed as the SDP is sent back and
forth. Each end can upgrade the a = curr:qos ¬eld dependent on local information.
For the call to proceed, the current status of the QoS has to satisfy the desired QoS
requirements negotiated. For mandatory strength requirements the QoS must be provided;
if the desired strength is optional the QoS should be requested but the call may proceed
even if it is denied. Use of the mode parameter is as follows: a send requirement is
satis¬ed by a current QoS status with mode set to send or sendrecv, for a receive require-
ment the current status must be receive or sendrecv, and for a sendrecv requirement only
sendrecv will suf¬ce.
For example, if a UA sets a mandatory requirement that send QoS is achieved end-to-
end, in the direction of send from this UA, the SDP would be a = des:qos mandatory e2e
send. If it then receives a current QoS status update indicating end-to-end QoS has been
established in both directions indicated by a = curr:qos e2e sendrecv, the QoS requirement
will have been satis¬ed and the call can proceed.
Consider the example exchange shown in Figure 9.20. In the ¬rst message, the INVITE
SDP, UAa is requesting a video stream. For this stream, it is stating that it requires a
sendrecv QoS in its own access network (des:qos local mandatory). Currently, no QoS has
been allocated (curr:qos local none). In the next SDP message (183 session progress),
UAb signals that it requires QoS to be allocated within its own local access network
(des:qos local mandatory). Notice that the meaning of local and remote are relative, i.e.
local refers to the access network of the sender of a message.
In the UPDATE message, UAa informs UAb of the successful allocation of QoS in
its access network by sending curr:qos local sendrecv. Finally, the 200 OK message
contains a con¬rmation that UAb has also established QoS in its local network (curr:qos
local sendrecv ).
At each point in the offer/answer exchange of QoS parameters, the UAs are free to
upgrade (but not downgrade) the QoS requirements and current status. For example, a
desired QoS which is send optional could be upgraded to sendrecv mandatory. Down-
grading QoS parameters is not allowed since this would allow either UA peer to deny
QoS to the other.
If either party cannot provide QoS mandated by the other, either because of lack
of resources, local policy or lack of support for QoS, the call should be dropped.

m=video 23101 RTP/AVP 31
a=rtpmap: 31 H261/90000
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv

183 Session Progress
m=video 23101 RTP/AVP 31
a=rtpmap: 31 H261/90000
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

m=video 23101 RTP/AVP 31
a=rtpmap: 31 H261/90000
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

200 OK
m=video 23101 RTP/AVP 31
a=rtpmap: 31 H261/90000
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv


. 119
( 132 .)