In this showdown BleedingVoIP will look at the two of the leading VoIP vendors signaling protocols. Due to the fact that signaling lies at the core of any VoIP system, it is interesting and insightful to look into how competing armies control their forces. Before we dive deep into the mechanics and details of each let’s spend some time to better understand what signaling is and why is important.

Signaling protocols are used to identify signaling encapsulation. They are the codes and commands used to establish and terminate a phone call over an IP network. The protocols support such features as conference calling, call waiting and call transfer. The primary "open" IP telephony signaling protocols are H.323, SIP and MGCP/MEGACO. There are also proprietary protocols, those that we will look at today; Nortel Network's UNIStim and Cisco Systems Skinny protocols provide the bulk of functionality found in their VoIP solutions. Although the aforementioned vendors, among others, have pledged a migration path to SIP, this process will take time and suffer from guaranteed delays. Until that time I do not see SIP as being highly prevalent in the enterprise other than for functions such as trunking over SIP-T, a function that exposes a minimal risk plane if properly provisioned.

I will start by giving a high level description of each protocol and followed by a breakdown of each, while in parallel drawing comparisons between both. I will not dive too deep into each signaling protocol itself, as it is dangerous and I don't feel its necessary to get my point across.

UNIStim

UNIStim was born on May 17th, 2000 when the first draft for internal review came to be related to developing a complete and robust VoIP protocol that would be used as the backbone of VoIP systems from Nortel in the 21st century. Never having spent any time at Nortel myself, one would as how I could acquire such knowledge. Simple, the underground community of hackers is always there to help a friend out. I digress, and start talking in Nortel lingo; the UNIStim protocol was developed to provide messaging support for the connection of a client Internet Terminal (IT) such as an Ethernet phone to a host server providing telephony services over an IP network. In Nortel's verbiage, the host server is referred to as the Network Intelligence (NI).

UNIStim is a stimulus protocol that provides a command set which enables the NI to control every aspect of an IT's operation. For those of who are still green in VoIP verbiage, stimulus refers to a protocol that is used to carry event notifications between end points. Such a protocol is used to control the operation of devices at each end of the link, while being agnostic to the system state and is most suited to networks with dumb peripherals and intelligent centralized applications.

Moreover, RTP streams are used for voice transmission while UDP sits at the transport level. However, UNIStim protocol requires a reliable transport layer to be able to deliver signaling services in a robust manner, similar to TCP. To address this Nortel, more accurately Bell Labs, developed what it called Reliable UDP (RUDP), a layer 7 addition that would turn UDP into a mutated version of TCP; it was originally intended for the Plan 9 OS. Out of this work came a customized and simplified version for use in VoIP systems. For the remainder of our discussion here when I refer to RUDP, I refer to version for Nortel VoIP systems and not the common-place version you can find in RFCs 1151 and 908. To conclude, all of this magic rides on top of IP.

The IT software architecture supported by UNIStim is characterized by a set of functional element managers, each responsible for a particular aspect of setup and operation. The UNIStim commands are grouped according to the functional element manager they control. The element managers and their functions are as follows:

• The Broadcast Manager is responsible for such things as icon, character table and time/date downloading for both the IT and any attached accessories.
• The Network Manager is responsible for configuring and maintaining the network connections between the NI and the IT.
• The Basic Manager handles IT maintenance functions such as self testing.
• The Key/Indicator Manager is responsible for the IT keys and indicators including setting LEDs and icons, reacting to key depressions and detecting on-hook and off-hook conditions.
• The Audio Manager looks after every aspect of the audio configuration of the IT. The main tasks of the manager are to configure the loss plan and tones, set up voice paths and establish end-to-end voice connections.
• The Display Manager has as its main task the presentation of the information sent by the NI on the LCD. The NI does not have to know where the information is physically presented. Another function of the display manager is to configure multi-language character tables.

Furthermore, UNIStim IT's can only exist in a few states. They are:

• unregistered
• registering
• registered
• on hook
• off hook
• in call

Let's dig a bit deeper into the basic layout of a UNIStim packet riding with RUDP.

What is interesting to note here, and what we will look at later is RUDP, in particular what benefits it could provide over the standard, reliable TCP it is trying to emulate.

Skinny

