Scalable voip mobility intedration and deployment- P4 pot

28 Chapter 2
www.newnespress.com
In-Progress Codes
• 100 Trying: sent by any endpoint, when it needs to inform the requester that it is
handling the request, but might not return quickly enough to prevent the sender from
thinking the message was lost.
• 180 Ringing: sent by the called party while it is ringing the phone.
• 181 Call is Being Forwarded: might be sent by a proxy to the caller when the call is
being forwarded to another destination, such as a second handset or voicemail. You may
never see this one.
• 182 Queued: sent by a server running a phone bank, informing the caller that the call is
on hold to be answered. It can also be sent at a chokepoint when lines are busy but one
of the proxies does not want to give up on establishing the call just yet.
Success Code
• 200 OK: the request succeeded. If the request was an INVITE, the message has the
session description for the audio channel.
Redirection Codes
• 301 Moved Permanently: sent by a proxy (or possibly an endpoint) when a user has
permanently changed his or her phone number to something else. The Contact header
should have the forwarding address.
• 302 Moved Temporarily: sent when the call is being forwarded. The Contact header will
have where the call needs to be forwarded to, and the caller must start a new call to that
forwarding address.
Request Failure Codes
• 400 Bad Request: sent when the SIP message is not formatted properly. This is a good
sign of interoperability issues between advanced features of different products.
Table 2.14: SIP BYE from Caller to Proxy
BYE sip: SIP/2.0
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK1818649196
From: “7010”〈sip:〉;tag=1687298419
To: 〈sip:〉;tag=as500634a6

Call-ID:
CSeq: 21 BYE
Max-Forwards: 70
Content-Length: 0
Voice Mobility Technologies 29
www.newnespress.com
• 401 Unauthorized: sent by a device when it requires SIP authorization.
• 403 Forbidden: sent for a number of reasons. Usually, this happens when a caller is not
allowed to use a certain feature, perhaps because of access rights in the proxy. This also
gets sent when unknown endpoints try to register and are not provisioned. Finally, this
status can also be thrown in when devices, for whatever reason, do not wish to handle
the request. Some phones or proxies send this when the other side is busy.
• 404 Not Found: sent by a proxy for a number that does not exist.
• 405 Method Not Allowed: sent by a proxy or an endpoint when they do not want to
perform a SIP method for the called party. Devices which do not allow calls, such as
registrars when the registrar is not a proxy, can send this, as can proxies that are not
registrars and are being registered to. This is a good sign that the phone is
misconfigured to use the wrong IP address for some PBX function.
• 407 Proxy Authentication Required: sent by the proxy or PBX when it requires
authentication. The calling phone might respond automatically by authenticating.
• 408 Request Timeout: sent by an endpoint or proxy when the request just cannot be handled
in time. This is often a sign of long delays or problems between specific SIP infrastructure
resources, such as a proxy being unable to reach a separate proxy or registrar.
• 410 Gone: sent when the called party did once exist, but no longer does, there is no
forwarding information, and the proxy does not know why the extension is gone.
Similar to “604 Does Not Exist Anymore,” where the difference between the two will
be described shortly.
• 480 Temporarily Unavailable: sent when the called party’s registration has expired, has
not logged in, or is not yet electronically ready to receive the call.
• 482 Loop Detected: sent by a proxy when it sees the same message twice. This is a sign

