The first step towards next generation networks was to replace the core TDM-based networks with SIP components (please note that most of the argumentation here applies just as well to BICC networks). Strangely enough, the usage of IP-based technology usually stops at the borders of the network. TDM is still the basis for interconnection with other operators or even with other divisions of the same company. This is rather inefficient due to multiple reasons:

• QoS reductions: Moving from IP to TDM and possibly back to IP means that the voice communication will have to be transcoded from IP packets to TDM and back to IP packets. This will introduce delays and possibly losses.
• Service limitations: As TDM networks are designed for voice only, any other service such as video or messaging can not be exchanged transparently between operators. Actually, not even high quality voice can be used in an end-to-end manner as both operators will have to agree on G.711.
• Costs: One of the main reasons for moving to IP-based core networks was to reduce costs. The same should apply to peering.

Monetary aspects certainly play a role in delaying the all-IP interconnection. Especially smaller providers of VoIP services seem to be making a living off of the termination fees they receive from their TDM peering partners. Hence, they do not show much willingness to move to a pure IP-based interconnection which is usually though to be free or based on some flat rates as is the case with interconnection of pure IP packets.

However, this does not explain why TDM is still the prevailing interconnection technology between large operators or between the divisions of the same operator.

Looking deeper into this issue we can identify the following reasons for why VoIP peering is not so popular yet:

• Timing: Lots of operators have just finished igrating their core networks to SIP, and hence it is only natural that they are taking their time to go into the next step.
• Organization: Interconnection infrastructure is often managed by a different organization than the mobile or fixed divisions inside an operator. In order to go IP, the interconnection division would have to be convinced to move to IP. as well.
• Security: VoIP as an IP based application still has the taste of something unknown und insecure to many operators. With TDM, there is already a long history and extensive experience in all kinds of troubles that might arise. Operators know how to deal with fraud and interoperability problems in TDM and have established solutions to deal with these issues. VoIP technology poses new threats and problems that require new solutions and often a non-negligible learning curve.
• Interoperability: Even after years of standardization and interoperability testing it is not uncommon to have interoperability issues between SIP equipment from different vendors. Solving the interoperability issue when rolling out a VoIP core network is rather straightforward. The vendors selected by the operators will most likely not get paid until all interoperability issues are solved. In the case of a peering scenario with other operators this is not as simple. Different operators and even different divisions of the same operator will have their own equipment. The willingness to change the configuration of one’s own equipment or to pressure a vendor to update an implementation will not be too high.
• Monetary: Especially in the case of large operators interconnection costs over TDM are predictable and low. Hence, the costs of moving to a new technology and establishing new business relations might not be economically justifiable. 

When a SIP endpoint is ready to register with a service, it has the name of the service and the Address of Record (AoR) that it wants to register under. Both of these are constructed as SIP URIs. For example, my phone might register sip:Robert.Sparks@tekelec.com by sending a REGISTER request to sip:tekelec.com. It takes the domain name from that URI and uses it to start a series of DNS queries as specified in RFC 3263 : Locating SIP Servers.

The algorithms specified in that RFC allow an endpoint to learn what transport (UDP, TCP, TLS over TCP, SCTP) to use, and what IP address and port to send the message to. They also give the service provider tools to provide redundancy and load-leveling. Here’s a short overview of how it works:

The endpoint will first make a query for all Naming Authority Pointer (NAPTR) records for tekelec.com. These records allow service providers to advertise various services. The records that are returned might look like this:

The service field contains strings like “SIP+D2U” identifying the service being advertised – the full set of strings currently defined for SIP is:

  SIP+D2T (SIP over TCP)
  SIPS+D2T (SIP over TLS over TCP)
  SIP+D2U (SIP over UDP)
  SIP+D2S (SIP over SCTP)
  SIPS+D2S (SIP over TLS over SCTP)

As new service strings are standardized, they will be registered with IANA.

The order and service fields allow the service provider to say things like “If you support it, you must use TCP” or “Try TCP first and if that fails, try UDP”. The numbers are processed from lowest to highest. Records with lower order values are inspected first. Once a record is found with a protocol the endpoint supports, it will only consider other records with that same order value. When multiple records appear with the same order value, they are considered in preference order.