Skinny was born sometime prior to 1998 when Cisco acquired Selsious Corp., the original inventors of the protocol. Historical remnants of the acquisition can still be seen today, as all phones are named SEP followed by their MAC address on today's Call Managers, where SEP stands for Selsius Ethernet Phone. The Skinny protocol was developed to provide messaging support for the connection of a client Skinny Client (SC) such as an Ethernet phone to a host server providing telephony services over an IP network. In this specification the host server is referred to as the Call Manager (CM).

Skinny is a stimulus protocol that provides a command set which enables the CM to control every aspect of an SC's operation. RTP streams are used for voice transmission. In contrast to UNIStim, Skinny rides on top of TCP and takes advantage of all of its built-in reliability features. All of this, of course, rides on top of IP.

The Skinny architecture is much simpler than that of UNIStim. There is really one main concept, called a message, which identifies and encapsulates some logic that either CM wants the SC to perform or vice-versa. Similar to UNIStim, Skinny's SC's go can only exist in a few states. They are:

• unregistered
• registering
• registered
• on hook
• off hook
• in call

Let's look at a typical Skinny packet.

What you will immediately notice is the simplicity of the protocol, namely due to leverage of TCP's functions. Look deeper (as we will) as discover that there are advantages to keeping a game simple.

UNIStim vs. Skinny features

 Skinny and UNIStim are both stimulus protocols that ride on top of some reliable transport layer for delivery. Both are used as primary signaling protocols for each of the respective vendor's VoIP systems. Both allow for arbitrary messages to be sent from one party to another. In general, they look very similar. Of course, they should! Why would they be so different? We are talking about VoIP signaling aren't we? 

 One of the only places where they could draw some differences would be in the messaging "encyclopedia' as I call it. Each could have a different set of requirements as dictated by the endpoints and servers that they support. But, are Nortel's and Cisco's VoIP systems that different? Is there some overwhelming disparity between what Cisco engineers have implemented versus Nortel? Definitely not; at least not at the signaling layer.

 Apart from subtle nuances of who has what displays, at what resolutions, what type of packets are generally sent went initiating a call for conferencing, etc. there is nothing exciting - trust me.

Thus, I would conclude that both are tied here as no vendor’s pulls far enough ahead of the other in support at the signaling protocol layer to trounce the other

Winner: Tie 

TCP vs. RUDP

  TCP and RUDP both have the same mandate; to ensure reliable in-order delivery of messaging. If both satisfy this requirement, why two protocols? Apart from shades of grey, it is due to that fact that TCP is a connection-oriented protocol while UDP is not. These protocols require that a logical connection be established between two devices before transferring date. This is generally accomplished by following a specific set of rules that specify how a connection should be initiated, negotiated, managed and eventually terminated. Usually one device begins by sending a request to open a connection, and the other responds. They pass control information to determine if and how the connection should be set up. If this is successful, data is sent between the devices. When they are finished, the connection is broke. In contrast, UDP is connection-less, where none of the above must occur for any data transfer to occur it is simply fire and forget.

One could quickly see why pure UDP would be a disaster as the transport medium for VoIP signaling; you have no traceability of where your packet really is, did the other side receive it? How long did it take, what happened on its way there, the list goes on. This is why a reliable UDP system must exist if UDP is to provide competition to TCP.

Let's get it out of the way now; I prefer and support any team that supports TCP over RUDP. For the simple reason that if TCP is used elegantly by clever people it offers enormous benefits that I'll elaborate on later over and reliable UDP system. Further, I assume you have some knowledge of acronyms and terms related to protocols; if not Google is just a tab away.

I won’t bore you with a re-hash of TCP and why it is so good. You can spend weeks reading on Google and sifting through Linux source code. For me what's important is to unravel RUDP from Nortel's VoIP systems so we can have a comparison. Again, anyone with good knowledge of C, some connections to underground and Asterisk source can write about RUDP at verbatim. It aims to provide a solution where UDP is too primitive because guaranteed-order packet delivery is desirable, but TCP claims to add too much complexity/overhead.

It extends UDP by adding the following additional features:

