Scalable voip mobility intedration and deployment- P3 potx

18 Chapter 2
www.newnespress.com
when the extension is not known by the registrar. That would happen when the phone really
does not belong to this particular telephone network.
The Via, From, and To fields serve the same purpose as before. Note that the To field now
has a tag. The From field is still from the original caller, even though this is a response, and
the To field is still from the called party. The Via line, and the indented one following it, are
all one line in the packet: the description will use ⇒ to mark that the following line
continues the current one.
The CSeq field has not changed, as this is still the REGISTER request/response pair.
The User-Agent is the vendor name of the registrar. In this case, it is “My PBX.” Because
you cannot go out and purchase “My PBX,” you may have to settle for someone else’s.
The Allow header states what types of actions a caller can request from the registrar. We
will look at the more important ones—INVITE and BYE—shortly.
The Expires header states that the registrar agreed with the client, and is going to let the
registration live for 3600 seconds. The registrar can shorten this amount, if it so chooses
and the client will lose its registration if it does not come in before then. You will notice
that the Expires information repeats as a separate field in the Contact header. There are,
unfortunately, still multiple ways of encoding exactly the same information in SIP, and there
will be a lot of redundancy. The problem, of course, with redundancy, is that no one really
knows how a complex system will work if the redundant information actually changes.
Finally, the date of the response came in. Now, the registrar knows the phone exists, and the
phone can make and receive calls. One good thing about registration is that the phone
Table 2.2: SIP REGISTER response
SIP/2.0 200 OK
Via: SIP/2.0/UDP ⇒
192.68.0.10:5060;branch=z9hG4bK1072017640;received=192.168.0.10
From: “7010”〈sip:〉;tag=915317945
To: “7010”〈sip:〉;tag=as7374d984
Call-ID:
CSeq: 1 REGISTER

User-Agent: My PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Expires: 3600
Contact: 〈sip:〉;expires=3600
Date: Tue, 27 Jan 2008 00:25:14 GMT
Content-Length: 0
Voice Mobility Technologies 19
www.newnespress.com
number and IP address bindings can be looked up in the PBX by the administrator. SIP-
aware intervening networks, such as some Wi-Fi systems, also track this state and show
which phones are wireless and where they are.
2.2.1.3 Placing a SIP Call
Our user, 7010, wants to place a call to his already registered coworker, 7020. In SIP, this
process belongs to a request-response series kicked off by an INVITE. The idea behind the
invite is that the caller invites the called party into the call.
Phone calls always start off with the user dialing the called party. Once that is done, the call
should ring until the called party answers, or until the system forwards the call to voicemail
or delivers a busy signal. Because there are phases of the call setup process—ringing, then
a forward to voicemail—we will see how SIP deals with multiple responses for the same
request. Figure 2.3 shows the messages that are exchanged in setting up the call, in order
from 1 to 9. The top and bottom half of the diagram are of the same equipment, but are
Phone
User Agen
t
User Agen
t
Phone
User Agent
Proxy

Phone
1) INVITE
3) INVITE
2) Trying
Phone
User Agent
Proxy
5) Ringing 4) Ringing
6) OK
7) ACK9) ACK
8) OK
Figure 2.3: SIP Call Setup
20 Chapter 2
www.newnespress.com
separated to make the arrows clearer. Each arrow represents a message being sent from one
part to the other. The black lines are for messages that represent the main setup messages,
representing the call being placed or answered. The dashed lines are for messages that
inform the caller of the progress. The dotted lines represent messages that are necessary for
the protocol to work, if a message gets lost, but do not carry meaningful information about
the call itself.
Table 2.3 shows the outgoing request for a phone call. This is delivered to the proxy, as the
calling phone has no idea where the called party is. The proxy will ask the registrar for
details, and will then forward the message appropriately.
Table 2.3: SIP INVITE Request from Caller to Proxy
INVITE sip: SIP/2.0
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK922648023
From: “7010”〈sip:〉;tag=1687298419
To: 〈sip:〉
Supported: replaces,100rel,timer
Call-ID:

