Scalable voip mobility intedration and deployment- P4 pot

• 180 Ringing: sent by the called party while it is ringing the phone.. Redirection Codes • 301 Moved Permanently: sent by a proxy or possibly an endpoint when a user has permanently ch

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:7020@corp.com SIP/2.0

Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK1818649196

From: “7010”〈sip:7010@corp.com〉;tag=1687298419

To: 〈sip:7020@corp.com〉;tag=as500634a6

Call-ID: 2114455679@192.168.0.10

CSeq: 21 BYE

Max-Forwards: 70

Content-Length: 0

• 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.

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

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:7020@corp.com ”,

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

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

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

Extensions Dial Plan

Figure 2.5: H.323 Architecture

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

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

Table 2.17: Example SCCP Call Setup Event Flow

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.

# 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