1. Acknowledgment of received packets
2. Limited Windowing and congestion control via ACK starvation
3. Retransmission of lost packets
4. Sequence and in-order delivery

 The traffic pattern between the ITs and the NI consists of bursts of 1 to 4 packets followed by long, non-deterministic delays between each burst. Such small numbers of packets in a burst is made possible by bundling many UNIStim commands in a single UDP packet. Given the small number of packets in a burst, there is no requirement for great complexity in the RUDP layer for reducing retransmission traffic or the RUDP layer’s control packets (ACK and NAKs) since the traffic reduction would be insignificant. Assuming that the IT and the NI are engineered to cope with the worst case traffic load that they are likely to experience in the course of their operation, the reliable UDP layer does not need an elaborate flow control scheme such as a sliding window. However, recognizing the fact that flow control capabilities are important if the system gets unexpectedly overloaded, the RUDP layer does provide a basic flow control scheme based on ACK starvation. The design assumes that the network will be engineered for IP telephony, i.e. low latency and high reliability, and so uses time-out values that would be considered “aggressive” in conventional networks.

 In detail, two main parameters, performance and complexity, drive the choice of error control scheme. A term called Go-Back-N represents a good trade-off between those two parameters. The transmitter does not have to wait for an acknowledgement before it sends the next packet. The transmitter is responsible for appending a sequence number to every outgoing packet, and for managing retransmissions based on incoming ACK/NAK’s and timeouts. The receiver is responsible for generating ACKs for every correctly received packet, and NAKs for packets received out of sequence. The following list highlights the key features of

The Go-Back-N error control flow:

• Every packet sent contains a sequence number
• Every packet received in sequence generates an ACK containing the sequence number of the packet
• The first packet received out of sequence generates a NAK containing the sequence number of the packet that was expected and all subsequent packets are ignored until the expected packet is received
• Every packet that is not acknowledged after a time-out period is re-sent
• When a NAK is received, the transmitter restarts the transmission at the sequence number contained in the NAK packet
• An ACK received for packet n automatically acknowledges all packets that have been transmitted before packet n and have not yet been acknowledged
• Repeated, already ACKed packets, are ignored by the receiver and are re-ACKed
• ACKs for packets that were already ACKed are ignored.

Although this scheme does not explicitly have a sliding window mechanism, there is an implicit window that is imposed by the finite amount of memory available at both endpoints.
In the context of Go-Back-N, the transmitter manages two main tasks. The first consists of appending a sequence number to every outgoing packet. The other is managing the retransmissions based on incoming ACK/NAKs and time-outs. The receiver is responsible for generating ACKs for all correctly received packets and NAKs for packets received out-of-sequence.

The transmitter adds a sequence number to every outgoing packet. This sequence number is used at the receiver side to ACK in-sequence packets and NAK out-of-sequence ones. The sequence number is a 32-bit unsigned integer. For security reasons, the sequence starts at a random number in the range 0 to 65535. Since the sequence number spans 32 bits, it is assumed that it will never wrap-around (232 = 10 packets/second over a 13.6 year period). The sequence number occupies the first four bytes of the UDP payload (Most Significant byte first). The data to transmit follows the sequence number. 

 The retransmission mechanism is the key element of any error control scheme. In Go-Back-N, the error control scheme relies on ACK, NAK and time-outs to ensure a reliable data channel. In a perfect network, every packet sent by the transmitter is received in sequence by the receiver which fires an ACK containing the sequence number of the packet back to the sender. However in a real network, packets can be lost, received out-of-sequence or delayed. To account for those intrinsic impairments the transmitter and receiver have to implement the rules of the Go-Back-N retransmission mechanism to maintain reliable communications, as described below:

Rule 1 - A received ACK for packet n acknowledges all preceding packets
Since Go-Back-N generates a NAK for every packet received out-of-sequence it can be assumed that when an ACK for packet n is received, all the packets < n were successfully received by the receiver. Here is an example: the transmitter doesn’t receive ACK n-1 but receives ACK n. The latter ACK indicates that the receiver has successfully received both packets n-1 and n. This assumption is accurate because if packet n-1 wasn’t received but packet n was, the response from the receiver would have been NAK n-1 to indicate that packet n was received out-of-sequence as it expected to receive packet n-1. Also, the reception of NAK n also implies that the receiver successfully received all packets up to n; as a result it implicitly ACKs all packets < n.

Rule 2 - A received NAK n forces transmitter to go back to n
A NAK n is generated by the receiver when it expects to receive packet n but receives packet x instead, where x > n. The NAK message indicates an out-of sequence reception. When the transmitter receives a NAK n, it “goes back” (hence the name) and retransmits all frames starting with the one specified in the NAK message. Once the receiver originates a NAK, it ignores all subsequent packets (unless the packet has sequence number 0xFFFFFFFF) until it correctly receives the next expected packet which is n.

