<<

. 117
( 132 .)



>>

9.5.8.4 Call-ID
This is set to a unique integer for each call so that the request and response codes can be
matched for a particular call.


9.5.8.5 Max-forwards
This ¬eld is used to stop SIP messages looping the network inde¬nitely in case of a
routing error. The ¬eld is decremented by each SIP server that receives the message. If
574 RELEASE 5 AND BEYOND (ALL-IP)


the ¬eld reaches zero, the server will not forward the message and will return a 483 Too
Many Hops to the source. The default value for this ¬eld is 70.


9.5.8.6 CSeq
This is a traditional sequence number used to match requests with responses and is
incremented for each new SIP request. The CSeq header contains not only the sequence
number, but the method of the original request.


9.5.8.7 Content-length
This has the same meaning as its equivalent in the HTTP protocol, and indicates the
length of the data following this request.


9.5.8.8 Content-type
The content type describes the format of the content as a MIME content type. For call
establishment messages within UMTS the content is an SDP description of the session
and the type is set to application/sdp. For other SIP messages the contents will vary
depending on the message type.


9.5.8.9 Contents
The headers are followed by an empty line containing just the CR/LF sequence and then
by a contents section. The contents section of a SIP INVITE request contains information
about the session requested (i.e. type of media, voice or video, data rate requested, port
number for RTP session). The parameters are as according to the session description
protocol (SDP) protocol, as was de¬ned in Chapter 8. The media being requested (or
offered) by the caller in the example shown in Table 9.4 is a video session using UDP
port number 45670 and RTP payload type 31, i.e. video encoded with the H.261 CODEC
(m = video 45670 RTP/AVP 31).



9.5.9 SIP call establishment
A standard SIP call setup, as shown in Figure 9.8 consists of a three-way handshake.
First the initiator sends an INVITE message to the recipient. The recipient can respond
to the INVITE with a range of responses (provisional or ¬nal). In the example given,
the phone starts ringing and responds with a RINGING information message. When the
phone is picked up the call is accepted and 200 OK is sent back to the initiator. Finally,
the calling UA sends an ACK back to the recipient to complete the call setup. Note,
since the ACK is part of the original INVITE sequence it contains the same CSeq value.
9.5 SESSION INITIATION PROTOCOL (SIP) 575




SIP User Agent SIP User Agent
INVITE

180 RINGING

200 OK

ACK

RTP multimedia session

BYE

200 OK


Figure 9.8 SIP call example

These SIP messages will include the SDP data, which will negotiate parameters for this
particular call such as which CODEC to use.
Once the session is established, multimedia packets can be transferred between the
two end points using the real-time transport protocol (RTP). When the call is ¬nished the
BYE message is sent which instructs the other SIP user that the call should be terminated.
Finally, 200 OK is sent back to complete the call termination.

9.5.9.1 ACK request
For the INVITE request a large delay can occur between the user™s phone ringing (180
RINGING) and the call being answered (200 OK). If the request was repeated until the
¬nal response a lot of unnecessary retransmissions of the INVITE would occur before the
call was answered. To overcome this problem the sender of the INVITE stops retransmit-
ting as soon as the ¬rst provisional (or ¬nal) response is received.
At this point in time the sender can be sure the original request has been delivered
(or in the case of a stateful proxied request, accepted for delivery). Once the phone is
answered the 200 OK is sent back to the originating UA. If the 200 OK message is lost
in transmission, however, the calling UA would not know the call has been answered and
continue to play the ringing tone, causing the call to fail. The use of the ACK message
ensures the delivery of the 200 OK message. The called UA will therefore continue to
retransmit the 200 OK until the ACK is received.


9.5.10 Cancel
CANCEL is used to terminate a SIP transaction before it is completed, i.e. before the
¬nal response has been received. This request should only be used for INVITE requests
576 RELEASE 5 AND BEYOND (ALL-IP)




SIP User Agent SIP User Agent
INVITE

180 RINGING

CANCEL

200 OK (for CANCEL)

487 Request Terminated (INVITE)

ACK


Figure 9.9 CANCEL example

because all other requests are expected to be completed without delay. Figure 9.9 shows
a call cancelled before being answered because the caller has given up. The CANCEL
is sent; the 200 OK acknowledges the CANCEL. The called UA then cancels the call
and sends the 487 request terminated in response to the original INVITE. The calling UA
then sends the ACK in reply to the ¬nal 487 response.