that inter-proxy forwarding is not correctly configured. This concept is similar to an
email forwarding loop.
• 483 Too Many Hops: sent by a proxy when the Max-Forwards header field hits zero.
This too is usually a sign that inter-proxy forwarding is not configured correctly, and
that there is a forwarding loop.
• 486 Busy Here: sent by a phone when it is already in a call or does not want to take the
call because the user is busy. The proxy receiving the message can try the next
registration for the extension, or can try forwarding the call off.
• 491 Request Pending: a rare message, which happens when INVITEs cross pass for the
same two clients from opposite directions. If you see this message, it is usually because
of a coincidence, rather than misconfiguration.
• 493 Undecipherable: the SIP security model cannot decrypt the message.
30 Chapter 2
www.newnespress.com
Server Failure Codes
• 500 Server Internal Error: sent when the SIP protocol is not being followed correctly
by the requester, or when there is something wrong with the endpoint receiving the
request, such as misconfiguration or an error.
• 501 Not Implemented: the recipient of the request does not implement the method.
• 502 Bad Gateway: one proxy did not like the response it got from another proxy, and
wishes to report it to the caller. Usually a sign of misconfiguration or incompatibility
between the gateways.
• 503 Service Unavailable: sent when the proxy or endpoint is not fully configured or is
undergoing maintenance.
• 504 Server Time-out: sent by a proxy when it cannot access a non-SIP service, such as
DNS, in a timely manner.
• 505 Version Not Supported: the requester is using a version of SIP too old or too new
for the other end.
Global Failure Codes
• 600 Busy Everywhere: sent by a proxy when it has tried every endpoint for the

extension, they are all busy, and there is no place to route the call. This should generate
a busy tone or busy indication, for the caller.
• 603 Decline: the called party does not want to participate, and does not want to explain
why.
• 604 Does Not Exist Anymore: similar to “410 Gone,” but is definitive. The called party
no longer exists, because the extension was deleted.
• 606 Not Acceptable: sent by the endpoint when it cannot handle the media stream being
requested. This can happen when an IPv6 phone (with no IPv4 address) calls an IPv4
phone, or when a videophone calls a standard audio phone, for example.
This list is not exhaustive. Moreover, SIP is a very flexible protocol, subject to a number of
different interpretations. Because of this, different phones and different proxies might send
different messages, depending on how they interpret the standard and what devices they
interoperate with will do when they receive the message.
2.2.1.7 Authentication
SIP authentication is based on the challenge-response protocol used in HTTP, and
allows username and password authentication into the registrar, proxies, and services. With
SIP, the concept for authentication is that the registrar or proxy will send one of the status
Voice Mobility Technologies 31
www.newnespress.com
messages that requires authentication (401 or 407), and the client or upstream server will
respond.
The authentication method is based on the WWW-Authenticate header. The more common
authentication method is using the digest scheme. The response comes in an Authorization
header in the retransmitted request. The digest method uses an MD5 hash over the
username, password, realm, and resource that is being accessed, along with a nonce from
the responder and a nonce from the requester.
Table 2.15: Example SIP Authentication Challenge
WWW-Authenticate: Digest
realm=“corp.com”,
qop=“auth,auth-int”,

nonce=“235987cb9879241b1424d4bea417b22f71”,
opaque=“aca9787a9e87cae532a685e094ce8394”
Table 2.16: Example SIP Authentication Response
Authorization: Digest username=“7010”,
realm=“corp.com”,
nonce=“235987cb9879241b1424d4bea417b22f71”,
uri=“sip: ”,
qop=auth,
nc=00000001,
cnonce=“3a565253”,
response=“d0ea98700991bce0bd0ba0eab1becc01”,
opaque=“aca9787a9e87cae532a685e094ce8394”
Table 2.15 shows an example authentication challenge header. The realm is “corp.com”.
“qop” asks for the specific algorithm to be used to calculate the hashes. The nonce is, as
expected, a random number from the server that proves that the client is alive and is not just
a replay of an older, valid session. The opaque value is some server-specific information
that the client is required to repeat, but has no cryptographic significance.
The client will perform a series of MD5 hashes on this information, as well as the
resource being requested, and will add the results into the Authorization header shown in
Table 2.16.
Authentication, by itself, does not provide any privacy or encryption for the traffic or
prevent modifications of the parameters to any message. But it does prevent accidental
misuse of resources.
32 Chapter 2
www.newnespress.com
2.2.1.8 Secure SIP
Full hop-by-hop security is possible with SIP, using what is called SIPS. This extension uses
TLS in essentially the same way as HTTPS does. URIs are modified from “sip:” to “sips:”,
just as “http:” is modified to “https:” with SSL (noting that SSL is just an older version of
TLS).

