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