Bearer Protocols in Detail

The bearer protocols are where the real work in voice gets done. The bearer channel carries the voice, sampled by microphones as digital data, compressed in some manner, and then placed into packets which need to be coordinated as they fly over the networks.

Voice, as you know, starts off as sound waves (Figure 1). These sound waves are picked up by the microphone in the handset, and are then converted into electrical signals, with the voltage of the signal varying with the pressure the sound waves apply to the microphone.

 

Figure 1: Typical Voice Recording Mechanisms

The signal (see Figure 2) is then sampled down into digital, using an analog-to-digital converter. Voice tends to have a frequency around 3000 Hz. Some sounds are higher—music especially needs the higher frequencies—but voice can be represented without significant distortion at the 3000Hz range. Digital sampling works by measuring the voltage of the signal at precise, instantaneous time intervals. Because sound waves are, well, wavy, as are the electrical signals produced by them, the digital sampling must occur at a high enough rate to capture the highest frequency of the voice. As you can see in the figure, the signal has a major oscillation, at what would roughly be said is the pitch of the voice. Finer variations, however, exist, as can be seen on closer inspection, and these variations make up the depth or richness of the voice. Voice for telephone communications is usually limited to 4000 Hz, which is high enough to capture the major pitch and enough of the texture to make the voice sound human, if a bit tinny. Capturing at even higher rates, as is done on compact discs and music recordings, provides an even stronger sense of the original voice.

 

Figure 2: Example Voice Signal, Zoomed in Three Times

Sampling audio so that frequencies up to 4000 Hz can be preserved requires sampling the signal at twice that speed, or 8000 times a second. This is according to the Nyquist Sampling Theorem. The intuition behind this is fairly obvious. Sampling at regular intervals is choosing which value at those given instants. The worst case for sampling would be ifone sampled a 4000 Hz, say, sine wave at 4000 times a second. That would guarantee to provide a flat sample, as the top pair of graphs in Figure 3 shows. This is a severe case of undersampling, leading to aliasing effects. On the other hand, a more likely signal, with a more likely sampling rate, is shown in the bottom pair of graphs in the same figure. Here, the overall form of the signal, including its fundamental frequency, is preserved, but most of the higher-frequency texture is lost. The sampled signal would have the right pitch, but would sound off.

 

Figure 3: Sampling and Aliasing

The other aspect to the digital sampling, besides the 8000 samples-per-second rate, is the amount of detail captured vertically, into the intensity. The question becomes how many bits of information should be used to represent the intensity of each sample. In the quantization process, the infinitely variable, continuous scale of intensities is reduced to a discrete, quantized scale of digital values. Up to a constant factor, corresponding to the maximum intensity that can be represented, the common value for quantization for voice is to 16 bits, for a number between −2¹⁵ = −32,768 to 2¹⁵ −1 = 32,767.

The overall result is a digital stream of 16-bit values, and the process is called pulse code modulation (PCM), a term originating in other methods of encoding audio that are no longer used.

Polycom SpectraLink Voice Priority (SVP)

Early in the days of voice over Wi-Fi, a company called SpectraLink—now owned by Polycom—created a Wi-Fi handset, gateway, and a protocol between them to allow the phones to have good voice quality, when Wi-Fi itself did not yet have Wi-Fi Multimedia (WMM) quality of service. SVP runs as a self-contained protocol, for both signaling and bearer traffic, over IP, using a proprietary IP type (neither UDP nor TCP) for all of the traffic.

SVP is not intended to be an end-to-end signaling protocol. Rather, like Cisco's SCCP, it is intended to bridge between a network server that speaks the real telephone protocol and the proprietary telephone. Therefore, SCCP and SVP have a roughly similar architecture. The major difference is that SVP was designed with wireless in mind to tackle the early quality-of-service issues over Wi-Fi, whereas SCCP was designed mostly as a way of simplifying the operation of phone terminals over wireline IP networks.

Figure 1 shows the SVP architecture. The SVP system integrates into a standard IP PBX deployment. The SVP gateway acts as the location for the extensions, as far as the PBX is concerned. The gateway also acts as the coordinator for all of the wireless phones. SVP phones connect with the gateway, where they are provisioned. The job of the SVP gateway is to perform all of the wireless voice resource management of the network. The SVP performs the admission control for the phones, being configured with the maximum number of phones per access point and denying phones the ability to connect to it through access points that are oversubscribed. The SVP server also engages in performing timeslice coordination for each phone on a given access point.

 

Figure 1: SVP Architecture

This timeslicing function makes sense in the context of how SVP phones operate. SVP phones have proprietary Wi-Fi radios, and the protocol between the SVP gateway and the phone knows about Wi-Fi. Every phone reports back what access point it is associated to. When the phone is placed into a call, the SVP gateway and the phone connect their bearer channels. The timing of the packets sent by the phone is such that it is directly related to the timing of the phone sent by the gateway. Both the phone and the gateway have specific requirements on how the packets end up over the air. This, then, requires that the access points also be modified to be compatible with SVP. The role of the access point is to dutifully follow a few rules which are a part of the SVP protocol, to ensure that the packets access the air at high priority and are not reordered. There are additional requirements for how the access point must behave when a voice packet is lost and must be retransmitted by the access point. By following the rules, the access point allows the client to predict how traffic will perform, and thus ensures the quality of the voice.