Using SIPS requires that both endpoints communicate using TCP. When the TCP connection
is connected, the server will use TLS to request that the client authenticate. The client will
then use its TLS credentials to authenticate, including using no credentials as an option,
akin to the typical use of HTTPS in which only the server needs to authenticate using TLS.
Once TLS finishes, both the requester and responder have a master key, which they use to
encrypt the session. Within the session, password-based authentication can be used using the
SIP digest authentication method. With the connection being encrypted with TLS, both
parties are provided confidentiality and protection from forgeries or modification.
2.2.2 H.323
H.323 is an International Telecommunication Union (ITU) specification that defines
how to establish both the signaling and the bearer channels. The goal was to use the
call signaling from ISDN, a call control protocol for renegotiating calls as they are
ongoing, and a registration protocol, to provide for an all-encompassing solution. (Compare
how SIP defines only registration, call signaling, and merely basic call control.) However,
the process was different, and the H.323 technology suffers from the typical emphasis on
layering and precise botanical definitions of technologies that haunts the world of
telecommunications.
H.323’s major advantage, compared to SIP, is that it contains the complete protocol
definition for the application, covering features such as media reservation and conference
negotiation that SIP leaves alone. H.323 is also able to pull together a number of other
ITU definitions and technologies, into one larger umbrella. Because of the ITU protocols’
amount of definition for media applications, H.323 is still the signaling protocol of choice
for many videoconferencing applications.
That being said, H.323’s relevance for voice is waning. For that reason, we will stick to
H.323 at a higher level than we did with SIP.
2.2.2.1 H.323 Architecture
H.323 has a somewhat similar architecture to SIP. Figure 2.5 shows this architecture.
The endpoints are known as terminals. The terminals must register with the registrar, which
is now in a function known as the gatekeeper. The gatekeeper is the PBX, and has complete
responsibility for administration, user definitions, registration, and routing. Gateways are

Voice Mobility Technologies 33
www.newnespress.com
now special devices that are specifically called out for bridging signaling and media
between two different networks.
H.323 uses a protocol known as H.225.0 for call setup signaling. H.225.0 itself is a package
that refers to Q.931 for call signaling definitions. (This sort of nesting is typical for
telecommunications definitions). The good news is that it stops at Q.931, and we can
identify it. ITU Q.931 is the call signaling protocol used in ISDN lines, and is referred to in
Section 2.2.6. H.225.0 also includes the Registration, Admission, and Status (RAS) protocol,
used by the client to register with the network.
Gatekeeper
Phone
Media Gateway
Public Switched Telephony Network (PSTN)
H.225.0
Call Setup Messages
H.225.0 or H.245 Specified
RTP Bearer Traffic
Telephone Lines
Terminal
Gateway
Phone
ExtensionsDial Plan
Figure 2.5: H.323 Architecture
34 Chapter 2
www.newnespress.com
The registration function is, therefore, defined by RAS. When a phone comes online, its first
task is to use RAS to find a gatekeeper (from a known or discovered list) that is willing to
let it register. Once it does that, it then requests to register. After the registration is
complete, the phone is ready to send or receive calls.