CSeq: 20 INVITE
Session-Expires: 1800
Contact: 〈sip:〉
Max-Forwards: 70
Expires: 180
Content-Type: application/sdp
Content-Length: 217
v=0
o=7010 1352822030 1434897705 IN IP4 192.168.0.10
s=A_conversation
c=IN IP4 192.168.0.10
t=0 0
m=audio 9000 RTP/AVP 0 8 18
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:18 G729/8000/1
a=ptime:20
So Table 2.3 shows a substantially more involved message than we saw with registration.
Let’s walk through it.
The first line states that this is an “INVITE”, asking for URI “sip:”, or the
phone number 7020. So now we know who the call is for.
Voice Mobility Technologies 21
www.newnespress.com
The To field repeats that the message is really destined for URI “sip:”.
The CSeq field is “20 INVITE”. This INVITE started at 20. There may be multiple
INVITEs coming for this call, depending on what happens as the call progresses. So 20 is a
starting point.
The Session-Expires header means that the entire session to start a phone call, including
future changes, shouldn’t live for more than 1800 seconds, or a half-hour. This has no
influence on the endpoints, but the proxy may be tracking the call, and this expiration lets

the proxy know when the call can be flushed from the system, if, for some reason, one side
or another disconnects from the network without informing the proxy.
The Expires header, on the other hand, states how long the calling phone is willing to wait
until it gets a yes-or-no answer from the other party. After 180 seconds, or three minutes,
the caller will give up and cancel the invitation.
The Content-Type field states that there is a body to this message, and it is in the Session
Description Protocol (SDP) format. As mentioned earlier, SIP has no understanding of voice
traffic itself. It is charged only with setting up calls. The SDP, on the other hand, describes
how to set up the voice traffic. We’ll talk more about SDP in the section on bearer
protocols, but for now, it’s enough to note that the rest of the packet is for the client asking
for an Real-time Transport Protocol (RTP) session with voice.
Table 2.4: SIP INVITE Trying Responses from Proxy to Caller
SIP/2.0 100 Trying
Via: SIP/2.0/UDP ⇒
192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10
From: “7010”〈sip:〉;tag=1687298419
To: 〈sip:〉
Call-ID:
CSeq: 20 INVITE
User-Agent: My PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: 〈sip:〉
Content-Length: 0
Table 2.4 describes the response from the proxy back to the caller. The code is “100
Trying”, meaning that the proxy has more work to do, and a better result will be provided
shortly. In the meantime, the calling phone may show some state reflecting that the call is
being attempted, but no ringing should be heard by the caller.
The proxy will also proceed to forward the INVITE request to the called party.
22 Chapter 2

www.newnespress.com
Table 2.5 shows the INVITE as the proxy has forwarded it. This message, from the proxy to
the called party, 7020, looks similar to the original INVITE. There is one major difference,
however, besides the Via header. The PBX in use is configured to direct the bearer channel
through itself, where it will bridge the two legs of the call, one leg from each phone to the
PBX. Therefore, it has substituted its own session description, in SDP, requesting the voice
connection to come back to its own IP address. Also note that the CSeq for this invite is
102, not 20. The proxy maintains its own sequence. Finally, note that the URI for the To
header has now changed to have the part after the @ sign refer to the phone’s IP.
The called party’s phone responds to the proxy with the next message, in Table 2.6.
The called party’s phone will also start to ring. This may not happen if the phone is busy or
not available. But, in this case, the phone is available, and is ringing.
Table 2.5: SIP INVITE Request from Proxy to Called Party
INVITE sip: SIP/2.0
Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport
From: “7010”〈sip:〉;tag=as13a69dc0
To: 〈sip:〉
Contact: 〈sip:〉
Call-ID:
CSeq: 102 INVITE
User-Agent: My PBX
Max-Forwards: 70
Date: Tue, 27 Jan 2008 00:25:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 281
v=0
o=root 10871 10871 IN IP4 10.0.0.10
s=session