Some examples:

If these records are returned, the service is saying “If you support TCP, use that. If it fails stop. Only try UDP if you don’t support TCP.”

  tekelec.com. IN NAPTR 10 50 “s” “SIP+D2T” “” _sip._tcp.tekelec.com.
  tekelec.com. IN NAPTR 20 50 “s” “SIP+D2U” “” _sip._udp.tekelec.com.

If the following records are returned, the service is saying “Try SCTP first if you support it. If you don’t or it fails, try TCP. If you don’t support that, or it fails, try UDP”:

  tekelec.com. IN NAPTR 50 10 “s” “SIP+D2S” “” _sip._sctp.tekelec.com.
  tekelec.com. IN NAPTR 50 20 “s” “SIP+D2T” “” _sip._tcp.tekelec.com.
  tekelec.com. IN NAPTR 50 30 “s” “SIP+D2U” “” _sip._udp.tekelec.com.

Let’s proceed assuming those last three records were returned, and that the endpoint I’m using only supports TCP and UPD. In this case, the endpoint will use the second of those three records, learning that it should use TCP and it should take “_sip._tcp.tekelec.com” as input into the next step.

The endpoint now queries the DNS for all the SRV records matching “_sip._tcp.tekelec.com”. The SRV records returned will have this form:

The endpoint will process all records ordered by the priority field, from lowest to highest. If multiple records have the same priority, the endpoint will choose randomly from them, weighting the probability of selecting a particular record using the weight field. This gives the service provider a tool to realize a form of load distribution.

Assume the following records are returned:

_sip._tcp.tekelec.com. IN SRV   10 1 5060 crowned.tekelec.com.
_sip._tcp.tekelec.com. IN SRV   10 1 5065 crested.tekelec.com.
_sip._tcp.tekelec.com. IN SRV   10 2 6065 golden.tekelec.com.

The endpoint will randomly choose crowned.tekelec.com 1/4 of the time, crested.tekelec.com 1/4 of the time, and golden.tekelec.com 2/4 = 1/2 of the time. Lets assume the random selection chose crested.tekelec.com.  The endpoint knows to use port 5065 when it sends its request.  

Finally, the endpoint looks up A or AAAA (depending on whether it is using IPv4 or IPv6) records for crested.tekelec.com, yielding the IP address to send.

At this point the endpoint has the information it needs to send the request to the right server.

That example assumed that the endpoint was starting with a SIP URI. The RFC 3263 steps are the same whether the endpoint is preparing to send a REGISTER request or an INVITE request to start a call.

Sometimes, the endpoint starts with an E.164 formatted telephone number instead of a SIP URI. The ENUM specs define how to convert that telephone number into a URI. Once the endpoint has performed that conversion, it follows the same RFC 3263 algorithm discussed above starting with that URI to find the server to contact.

While SIP provides great support for session management, it lacks capabilities to set underlying network QoS parameters or to support business rules that carriers need to offer differentiated services or to meet regulatory requirements.  Increasingly, these issues are being solved by using policy management in conjunction with SIP.

To facilitate information exchange between session management and policy, the Rx reference point, as defined in 3GPP TS 23.203, is used to exchange application level session information between the Policy and Charging Rules Function (PCRF) and the Application Function (AF). In the case of SIP-based session management the AF can be the P-CSCF, a Session Border Controller (SBC) or potentially a softswitch. Some typical use cases supported by the Rx interface include:

• SIP-based VoIP for cable MSOs: The cable MSO IP infrastructure is a shared IP pipe that can carry a variety of services, ranging from high speed data to VoIP or video conferencing. Cable IP networks also tend to be asymmetric – with greater bandwidth in the downstream direction (from the network to the customer). While voice traffic doesn’t require a great deal of bandwidth in either the upstream or downstream direction, it does require low latency and jitter in order to provide “PSTN” quality voice.

  Many cable MSOs have deployed a PCRF-based architecture to set the appropriate QoS for SIP initiated calls. In this case, the AF (which in the cable MSO scenario could be a softswitch) passes the SIP SDP parameters across the Rx interface using DIAMETER to the PCRF. The PCRF looks at the SDP parameters passed in the Rx message to adjust the DOCSIS parameters in the network to ensure the QoS is appropriate for the type of session, codec, or other parameters that are indicated in the SDP. Note the flexibility of SIP and Packet Cable Multimedia (PCMM) Architecture means the same infrastructure can support videoconferencing or any other SIP-based service. The very first market trial that Tekelec participated in for PCMM was a SIP-based videoconferencing service but this has tended to be a niche application for operators especially when compared to VoIP service.

• IMS-based Services for LTE based Wireless Networks: Many wireless carriers throughout the world have announced their support for LTE radio access networks (RANs) and for the Voice over LTE (VoLTE) work that is now being led by the GSMA. LTE based (RANs) have a number of benefits versus today’s RAN technology, including support for higher bandwidths, higher spectral efficiency, lower cost per bit and support for an all IP network (i.e., IP from the handset through the RAN into the core). The VoLTE architecture takes advantage of this IP infrastructure by specifying how IMS based core network can be deployed to support services such as voice.

  Similar to the cable MSO scenario above, the LTE RAN provides an “all-IP” pipe over which all services are carried.  A PCRF-based architecture is essential in ensuring that the appropriate QoS is set based on the type of service.  In an IMS based network the P-CSCF acts as the entry point to core network. The P-CSCF also translates the SDP body contained in the SIP INVITE message from the user equipment (UE) into DIAMETER over the Rx interface and sends it to the PCRF. In response to the received parameters the PCRF can:

  • Can choose to disallow a session setup If the SDP offer contains a codec or any other media characteristics that are not allowed by the service agreement the subscriber has with the operator,
  • Ensure that the user is entitled to use the service and authorize the radio bearer with the appropriate QoS,
  • Zero-rate the usage so the VoIP usage doesn’t count against the user’s data bucket in case the user does not have an “all you can eat” data plan,
  • Get the CALEA app involved if the call needs to be managed for legal reasons

In addition to these more common use cases, there is growing interest in the industry around other use cases.

• Significant interest is gathering around SIP trunking applications for commercial customers of cable MSOs.  The cable operators have been investigating how to do “T1-replacement” and other trunk-oriented voice offerings, but have mostly either restricted deployment to direct fiber-based plant or stayed at the small end of the SOHO market.  Now, with DOCSIS 3.0 bandwidth, PCMM QoS, and new eSBC products, they can make strong offerings to support trunk services at 12-, 24-, and higher line counts.  For these users, QoS control is seen as a baseline requirement and not an option.  Most frequently there is an SBC involved, which provides an Rx interface with the necessary parameters that can be used to set the appropriate QoS in the network based on call type.  While the line counts aren’t expected to be large initially it is helping to provide the “toe in the water” driving many operators to SIP with PCMM QoS on DOCSIS.
• Initial deployments of residential VoIP in U.S.-based cable companies were primarily been based on session management protocols such as the Network-based Call Signaling (NCS) and Media Gateway Control Protocol (MGCP) and the PacketCable 1.x specifications. These deployments are very cable specific and the number of vendors supporting them is relatively small. The cable operators are seeing the opportunity to evolve to a much more widely accepted standard, namely IMS. The evolution to an IMS core means that cable MSOs are getting ready to “cap & grow” and then migrate millions of lines to IMS with PCMM (PacketCable2.0). Given the use of IMS the obvious choice for managing QoS is a PCRF based architecture using Rx from the P-CSCF or an SBC.

Additional technical details on the topics discussed here, including the definition of the Rx interface, the signaling flows and Quality of Service (QoS) parameter mapping and the Rx protocol definition can be found in 3GPP technical specifications TS23.203, TS29.213 and TS 29.214.

After about 10 years of SIP it may be worthwhile to look back at how it gained its position. Back at the turn of the century it was not clear at all if H.323 or SIP would gain the upper hand. In fact, H.323 was by then enjoying the first mover’s advantage both in terms of standards and deployments. Nevertheless, it was eventually SIP that gained the upper hand.