To place a call, the phone sends an admission request to the gatekeeper. The gatekeeper’s
job is to find out where the other endpoint is, by looking up in its extension or routing
tables. The result will be an acceptance or rejection. If the result is an acceptance, the
gatekeeper will also respond with the contact information for the other endpoint. Notice that
the model here is based on admission control. The gatekeeper is allowed to monitor voice
resources, and reject calls purely on the basis of there not being enough resources. In any
event, the caller now has the contact information of the called party, so the caller contacts
the called party directly to attempt to establish the call. This direct contact is done using
Q.931 signaling over IP. If the called party is willing to accept the call, the called party
must contact its local gatekeeper with an admission request. If that is granted, the call is
ready to be finalized.
H.245 plays the role of establishing what the bearer channel will hold. H.245 was designed
to provide the information necessary to set up the bearer channels over RTP, and so takes
the place of SIP’s SDP. H.245 exchanges the codec and bearer capabilities of each endpoint,
and is used to negotiate what bearer technology to use. This can be done in a manner that
works for multiple-party calls, and in this way is useful with teleconferencing.
It is still possible to find softphones and open source technology that supports H.323,
especially because of the videoconferencing aspect. However, voice mobility networks are
unlikely to see much of H.323.
2.2.3 Cisco SCCP: “Skinny”
Cisco has a proprietary Skinny Client Control Protocol (SCCP), which is used by the Cisco
Unified Communications Manager and Cisco phones as their own signaling protocol. SCCP
requires the Cisco Unified Communications Manager or open-source PBXs to operate.
Given the downside of proprietary protocols, the main reason for discussing SCCP within
the context of voice mobility is only that Cisco’s Wi-Fi-only handsets support SCCP, and so
SCCP may be seen in some voice mobility networks. Unfortunately, SCCP internal
documentation is not widely available or as well understood as an open protocol is, and so
enterprise-grade implementations tend to lock the user into one vendor only.
SCCP runs on TCP, using port 2000. The design goal of SCCP was to keep it “skinny,” to
allow the phone to have as little intelligence as needed. In this sense, the Cisco Unified

Communications Manager (or older Cisco Call Manager) is designed to interface with other
telephone technologies as a proxy, leaving the phone to deal with supporting the one
proprietary protocol.
Voice Mobility Technologies 35
www.newnespress.com
SCCP has a markedly different architecture from what we have seen already. SCCP is still
an IP-based protocol, and there is the one point of contact that the phone uses for all of its
signaling. However, the signaling design of SCCP has the remarkable property, unlike with
SIP or H.323, that the phone is not self-contained as an extension. Rather, SCCP is entirely
user event–based. The phone’s job is to report back to the call manager, in real time,
whenever a button is pressed. The call manager then pushes down to the phone any change
in state that should accompany the button press. In this way, the entire logic as to what
buttons mean is contained in the call manager, which locally runs the various telephone
endpoint logic. In this way, SCCP has more in common with Remote Desktop than it has
with telephone signaling protocols: the phone’s logic really runs in some centralized
terminal server, which is called the call manager. To emphasize this point, Table 2.17 lists a
typical sequence of events between a phone and a call manager, from when the phone is
taken off the hook.
As you can see, the phone’s entire personality—the meaning of the buttons, what the display
states, which lights are lit, the tones generated—are entirely controlled by the call manager.
Overall, this is a marked difference from true telephone signaling protocols. In this sense,
then, one can consider SCCP to be mostly a remote control protocol for phones, and the call
manager is thus left with the burden of implementing the true telephone protocol.
Unfortunately, however, when SCCP is used with a packet-based voice mobility network,
the protocol going over the wireless or edge network is going to be SCCP, and not whatever
protocol the call manager is enabled with.
Bearer traffic, on the other hand, still uses RTP, as do the other protocols we have looked at
so far. Therefore, most of the discussion on bearer traffic, and on voice traffic in general,
holds for SCCP networks.
2.2.4 Skype

Skype is mentioned here because it is such an intriguing application. Famous for its
resiliency when running over the Internet, or any other non-quality-of-service network, as
well as for its chat feature and low-cost calls, questions will always come up about Skype.
Undoubtedly, Skype has helped many organizations reduce long distance or international
phone bills, and many business travelers have favored it when on the road and in a hotel,
to avoid room and cell charges for telephone use.
Skype is a completely proprietary peer-to-peer protocol, encrypted hop-by-hop to prevent
unauthorized snooping. There are plenty of resources available on how to use Skype, so it
will be appropriate for us to stick with just the basics on how it applies for voice mobility.
The most important issue with Skype is that it is not manageable in an enterprise sense. Not
only is it a service hosted outside the using enterprise, but the technology itself is encrypted
36 Chapter 2
www.newnespress.com
Table 2.17: Example SCCP Call Setup Event Flow
# Direction Event Name State Meaning
1
Phone → Call
Manager
Offhook
Dialing User has taken the phone off the
hook.
2
Call Manager →
Phone
StationOutputDisplayText
Displays a prompt that the phone is
off hook and waiting for digits.
3
Call Manager →
Phone