c=IN IP4 10.0.0.10
t=0 0
m=audio 11690 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
Voice Mobility Technologies 23
www.newnespress.com
Table 2.7 shows the ringing message sent from the proxy, back to the caller. The caller
receives this message, and starts playing a ringback tone for the caller to listen to, as the
other party decides whether to answer. Some amount of time passes, and then the called
party answers.
Table 2.8 shows the “200 OK” message, reflecting that the call has been answered. In the
OK message, we can see that the called party states where it wants its leg of the call to
arrive to, and how it would like to set up the bearer channel.
The proxy will receive this message and patch together the second leg of the call from it to
the called party. To do so, the proxy, which has inserted itself between the two endpoints
of the call, needs to send an acknowledgment (ACK), as shown in Table 2.9. This is needed
because UDP is a lossy protocol, and there is a possibility that one of the messages didn’t
get through. If the original INVITE did not get through, the sender will continue to send
duplicate INVITEs, every second or so, until the other side gets it. Now, with the OK
having been sent, the called party needs to know that the caller knows and is in the call.
Table 2.6: SIP Ringing Response from Called Party to Proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport=5060

From: “7010”〈sip:〉;tag=as13a69dc0
To: 〈sip:〉;tag=807333543
Call-ID:
CSeq: 102 INVITE
Contact: 〈sip:〉
Content-Length: 0
Table 2.7: SIP Ringing Response from Proxy to Caller
SIP/2.0 180 Ringing SIP/2.0
Via: SIP/2.0/UDP ⇒
192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10
From: “7010”〈sip:〉;tag=1687298419
To: 〈sip:〉;tag=as500634a6
Call-ID:
CSeq: 20 INVITE
User-Agent: My PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: 〈sip:〉
Content-Length: 0
24 Chapter 2
www.newnespress.com
The proxy also needs to send the OK through to the caller.
Table 2.10 shows the message the caller gets. This lets the caller stop playing the ringback
tone, and connecting the phone call from itself to the PBX. Now, both callers can hear each
other.
There is nothing to be done after the ACK, as it marks the end of the call setup protocol.
We can now ask how the proxy participated. The messages you have seen look as if they
could have gone directly from party to party. And this is true. However, the SIP proxy and
registrar work together to provide a way for clients to find out about other clients, and have
Table 2.8: SIP OK Response from Called Party to Proxy

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport=5060
From: “7010”〈sip:〉;tag=as13a69dc0
To: 〈sip:〉;tag=807333543
Supported: replaces
Call-ID:
CSeq: 102 INVITE
Contact: 〈sip:〉
Content-Type: application/sdp
Content-Length: 160
v=0
o=9002 1367913267 845466921 IN IP4 192.168.0.20
s=A_conversation
c=IN IP4 192.168.0.20
t=0 0
m=audio 9000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
Table 2.9: SIP ACK Request from Proxy to Called Party
ACK sip: SIP/2.0
Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK632b9079;rport
From: “7010”〈sip:〉;tag=as13a69dc0
To: 〈sip:〉;tag=807333543
Contact: 〈sip:〉
Call-ID:
CSeq: 102 ACK
User-Agent: My PBX
Max-Forwards: 70
Content-Length: 0
Voice Mobility Technologies 25

