<<

. 118
( 132 .)



>>



Offer Answer

INVITE 200 OK
v=0
v=0 Video media
o=
o= rejected by
s=
s= setting port
c=IN IP4 128.7.8.9
c=IN IP4 128.7.8.9 number to '0'
t=
(b) t=
m=audio 2097 RTP/AVP 3
m=audio 23099 RTP/AVP 0 3
a=video 0 RTP/AVP 31 96
m=video 23101 RTP/AVP 31 96
a=rtpmap:96 H263/90000




Figure 9.12 SIP offer/answer examples


do this the UA will send an SDP offer containing the SDP media attribute set to inactive.
An example of this is shown in Figure 9.13. The ¬rst UPDATE puts the media on hold
by sending a = inactive; the 200 OK con¬rms the hold status.
The media stream is resumed with the second UPDATE with the media attribute set as
a = sendrecv.



9.5.14 SIP registration
SIP registration is used to allow users to indicate to the network their contact preferences
and current location. Mobility is supported via the registration process since a user can
indicate which visited network they currently reside in. To register, a REGISTER request
is sent to the registrar server, which allows a user to submit one or more contact URIs
where they can be reached. The contact header in the message contains the actual contact
addresses. The contacts are usually presented as SIP URIs but any valid URI can be used,
for example email addresses (mailto URL) and telephone numbers (tel URL). Figure 9.14
shows two registration requests. The ¬rst example shows the UA registering its local
580 RELEASE 5 AND BEYOND (ALL-IP)


Offer (HOLD) Answer (HOLD)

UPDATE 200 OK
v=0
v=0
o= o=
s= s=
c=IN IP4 128.7.8.9 c=IN IP4 128.7.8.9
t= t=
m=audio 23099 RTP/AVP 96 m=audio 2097 RTP/AVP 3
a=rtpmap:96 AMR a=rtpmap:96 AMR
a=inactive a=inactive



Offer (RESUME) Answer (RESUME)

UPDATE 200 OK
v=0
v=0
o=
o=
s=
s=
c=IN IP4 128.7.8.9
c=IN IP4 128.7.8.9
t=
t=
m=audio 2097 RTP/AVP 3
m=audio 23099 RTP/AVP 96
a=rtpmap:96 AMR
a=rtpmap:96 AMR
a=sendrecv
a=sendrecv


Figure 9.13 Use of UPDATE to provide call hold


REGISTER sip:vodafone.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.4:5060
To: seb <sip:seb@vodafone.com>
From: seb <sip:seb@vodafone.com>
Call-ID: 8435678684230@12345
Cseq: 2567 REGISTER
Contact: <sip:seb@10.0.0.4> ; q=0.5; expires 86400,
<mailto:seb@orbitage.com> ; q=0.3; expires 86400



REGISTER sip:vodafone.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.4:5060
To: seb <sip:seb@vodafone.com>
From: seb <sip:seb@vodafone.com>
Call-ID: 8435678684231@12345
Cseq: 2568 REGISTER
Contact: <mailto:seb@10.0.0.4> ; expires 0
<tel: +4478912345678> ; q=1.0; expires 3600


Figure 9.14 Registration examples
9.5 SESSION INITIATION PROTOCOL (SIP) 581


SIP IP contact and email address. The expires parameter controls the lifespan of the
registration. In the example given, the expiry time is set to 86 400 seconds or 1 day.
After this the registration will be deleted from the server. The q parameter gives the
priority value. A UA receiving a list of contacts should try the contact with the highest q
value ¬rst. This is a fractional value, with 1 being the highest priority and 0 the lowest.
In the second example, the registration shows how the registration binding can be deleted
by setting the expiry time to 0.


9.5.15 SIP call routing (direct, proxy and redirect)
Usually when an INVITE is sent out from the UA it is directed to the local outgoing
proxy server. The local proxy will examine the URI in the SIP header. If the host part
of the URI is an IP address, the request can be forwarded directly. More often, the host
part of the URI is a domain name, in which case a DNS lookup will be performed to
determine the associated IP address. For messages destined for a different domain, the
message will be forwarded to that domain™s proxy server. To do this, the local proxy must
discover the address and port number of the remote domain™s proxy server. This is done
using the mechanisms described in Section 9.5.7.
When the SIP proxy serving the target domain receives the INVITE it will then inter-
rogate its location service to determine the destination user™s current contact details. If
the SIP user™s contact is local, the call can be forwarded directly to the UA. For non-local
contacts, however, the INVITE must be proxied by the server or a redirect response sent
back to the originating proxy or UA.
Figure 9.15 shows a call being proxied by the remote server. The call involves the
following steps:

1. Originating UA sends INVITE, destination is seb@vodafone.com.
2. Local proxy forwards the INVITE to remote proxy at vodafone.com.
3. Proxy at vodafone.com interrogates location service for seb@vodafone.com.
4. Location service returns two SIP contacts: one at IP address 10.0.0.4, the other at
seb@orbitage.com.
5. Proxy at vodafone.com picks seb@orbitage.com to forward the call to based on user
preference settings and forwards INVITE to proxy at orbitage.com.
6. Proxy at orbitage.com interrogates location service for seb@orbitage.com.
7. Location service returns contact address at 192.10.4.5.
8. Call is forwarded to user™s UA at 192.10.4.5.

Note that the SIP URI on the request line can be rewritten by the proxy servers, but
the From and To headers remain unaltered as the call is forwarded across the network.
Figure 9.16 shows the call ¬‚ow when the proxy sends a 3xx redirection response back
to the originating UA. This has the bene¬t of putting the user in control, as at the point
of receiving the response which contains the destination contact list, the UA can provide
a list of contact options for the user to choose from. The stages for this call are:
582 RELEASE 5 AND BEYOND (ALL-IP)


sip.org
UA
1
INVITE vodaphone.com

INVITE sip:seb@vodaphone.com Location request
Proxy/ 3
2 location
To: <sip:seb@vodaphone.com> scoope@vodaphone.com
redirect
Proxy From: <sip:kjones@sip.org>
4 service
Location response
server seb@orbitage.com
5 seb@10.0.0.4

INVITE sip:seb@orbitage.com
To: <sip:seb@vodaphone.com>
From: <sip:kjones@sip.org>
orbitage.com

Location request
Proxy/ 6
location
seb@orbitage.com
redirect
service
Location response
7
server seb@192.10.4.5
8 INVITE sip:seb@192.10.4.5
To: <sip:seb@vodaphone.com>
From: <sip:kjones@sip.org>

UA



Figure 9.15 Call forwarded by proxy


sip.org
UA

INVITE
vodaphone.com
INVITE sip:seb@vodaphone.com
1 Location request
To: <sip:seb@vodaphone.com> Proxy/ 2
location
seb@vodaphone.com
From: <sip:kjones@sip.org>
redirect
Proxy
service
Location response
server 3
302 Moved Temporarily sip:seb@orbitage.com
4
contact:<sip:seb@orbitage.com> mailto:seb@hotmail.com
5
contact:<mailto:seb@hotmail.com>
INV
IT
To: E sip
< :s
Fro sip:s eb@o
orbitage.com
m: eb@ rbit
<si a
p:k voda ge.c
jon pho om
es@ ne SIP Location request
Proxy/
sip .com /2.0 6
.or seb@orbitage.com
g> > location
redirect
service
Location response
server 7
seb@192.10.4.5
8 INVITE sip:seb@192.10.4.5 SIP/2.0
To: <sip:seb@vodaphone.com>
From: <sip:kjones@sip.org>


UA



Figure 9.16 Call redirection using 3xx response
9.5 SESSION INITIATION PROTOCOL (SIP) 583


1. Originating UA sends INVITE, destination is seb@vodafone.com.
2. Local proxy forwards the INVITE to remote proxy at vodafone.com.
3. Proxy at vodafone.com interrogates location service for seb@vodafone.com.
4. Location service returns two contacts: one is an email address, seb@hotmail.com,
the other a SIP contact at seb@orbitage.com.
5. Proxy at vodafone.com sends 302 moved temporarily redirect back to local proxy.
This message contains the contact list for the destination.
6. 302 response sent back to originating UA.
7. Originating UA re-sends INVITE to seb@orbitage.com.
8. Proxy at orbitage.com interrogates location service for seb@orbitage.com.
9. Location service returns contact address at 192.10.4.5.
10. Call is forwarded to user™s UA at 192.10.4.5.


9.5.15.1 Forking
It is possible for the proxy to forward the INVITE to a number of different contact
addresses simultaneously. This process, called forking, allows the proxy to try to speed
up the process of contacting the user. Forking can only be performed by a stateful proxy as

<<

. 118
( 132 .)



>>