Initially, it was the standardization argument which gave SIP an advantage. SIP became part of the 3GPP reference architecture. Today, both numerous international and standardization bodies preoccupy themselves only with SIP (i3 Forum, PacketCable, Germany’s national regulator, etc.)

Technical arguments played a noticeable role, as well. A Nortel report dated January 2000 comparing SIP to H.323 highlighted the following arguments in favor of SIP: lower complexity, easier trouble-shooting, extensibility, interoperability, inter-domain capability and more. A NOSDAV paper (c. 1999) by SIP proponents suggested similar arguments and listed, for example, a superior PBX-feature support in SIP and the stateless nature of SIP.

Certainly, the most convincing arguments were visionary. SIP presented a promise of a native Internet end-to-end service combined with application richness. As a result, new H.323 deployments are hard to find among operators today.

These standardization, technical and visionary arguments reveal a number of ironies. In fact, very little of the early advantages have survived today, and the technical arguments are almost completely invalid. Particularly, SIP’s complexity is best documented by the number of standards or the “Hitchhiker’s Guide to SIP,” aka rfc5411. Interoperability of more complicated features in multivendor PBX environment is still perceived as immature. While the 3gpp/IMS standardization argument helped to push SIP forward, trunking and residential traffic prevails over the IMS flavor. The majority of the traffic is not even resembling the end-to-end vision: most of the SIP calls visits also PSTN or Skype, and rarely conveys anything else than voice.

In summary: a vision which didn’t materialize has won.

By Jan Janak

There is no doubt that VoIP systems, being used by ever increasing number of people as a primary means of communication, have been growing bigger and bigger in recent years. Skype, a popular peer-to-peer communication service, has tens of millions of users online at any given moment. Some of the largest Session Initiation Protocol (SIP) based VoIP systems have millions of phones online all the time. All these devices, ranging from small desk phones to regular PCs and servers needed to support the infrastructure, form a large ecosystem of devices that are turned on most of the time. While we tend to turn off our PCs and laptops when we do not need them, our phones remain turned on all the time to receive incoming calls.

Given that the costs of energy have been steadily increasing over the years and this trend is unlikely to change in the foreseeable future, we have been wondering what we can say about energy efficiency of existing VoIP infrastructure.

How much energy is consumed by a SIP phone sitting quietly on our desk? How does it compare with a desktop PC or a laptop? How much energy consumed by an idle desktop PC can be attributed to the Skype client running on the PC solely for the purpose of receiving Skype calls? How does the power consumption of a VoIP system increase with growing number of phones? Is Skype “greener” than traditional SIP based VoIP systems because it uses no servers?

These are some of the questions we would like to answer so that we can offer our customers more energy efficient solutions. We attempted to answer some of these intriguing questions in the paper “How Green is IP-Telephony?” 

We gathered information about existing client-server (SIP) and peer-to-peer VoIP systems and evaluated their power consumption and relative energy efficiency through analysis and a series of experiments. Contrary to the recent work on energy efficiency of peer-to-peer systems, we found that even with efficient peers a peer-to-peer architecture, such as Skype, can be less energy efficient than a client-server SIP architecture. We also found that the presence of NATs in the network is a major obstacle in building energy efficient VoIP systems, both in fixed-line and mobile phone networks.

The paper was selected for publication at the First ACM SIGCOMM Workshop on Green Networking and will be presented there this week. I’m looking forward to hearing the feedback on this topic.

Jan is a founding member and one of core developers for the sip-router.org project, a group of developers working on a freely available high-performance SIP server. Currently, he is a senior software architect at Tekelec. His responsibilities include design and implementation of high-performance SIP software and solutions for next generation mobile networks.

Previously, Jan was co-founder and chief software architect at iptelorg GmbH, a German start-up company developing and deploying solutions based on the SIP protocol for large-scale Internet telephony services providers. The company was acquired by Tekelec in 2005. Prior to joining iptelorg GmbH, Jan was researcher at Fraunhofer institute FOKUS, working on the design and implementation of the SIP Express Router, high-performance free SIP server.