www.newnespress.com
their calls routed to voicemail, the outside world, or to have any other advanced call feature
performed. For this to work, the SIP proxy and registrar must work together to form a PBX.
Clients are prevented from communicating directly. You may have noticed that at no point
do the messages from the caller to the proxy have the IP addresses of the called party, and
vice versa. The Contact and Via headers are always kept consistent, and all of the messages
are forced to flow through the proxy. Not all proxies act this way, but most proxies with full
PBX functionality do.
Table 2.10: SIP OK Response from Proxy to Caller
SIP/2.0 200 OK
Via: SIP/2.0/UDP ⇒
192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10
From: “7010”〈sip:〉;tag=1687298419
To: 〈sip:〉;tag=as500634a6
Call-ID:
CSeq: 20 INVITE
User-Agent: My PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: 〈sip:〉
Content-Type: application/sdp
Content-Length: 202
v=0
o=root 10871 10871 IN IP4 10.0.0.10
s=session
c=IN IP4 10.0.0.10
t=0 0
m=audio 12482 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
Table 2.11: SIP ACK Request from Caller to Proxy
ACK sip: SIP/2.0
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK1189369993
From: “7010”〈sip:〉;tag=1687298419
To: 〈sip:〉;tag=as500634a6
Call-ID:
CSeq: 20 ACK
Max-Forwards: 70
Content-Length: 0
26 Chapter 2
www.newnespress.com
Phone
User Agent
User Agent
Phone
User Agent
Proxy
Phone
1) INVITE
3) INVITE
2) Trying
Phone
User Agent
Proxy
5) Ringing 4) Ringing
6) Busy Here
7) ACK9) ACK

8) Busy Everywhere
Figure 2.4: SIP Call Rejection
2.2.1.4 A Rejected SIP Call
Sometimes the called party does not want to answer the call. This happens when the phone
call comes in and the user is busy. The process looks very similar to a successful SIP call,
except that, instead of the called party sending a 200 OK message, it sends a different one.
Figure 2.4 shows the call setup flow. The change is that the OK is now replaced with a “486
Busy Here” message, which means that the called party is busy at the endpoint they were
called at. The proxy could have used this status to forward the call onto a voicemail system,
by either sending a new INVITE to the voicemail system (if it has a separate user agent)
and bridging those two legs together, or by sending a “302 Moved Temporarily” response to
the client and expecting the client to try the voicemail.
Table 2.12 shows the rejection that the called party will send if the user declines to take the
call. The proxy will continue with its ACK, as before.
Voice Mobility Technologies 27
www.newnespress.com
Next, the proxy will send to the caller a busy message (Table 2.13), stating that the called
party is busy at every user agent that it is aware of, which, for this example, is the one at
192.168.0.20. Because the proxy knows that the called party has no other alternatives, it
changed the message code from “486 Busy Here” to “600 Busy Everywhere”.
2.2.1.5 Hanging Up
Once the SIP call is going, there are no response codes that can hang the call up. Rather, the
party who hangs up first sends a new request to the proxy, to disconnect the call. This type
of message, called a BYE request, tells the receiver that the call is now over.
Table 2.14 shows the BYE message, sent when the caller hangs up the phone call. The
proxy server will respond to the BYE with a “200 OK” response, which is similar to the
ones we have seen before, except without any SDP description of the bearer channel. Then,
the proxy server will send a BYE to the called party, and wait for the OK from there.
Unlike with the call setup, the OK message is enough to mark the end of the teardown.
2.2.1.6 SIP Response Codes

The protocol has a number of response codes, some of which are more esoteric than others.
We’ll go through the main ones, one by one, to get a better sense of what can happen.
Table 2.12: SIP Busy Here Rejection from Called Party to Proxy
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK51108ed9;rport=5060
From: “7010”〈sip:〉;tag=as13a69dc0
To: 〈sip:〉;tag=807333543
Call-ID:
CSeq: 102 INVITE
Content-Length: 0
Table 2.13: SIP Busy Everywhere Rejection from Proxy to Caller
SIP/2.0 600 Busy Everywhere
Via: SIP/2.0/UDP ⇒
192.168.0.10:5060;branch=z9hG4bK922648023;received=192.168.0.10
From: “7010”〈sip:〉;tag=1687298419
To: 〈sip:〉;tag=as500634a6
Call-ID:
CSeq: 20 INVITE
User-Agent: My PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0