Rule 3 - Every packet that is not acknowledged after a time-out period is re-sent
Every packet sent by the transmitter has an associated timer. If packet n isn’t ACKed (by receiving an ACK for packet >= n) before its timer expires the transmitter will retransmit packet n. The transmitter will try to re-transmit packet n for a certain amount of time before it considers the network connection dead and begins recovery procedures. Some error control schemes have a back-off procedure to prevent the network from being flooded with increasing traffic when it goes down. Go-Back-N doesn’t support a back-off scheme since it assumes that the outages will be punctual and of relatively short duration. As such, the majority of the endpoints will not notice the outage since they will not attempt control packet transmissions during the down period. The endpoints that will notice the outage will retry transmissions for a certain period of time after which they undertake recovery procedures. Details of the recovery mechanism are outside the scope of this document. However, it is recommended that this recovery procedure include periods of silence to avoid packet storms in case the outage persists for a longer-than-usual period of time.

It is possible for the receiver to receive duplicate copies of a packet. The receiver must acknowledge the duplicate copy even if it has already received it. The time-out interval has to be chosen such that it is greater than the estimated round trip time (RTT) experienced on the network. The time-out interval, which can be configured using UNIStim commands and has a default value of 500ms. The maximum number of retransmissions due to time-outs is also a parameter that is configurable using UNIStim commands and is set at 10 by default.

 So far we have discussed Go-Back-N for one-way communication only. However, it could easily be used for two-way communications by maintaining two independent one-way error control state machines and queues so that both sides would be a transmitter as well as a receiver.

 I hope I have not discouraged you from reading further; this is really interesting stuff, the guts. As you can see RUDP is much more complex than the standard UDP, one would argue that it implements an efficient subset of TCP even. Maybe. I don't agree. Knowing networks, networking internals and kernel systems in places such as Linux, let me tell you that TCP wins for me because it is proven, standard and has been around for many years. Why do you think there is no official RFC standard for RUDP? Time? I don't think so; it is the simple fact that each vendor tweaks UDP to their desire to get a reliable version. I like stable, proven and robust systems. Judging from personal experience in the VoIP security space with Nortel RUDP, my case is only strengthened.

 And I haven’t even talked about security in detail! I left it to its own section because it become even clearer why Cisco chose TCP and why in my opinion TCP wins. Feel free to bombard me with your own view of things

Winner: TCP 

Security Comparison

My favorite part; I won’t spend long getting to the end because it’s very simple. Skinny+TCP wins security hands down. Actually, security is associated with a connection-oriented system by default. Connection-less systems cannot have sophisticated security built in. You already must be familiar with terms such as TLS, SSL; most likely the later. Well, all of those ride on TCP and provide you with bulletproof authentication and encryption mechanisms if properly used (at least until someone implements a real quantum processor).

UDP on the other hand and RUDP by that have 0 security from the perspective of encryption and true authentication built in. Yes, you can implement any authentication and encryption schema at the application level, but what the point, it’s not scalable form the architectural point of view, especially if you want a heterogeneous use of your stuff. DSO how does Nortel allow you to sleep at night? The SMC 2450. This beast is really a proxy that is going to have to sit somewhere midstream and take care of ensuring that after a certain point, all packets are encrypted and authenticated. But, there a catch; it’s not point to pint from phone to phone. It is phone to proxy to proxy to phone. If you feel that’s exciting then OK, I’m not too excited - pushing another product to offset the deficiency of UDP.

We’re almost done. Before I go I want to talk a little about IPSec. IPSec delivers SSL style security and more across any transport mediums by sitting one layer below TCP and UDP. As such some claim that my above discussion is irrelevant and we should all switch to IPSec, dump whatever traffic we want on the pipe and we’ll be safe. Maybe, maybe not. First of all IPSec is a big hype and was and still is an administrative nightmare. This whole PKI thing is and won’t be scalable for the VoIP space. Why, there a laundry list, from establishing true trust points, administering certificates, provision hop-points, compatibility at the switch/router plane, etc. If they could only simplify the whole thing, IPSec could be a real winner.

Winner: Skinny

Overall Winner: Skinny

My acknowledgments go to my friends in the underground community and the wonderful source code of the open source PBX "Asterisk", really a jewel for reference. Feel free to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it and stay tuned for more BleedingVoIP Showdowns.

This article is subject to copyrights against its respective writer. Feel free to contact them if you wish to use the article in some intermediate form.

---