SetRinger
Turns off the ringer.
4
Call Manager →
Phone
SetLamp
Turns on the light for the line that is
being used.
5
Call Manager →
Phone
CallState
Sets the phone up so that the user
can hear audio and press buttons.
The phone is not connected to any
other extension yet.
6
Call Manager →
Phone
DisplayPromptStatus
7
Call Manager →
Phone
SelectSoftKeys
8
Call Manager →
Phone
ActivateCallPlane
9
Call Manager →

Phone
StartTone
Starts a dial tone.
10
Phone → Call
Manager
KeypadButton (dialed 7)
The user dialed the number 7.
11
Call Manager →
Phone
StopTone
Stops the dial tone, acknowledging
that a digit has been dialed.
12
Call Manager →
Phone
SelectSoftKeys
Changes the keys of interest to
just the number pad (no redial
buttons, etc.).
13
Phone → Call
Manager
KeypadButton (dialed 0)
The user dialed the number 0.
14
Phone → Call
Manager
KeypadButton (dialed 2)

The user dialed the number 2.
15
Phone → Call
Manager
KeypadButton (dialed 0)
The user dialed the number 0.
16
Call Manager →
Phone
SelectSoftKeys
Ringing Changes the keys of interest.
17
Call Manager →
Phone
CallState
Changes the state of the phone.
18
Call Manager →
Phone
CallInfo
19
Call Manager →
Phone
DialedNumber
Reports that 7020 has been dialed.
20
Call Manager →
Phone
StartTone
Starts playing a ringback tone.

21
Call Manager →
Phone
DisplayPromptStatus
Changes the prompt to show
that the other side of the
phone is ringing.
22
Call Manager →
Phone
CallInfo
The call is still ringing.
Voice Mobility Technologies 37
www.newnespress.com
# Direction Event Name State Meaning
23
Call Manager →
Phone
StopTone
Connected Stops playing the ringback tone.
24
Call Manager →
Phone
DisplayPromptStatus
Displays that the phone call was
answered.
25
Call Manager →
Phone
OpenReceiveChannel

Prepares for the downward leg of
the call.
26
Phone → Call
Manager
OpenReceiveChannelAck
Acknowledges the downward leg.
27
Call Manager →
Phone
StartMediaTransmission
The call’s bearer channel
starts flowing.
28
Phone → Call
Manager
OnHook
Hanging
Up
The caller hung up.
29
Call Manager →
Phone
CloseReceiveChannel
Tears down the receive leg.
30
Call Manager →
Phone
StopMediaTransmission
Stops the bearer channel entirely.

31
Call Manager →
Phone
SetSpeakerMode
Restores the phone to the
original state.
32
Call Manager →
Phone
ClearPromptStatus
33
Call Manager →
Phone
CallState
34
Call Manager →
Phone
DisplayPromptStatus
35
Call Manager →
Phone
ActivateCallPlane
36
Call Manager →
Phone
SetLamp
Turns off the light for the line that
was in use.
Table 2.17: Continued
to prevent even basic understanding or diagnosis. Furthermore, it cannot be run independent

of Internet connectivity, and it is designed to find ways around firewalls. As a primarily
consumer-oriented technology, Skype does not yet have the features necessary for enterprise
deployments, and thus is severely limited in a sense useful for large-scale voice mobility.
Another main issue with Skype is that it does not take advantage of quality-of-service
protocols to provide reliable or predictable, or even prioritized, voice quality. Traffic
engineering with Skype is incredibly difficult, especially if one tries to predict how Skype
will consume resources if large portions of the networked population choose to use it, inside
or outside the office.
On the other hand, Skype comes with better, high-bitrate codecs that make voice sound
much less tinny than the typical low-bitrate codecs used by telephones that may have to
access the public switched telephone network (PSTN). Skype’s ability to free itself from