9.5.11 Call establishment via proxy
Users within the IMS are expected to establish calls via a proxy server since it provides
functions such as user authentication, accounting control and call routing (in particular
mobility management). Figure 9.10 shows the call setup but this time with the messages
being forwarded via a proxy. In this case, another response, 100 TRYING, is sent by the
proxy to tell the UA that the request has been received and the call setup is in progress.



9.5.12 Stateless and stateful proxies
A stateless proxy only forwards the message it receives and does not take part in the
client/server transaction. A stateful proxy, on the other hand, acts as a server for client
requests it receives and a client for requests it forwards. The proxy shown in Figure 9.10
is stateful, since it accepts the SIP call on the UA™s behalf and generates the 100 TRYING
provisional response in reply. In this transaction the UAC of the caller is the client and
the proxy acts as the server. The proxy then forwards the request acting as a SIP client in
respect of the called UAS. The reliability of the message transfer is ensured hop-by-hop
since the proxy will retransmit the INVITE message as part of its SIP transaction if the
called party does not respond within the timeout period.
9.5 SESSION INITIATION PROTOCOL (SIP) 577




SIP proxy
SIP User Agent SIP User Agent
INVITE
INVITE
100 TRYING
180 RINGING
180 RINGING
200 OK
200 OK

ACK
ACK

RTP multimedia session
BYE
BYE

200 OK
200 OK


Figure 9.10 SIP call via proxy

Figure 9.11 shows how the same call would look for a stateless proxy. In this case
the proxy will not generate the 100 TRYING message and the reliability mechanism is
ensured end-to-end instead of hop-by-hop. This creates a problem if a stateless proxy
receives a message using TCP in its ¬rst link and uses UDP on its second. The sending
UA is using a reliable transport mechanism and will not retransmit its INVITE message
to the proxy. If the proxy then sends the message using UDP and it is lost in transit, it
will not retransmit, causing the call to fail. For this reason when a proxy server forwards
a message using a different transport from the one which it is received on, some action
is required by the proxy to ensure reliable delivery, i.e. the proxy must act statefully.


9.5.13 SIP offer/answer model
SIP uses an offer/answer model to negotiate media options between end points. This
procedure is formally de¬ned in RFC 3264. The protocol operates as follows:

• the initiator provides a series of media options in the initial SDP offer;
• the responder answers with its choice of media.

The original offer can be carried in the INVITE request, or, if omitted by the sender,
the called party must include the offer in the 200 OK response. If the original offer is
578 RELEASE 5 AND BEYOND (ALL-IP)




SIP proxy
SIP User Agent SIP User Agent
INVITE
INVITE

180 RINGING
180 RINGING
200 OK
200 OK

ACK
ACK

RTP multimedia session
BYE
BYE

200 OK
200 OK


Figure 9.11 Call setup using stateless proxy


carried in the INVITE message then the answer must be carried in the 200 OK response.
The answer can also optionally be included in the provisional 1xx responses. If, on the
other hand, the original offer is made in the 200 OK response, the answer will be carried
within the ACK message.
Figure 9.12 shows two offer/answer examples. In the ¬rst, Figure 9.12(a), the initiator
is offering to communicate using both video and audio media streams. It is willing to
offering the called party the following options:

PCM µlaw or GSM, RTP port 23099, RTP clock 8 kHz
Audio
Video H.261 or H.263, RTP port 23101, RTP clock 90 kHz

The called UA replies choosing GSM and H.261. Note that static RTP payload types
0 (PCM µlaw), 3 (GSM) and 31 (H.261) are de¬ned in the standard RTP audio visual
pro¬le (RFC 1890). In the second example, Figure 9.12(b), a UA is shown rejecting the
offer of the video stream by setting the port number to 0.
After the initial offer/answer for any given call, a re-INVITE can be sent containing
new SDP content negotiating the media streams options again. This would allow, for
example, for two users participating in an audio call to add video. A simpler way to
renegotiate media for a call is to use the UPDATE message. This is preferable to the
re-INVITE since it only requires two messages (UPDATE and 200 OK) instead of the
INVITE three-way handshake. One use of media renegotiation is to put a user on hold. To
9.5 SESSION INITIATION PROTOCOL (SIP) 579


Offer Answer

INVITE 200 OK
v=0
v=0
o=
o=
s=
s=
c=IN IP4 128.7.8.9
c=IN IP4 128.7.8.9
(a) t= t=
m=audio 2097 RTP/AVP 3
m=audio 23099 RTP/AVP 0 3
m=video 2095 RTP/AVP 31
m=video 23101 RTP/AVP 31 96
a=rtpmap:96 H263-1998


<<

. 117
( 132 .)



>>