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.

H.323 | Signaling Protocols in Detail

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.

H.323 Architecture

H.323 has a somewhat similar architecture to SIP. Figure q shows this architecture.

Figure 1: H.323 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. H.225.0 also includes the Registration, Admission, and Status (RAS) protocol, used by the client to register with the network.

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.

Evolution of Signaling

Now that we know what the voice circuit between the switches is, we can talk about how it is established. In the so-called plain old telephone service (POTS), establishing a call is routing, for once the call (for example, an end-to-end virtual circuit) is established, no routing decisions are to be made by the switches. There are three aspects to call establishment: First, a switch must understand the telephone number it receives in order to terminate the call on a line or route the call to the next switch in the chain; second, a switch must choose the appropriate circuit and let the next switch in the chain know what it is; third, the switches must test the circuit, monitor it, and finally release it at the end of the call. We will address the (quite important) concept of understanding the telephone number later. The other two circuit-related steps require that the switches exchange information. In the PSTN, this exchange is called signaling.

Initially, the signaling procedure was much closer to the original meaning of the word—the pieces of electric machinery involved were exchanging electrical signals. The human end user was (and still is) signaled with audio tones of different frequencies and durations.

As far as the switches are concerned, in the past, signaling was not unlike what our telephones do when we push the buttons to dial: switches exchanged audio signals using the very circuit (that is, trunk) over which the parties to the call were to speak. This type of signaling is called in-band signaling, and quite appropriately so, because it uses the voice band. There are quite a few problems with in-band signaling. Not only is it slow and quite annoying to the people who have to listen to meaningless tones, but also telephone users can produce the same tones the switches use and thereby deceive the network provider or disrupt the network.

To prevent fraud and also to improve efficiency, another form of signaling that would not use the voice band was needed. This could be achieved by using for signaling the frequencies that were out of the voice band (thus called out-of-band frequencies). Nevertheless, a channel in the telephone network is limited to the voice band, so there is no physical way to send frequencies beyond the voice band on such a channel. This limitation necessitated out-of-channel rather than out-of-band signaling. It was also obvious that much more information (concerning the characteristics of the circuits to be established, calling and called parties’ numbers, billing information, and so on) was required, and that this information could be stored and passed in the same form that was used for data processing. Hence (1) the information had to be encoded into a set of data structures and (2) these data structures had to be transformed over a separate data communications network. Thus, the concept of common channel signaling was born. Common channel signaling is signaling that is common to all voice channels but carried over none of them. Although it is clearly a misnomer, this type of signaling is often still called out-of-band signaling.

Let’s get back to the question of the switch understanding the telephone number. First of all, there are two types of numbers: those that actually correspond to the telephones that can be called and those that must be translated to the numbers of the first type. An example of the first type is a U.S. number +1-732-555-0137, which translates to a particular line in a particular central office (in New Jersey). An example of the second type is any U.S. number that starts with 1-800. The 800 prefix signals to the switch that the number by itself does not identify a particular switch or line (there is no 800 area code in the United States). Such a number designates a service (called toll-free in the United States or freephone in Europe) that is free to the caller but paid by the organization or person who receives calls.

Handling numbers of the first type is relatively straightforward—they end up in a switch’s routing table, where they are associated with the trunks or lines to be used in the act of establishing a call. The other (toll-free) numbers need translation. Naturally, a switch could translate the toll-free number, too, but such a solution would require tens of thousands of switches to be loaded with this information. The only feasible solution is to let a central database do the translation. The switch then needs to communicate with the database. [Note: The solution was figured out as early as 1979—see Faynberg et al. (1997) for the history.]

Another example where a database lookup is needed is implementation of local number portability (LNP). In the United States, the Telecommunications Act passed by the U.S. Congress in 1996 mandates the right of telephony service subscribers to keep their telephone numbers even when they change service providers. With that, subscribers can keep not only the numbers but also the features (such as call waiting) originally associated with the numbers. In the United States, the solutions are based on switches’ capabilities to query databases so as to locate the terminating switch when they encounter numbers marked as ported. (To be precise, this process requires two database dips—one to determine whether a dialed number is portable and the other to find the terminating switch.)

For both types of communications—out-of-band signaling among the switches and querying the database—the Bell Telephone System has designed a special data network called a common channel interoffice signaling (CCIS) network. When this network was introduced—in 1976—it was used only for out-of band signaling (hence interoffice). Thus the network served as a medium for communicating information about any trunk (channel) without being associated with that particular trunk. In other words, it was a medium common to all trunks, hence the term common channel. In the early 1980s, the network databases were connected to the network; thus signaling ceased to be strictly interoffice, and the I was taken away from the CCIS. Both the network and the concept became known as common channel signaling (CCS).

The architecture of the CCS network is depicted in Figure 1. The endpoints of the system are switches and network databases. The CCS routers are called signaling transfer points (STPs). Since all signaling has been outsourced to it, the CCS network must be as fast and as reliable as the network of the telephone switches. The reliability has been achieved through high redundancy: All STPs within the network are fully interconnected. Furthermore, each STP has a mated STP, with which it is connected through a high-speed link (C-link). Interconnection with other STPs is achieved through a backbone link (B-link). Finally, switches and databases are connected to STPs by A-links.