SVP is a unique protocol and system, in that it is designed specifically for Wi-Fi, and in such a way that it tries to drive the quality of service of the entire SVP system on that network through intelligence placed in a separate, nonwireless gateway. SVP, and Polycom SpectraLink phones, are Wi-Fi-only devices that are common in hospitals and manufacturing, where there is a heavy mobile call load inside the building but essentially no roaming required to outside.

Skype | Signaling Protocols in Detail

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 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 PSTN integration as the standard case (Skype's landline telephone services can be thought of more as special cases) has allowed it to be optimized for better voice quality in a lossy environment.

Skype is unlikely to be useful in current voice mobility deployments, so it will not be mentioned much further in this book. However, Skype will always be found performing somewhere within the enterprise, and so its usage should be understood. As time progresses, it may be possible that people will have worked out a more full understanding of how to deploy Skype in the enterprise.

Cisco SCCP: "Skinny" | Signaling Protocols in Detail

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 1 lists a typical sequence of events between a phone and a call manager, from when the phone is taken off the hook.

Table 1: 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.
6	Call Manager → Phone	DisplayPromptStatus		The phone is not connected to any other extension yet.
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.
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.

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.

Session Initiation Protocol and Session Description Protocol

The two standard protocols that govern session control are the Session Initiation Protocol (SIP) and Session Description Protocol (SDP). These standards were originally intended for loosely controlled multimedia conferencing over the Internet; however, they have developed into a functional alternative to the H.323 suite. In particular, the combination of SIP and SDP is functionally equivalent to that of H.225.0 and H.245.

SIP (see RFC 2543) was initially standardized by the Multiparty Multimedia Session Control (mmusic) (see www.ietf.org/html.charters/mmusic-charter.html ) working group in the IETF Transport area. As the work had grown, a specialized SIP working group was created (see www.ietf.org/html.charters/sip-charter.html ).

SIP was designed to create and tear down multimedia sessions. In its syntax, SIP is similar to the Hypertext Transfer Protocol (HTTP)—defined in RFC 2616—and it reuses many HTTP header fields (such as authentication). Like HTTP, SIP is ASCII text encoded. Unlike HTTP, however, SIP was developed with the intention of addressing human users, for which reason the uniform resource identifier (URI) defined by SIP looks more like an e-mail address than the address of a World Wide Web page. For example, sip:hui-lan.lu@bell-labs.com is a SIP URI. For the purposes of integrating the PSTN and the Internet, it is important to note that SIP message headers can also carry other URIs (such as telephone URLs, defined by the IETF).

SIP is a client-server protocol: A client generates a request, to which a server sends one or more responses. A (potential) session participant can both generate and receive requests, which suggests that the end systems should have both the client and server capabilities. SIP also supports transaction capabilities. The RFC 2543 definition of a transaction is:

A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final . . . response sent from the server to the client.

Transactions are assigned the command sequence (CSeq) numbers. The SIP nomenclature (similar to that of SNMP and HTTP) alludes to the object-oriented model by defining the following methods that are carried in SIP requests (one method per request):

§  INVITE. Conveys the information about the call to invited participants. It is issued in order to set up a call, and once the call is set up, it can be issued by any party to the call in order to change the call parameters or to add another party.

§  BYE. Terminates a connection.

§  OPTIONS. Solicits information about a user’s capabilities.

§  CANCEL. Terminates the search for the user.

§  REGISTER. Makes the user’s location known to a SIP server.

§  ACK. Invokes the reliable message exchange for invitations. (Note that SIP has its own mechanism for invitation exchange; thus, it can run on top of an unreliable transport layer protocol such as UDP.)

The invitation to a session is accompanied by the Session Description Protocol (SDP) defined in RFC 2327, also developed by the mmusic working group (WG). SDP provides the description format (not the protocol) of the multicast and unicast addresses, the number and types (that is, audio, video, data, control) of streams involved, the codecs involved (that is, the payload types to be carried by the transport protocol), the transport protocol itself (for example, RTP or H.320), the UDP port, the list of starting and stopping times of the session, encryption keys, and so on. Keep in mind that SDP is only one possible payload of SIP; SIP can also carry all Multipurpose Mail Extensions (MIME) types, for example.

In the following section, we discuss location of clients and servers. In a perfectly valid degenerated case, both a client and server can be located in the same host. The opposite extremity, which is strategic to network-wide applications of SIP, is when several SIP servers located in different hosts act as proxies. In this case, server A, after having received a request from a client, may consult a local directory (by using LDAP, for example), only to find out that there is another SIP server, server B, which is better suited to respond to the request. Server A forwards the request to server B, which, from now on, will route its responses through server A.

The proxies can form a routing chain of any length. Figure 1 demonstrates such a chain. You have probably noticed a striking similarity between this figure and Figure 1. This similarity is actually profound, and it has been among the major factors that have influenced the pint working group to adopt SIP as the foundation of the PINT Protocol. SIP also offers a natural solution to the problem of gateway discovery, which is being worked on in the IP Telephony (iptel) working group (www.ietf.org/html.charters/iptel-charter.html).

Figure 1: SIP routing.

The use and applications of SIP are growing. The present specification of SIP, however, as far as size is concerned, is about one-tenth of that of the H.323 suite. In some cases (for example, session control), the protocols seem to be working to solve the same problem; other aspects (for example, definition of network functional elements and their respective roles) are different. For a good comparison of H.323 and SIP, please see “A Comparison of SIP and H.323 for Internet Telephony” (Schulzrinne and Rosenberg, 1998).