Figure 1: The common channel signaling (CCS) architecture.

Historically, there are two distinct types of protocols within common channel signaling: (1) interactions between the switches and databases that started as simple query/response messages for number translation and have evolved into service-independent protocols that support multiple services for IN technology; and (2) the protocols by means of which the switches exchange information necessary to establish, maintain, and tear down calls.

The CCS network has evolved through several releases and enhancements in the Bell System, and subsequently other telephone companies, which eventually resulted in multiple CCS networks. To ensure the interoperability of these networks as well as multivendor equipment interoperability in each of them, ITU-T has developed an international standard for common channel signaling. The latest release of this standard is called Signalling System No. 7 (SS No. 7).

Note that the official ITU-T abbreviation of this term is SS No. 7; however, the unofficial (but much easier to write and pronounce) term SS7 is used throughout the industry.We use the official term whenever we refer to the standard or its implementation in the network; we use SS7 when we refer to new classes of products (such as the SS7 gateway).

Signaling : In-Band Signaling,

Signaling is the process of transferring control information such as connection addresses, call supervision codes, or other connection information between communication switching equipment and other communications equipment or systems. The basic functions of signaling include initiate a call or line connection (call setup), maintain a communication link, and to end a call or connection (call teardown). Signaling comes in two basic forms: in-band signaling and out-of-band signaling.

In-Band Signaling
In-band signaling sends control messages in the same communication channel that is used for voice or data communication. During the period of in-band signaling, the voice or data communication is temporarily inhibited (muted) to allow the transfer of control messages. The types of in-band address signaling include dial pulse (DP), dual-tone multi-frequency (DTMF), MF (Multi-Frequency), audio signaling, and line control.

Dial pulse (DP) signaling senses and counts the changes in current flow, such as from a rotary dial telephone, to allow the user to send address information (dialed digits) to the telephone system.

DTMF signaling is a means of transferring information from a user to the telephone network through the use of in-band audio tones. Each digit of information is assigned a simultaneous combination of one of a lower group of frequencies and one of a higher group of frequencies to represent each digit or character.

Multifrequency (MF) signaling is a type of in-band address signaling method that represents decimal digits and auxiliary signals by pairs of frequencies from the following group: 700, 900, 1100, 1300, 1500, and 1700 Hz. These audio frequencies are used to indicate telephone address digits, precedence, control signals, such as line-busy or trunk-busy signals, and other required signals.

On modern telephone systems, most in-band signaling only occurs between the end-user and his serving central office telephone switch.

These signals travel over the same audio line as the voice or data call. Examples of other these in-band signaling messages include:

- Dial tone (the circuit is working)

- Busy tone (the circuit is unavailable)

- Fast busy tone (the system is busy)

- DTMF or pulse digits (send dialed digit information)

- Special functions such as # and * (activate other services)

- Telephone systems also can sense line condition as a signaling method. When the central office senses a grounding of the line (ground start) or a reduction in voltage (off-hook loop-start), it produces a dialtone signal (audio signaling) to inform the user service is available. Wink start is another line activation signal that is used by the telephone switch to indicate to end-user telephone systems of a change in status. Wink signals are brief 140 msec interruptions of communication.

Out-of-Band Signaling
Out-of-band signaling is signaling that travels over a separate path from voice and data calls but carries control information about the calls such as call setup, call routing, caller-id, call tear-down, etc. For out-of-band signaling the telecommunication industry uses a standard called Common Channel Signaling and Control (CCS). The current version of CCS is known as Signaling System 7 (SS7). Through standardization all telephone companies implement SS7 and thus can interact smoothly with very few errors.

Using SS7, switches can more effectively route calls and even query centralized databases for additional control information. The advent of SS7 has brought with it many new features such as caller-id. It has also been instrumental allowing for the phenomenal growth the industry has seen.

Control Message Signaling [Simple Telecom]

Control message signaling (commonly called “signaling”) is the process of transferring control information such as address, call supervision, or other connection information between communication equipment and other equipment or systems. There are two methods used for signaling: in-band and out-of band signaling.

In-Band Signaling
In-band signaling occurs when control messages share the same communication channel as the information signals (e.g., within the audio signal bandwidth). In-band signaling requires the users voice or data information to be momentarily interrupted or altered while signaling messages are being transferred. In-band signaling is sometimes called blank and burst signaling.

Figure below shows the process of in-band signaling. This diagram shows that a signaling message has been created to control the communications line (e.g., to transfer a call). To allow the transmission of the control message, the information is temporarily inhibited (or discarded) and the control message is sent on the same channel.


In-Band Signaling

Out-of-Band Signaling
Out-of-band signaling is a process of sending control signals outside of the communication channel that is in use (e.g., outside the audio signal frequency range). Out-of-band signaling allows uninterrupted communication while the users voice or data information is being transferred.

Figure below shows how out-of-band signaling occurs. This diagram shows that a control message can either be sent on the same channel but in different time slots than the information (e.g., voice) signal or over a separate control signaling network (called common channel signaling).


Out-of-Band Signaling