This is the final post in the series on SIP-I and SIP-T deployment challenges. You may wish to read the Introduction to SIP-I and SIP-T post for some general background on these two protocols before continuing.

The difficulties in interworking features between the PSTN and SIP networks stem predominantly from two areas. The first is the different models for where services are implemented — the PSTN expects them to be performed by the network, while SIP is designed for them to be implemented in the end points. The second is the fact that SIP defines tools instead of named services, while the PSTN relies on a discrete and highly constrained set of standardized services.

To be clear, most basic services work just fine in a mixed-protocol network. Call waiting, call forwarding, calling party identification — in fact, almost all of the most popular PSTN CLASS services work just fine.

A good demonstration of how these two issues can cause problems is the class of services commonly known as “Call Completion.” (This service goes by a large number of other names, such as “Auto Callback” and “Camp On Extension.”) At a high level, the call completion service works as follows: a calling party attempts to contact a called party; however, the attempt is unsuccessful (either because the called party is busy or because they do not answer). The calling party then activates the Call Completion service. When the called party become available (is no longer busy, or demonstrates availability by changing hookstate), the calling party is alerted. The calling party then picks up the phone, and the call proceeds as normal.

To examine why this is not trivial to interwork, we need to understand how ISUP implements this service and how SIP implements it.

The ISUP version of this service is defined in the ITU-T documents Q.733.3 and Q.733.5. At a high level: during a call setup attempt, the ISUP Address Complete (ACM) message includes an indication that a called party’s end office supports the Call Completion service. If the calling party wants to activate the Call Completion service, then TCAP is used to convey an activation request. When the called party is available, TCAP is again used to indicate that the remote user is free. The calling party’s end office alerts the calling party and waits for their phone to go offhook. The end office then attempts a new call to the called party. The ISUP Initial Address Message (IAM) indicates that this call attempt is a result of the Call Completion service, to allow proper handling at the called party end office. From this point, the call proceeds pretty much as normal.

The overall call flow looks something like this:

By contrast, the tool SIP uses to perform this service is the dialog event package, defined in RFC 4235. The dialog event package allows a user to subscribe to the state of sessions at another user’s device or devices. In other words, by subscribing to the dialog event status of another user, I can tell whether that other user is busy in one or more calls. I can also tell when their terminal goes on-hook or off-hook (when those concepts apply to the terminal they are using).

Of couse, this tool enables a lot more than the Call Completion service — but it can be used to implement a Call Completion service in the SIP network. At a high level, the call flow actually looks pretty similar to the SS7 version: the calling party sends an INVITE to the called party, which indicates support for the dialog event package in its provisional responses (e.g., 180 Ringing) and final response (e.g., 486 Busy). The calling party can then subscribe to the dialog event package, and learn when the called party is available again. (This can be greatly enhanced using SIP presence information about the called party, but we’ll stay focused on replicating the PSTN functionality in this example.) The calling party’s terminal then tracks the state of the called party’s calls and terminals. When it determines that the called party is available for a call, it alerts its local user, and sends a new INVITE to the called party.

The call flow looks something like this; note that no network servers are shown in this call flow because they do not participate in the service:

The issue that arises is due to the difference between ISUP’s call completion service and SIP’s dialog event package tool. ISUP’s service is very narrowly focused on making this one specific use case work. None of its procedures or messages can be re-used to implement new services. By contrast, the SIP tool can be used for myriad services, such as enhancing multiparty conferences, enabling certain types of advanced third-party call control, and implementing shared-line behavior on multiple devices. And, of course, it can be deployed in new and clever ways to create services that we haven’t even thought of yet.

The problem is that the PSTN gateway can tell that the called party supports the call completion service, but can’t actually get more general information about the calls that the called party is involved in. And there is no way for the gateway to tell the calling party “I support the call completion service, but don’t have enough information to actually do the dialog event package” — because, in SIP, we use tools, not services.

Similar problem arise with distinctive alerting, call parking, line sharing, and several other advanced services. Luckily, the IETF has formed a working group, BLISS, to tackle these issues. BLISS has been working in concert with TISPAN and other standards groups to ensure that the solutions work well with existing solutions in the PSTN. So, unlike the other deployment challenges we’ve gone over, this one is likely to get better as time goes on.

Some time ago my colleague Jiri Kuthan recommended me to read RFC5218. In it the authors discuss what makes protocols succeed or fail. A successful protocol is defined as one that meets its design goals and is widely deployed.  The authors present some factors which they believe to be crucial for the success of a protocol and present some use cases in which they apply these factors to some successful and failed protocols. Among these factors the authors list the design, extensibility and openness of networking protocols.

While reading the RFC I started thinking, what would be the result of applying these factors on SIP:

Initial Success factors: These are the factors that help a protocol to become successful in the initial phase of their deployment

• Positive net value: SIP obviously solves a problem; namely that of establishing a session in IP networks. While SIP bears the promise of enabling all kinds of sessions it is mostly used for establishing voice calls. In this context it does not offer more functionality than traditional SS7 signaling, H.323 or Skype. The real positive net value of SIP is hence demonstrated when operators start deploying more SIP-based services such as presence and application servers that offer more flexible and intelligent communication services than we have today.
• Incremental deployment: SIP can be deployed without having to update the network routers. However, unlike the arguably most successful Internet protocol, HTTP, it is not sufficient to provide a server and a client. For a communication service to be of use there must be a lot of clients and users available. While there are already different providers offering VoIP services using SIP with millions of users, these providers act as islands that are connected over the PSTN. Hence, in order for SIP to excel on this point, more SIP-based peering between providers is needed.
• Open code availability: There are already different open source components needed for a SIP service. The SIP Express Router is an excellent and widely used SIP proxy. Asterisk and SEMS offer flexible and easy to use media services such as IVR or conferencing. On the user agent side, there are also different implementations of different quality.
• Restriction free: SIP is a provided as a patent free technology for all.
• Open specifications: The SIP specifications are provided by IETF and are open.
• Open maintenance: SIP is maintained by the IETF and is extended and fixed continuously. While this is surely a good thing, this has also led to a load of specifications that some might claim are too much.
• Good technical design: While SIP was being hailed at the beginning as the simpler alternative to H.323, it has gained a lot of weight over the years. Taking the same comparison factors used in RFC5218 – namely security and congestion control – then SIP does not seem so perfect as congestion control is not considered and it does not have a powerful concept for identity management. Also, deployment issues such as NAT traversal were only added at later stages.

Wild success factors: These are the factors that contribute to success and wide deployment:

• Extensible: While designed in the early stage for simple calls, SIP is now used for multi-party calls, presence and trunking scenarios. Also, the integration of new applications and services should be rather straightforward as SIP is not restricted to a certain usage scenario.
• Scalability: While we still do not have any experience regarding the cost and complexity of building a SIP infrastructure for hundreds of millions of users. I do not see a real reason why this could not be done.
• Security: SIP has different mechanisms for authenticating users and protecting the signaling traffic. However, it does not have explicit mechanisms for protection against DoS attacks or fraud.

Discussion

Looking at the points above it looks like SIP has more or less a positive result on the discussed factors. However, getting positive marks on the evaluation factors does not mean that a protocol will be a success. If we evaluate Skype based on these parameters then we should conclude that Skype should fail. There is no open source code or open specifications and the net value is not much higher than PSTN or SIP. However, the number of users of Skype is higher than that of SIP.

So does this mean that SIP will become a wild success? Well, I guess the answer is a very definite maybe! The success or failure of a protocol can only be judged 5 to 10 years after finishing the standardization – so we still have a few years in front of us. But, it has the needed success factors, and with more applications, peering relations and clearer business models, the chance that SIP will be wildly successful are pretty good.

Mobile data traffic is growing beyond our imagination. After the introduction of the latest iPhone in June, Google stated that the mobile upload of video increased by 400% over the previous day. The introduction of Android powered phones including the recently launched Nexus One will only increase this rate. Over the next four years, it is projected that global mobile traffic will exceed 50,000 Terabytes per day! I believe that this humongous data avalanche that is taking over the mobile world will remain the single most important factor that will influence mobile infrastructure trends in 2010 and beyond.

So if I have to pick the top three mobile infrastructure trends for 2010 what will they be?

• 3G/4G Network expansion will continue through this year at an accelerated pace. We will see more and more deployments of HSPA, HSPA+ and LTE.
• Convergence of Wireless LAN/WAN – Traffic growth may be huge, but operators are yet to find that magic formula to monetize all this traffic growth. That means cost optimization of network expansion is critical. Wi-Fi and Femtocell micro-sites will complement 3G/4G networks by offloading much of the data traffic.
• Just throwing money into mobile bandwidth infrastructure will not by itself address the problem of exploding mobile data traffic. Networks will get smarter in handling the traffic. Better traffic management and differentiated treatment of different traffic types are the essential short-term solution. In the long run, the industry also needs innovative pricing that monetizes different types of traffic that can fund infrastructure growth. Net Neutrality driven regulation may be a wild card that will influence this in certain regions, but I still think this will be the case globally.

What would be your top 3 trends?

As described in an earlier FAQ, SIP Events uses a notion of a “package” to determine what kind of information is being asked for, what kind of change will cause a notification to be sent, and what the available options are for encoding the information in a NOTIFY request.

The current set of standardized SIP Event packages is maintained at the sip-events namespace registry at IANA. At the beginning of 2010, there are thirteen registered packages, and one special thing called a “template-package”: winfo.

Subscribing to this template-package will give you “Watcher INFOrmation”: details of each subscription to a particular event. For instance, I could subscribe to “presence.winfo” for sip:RjS@tekelec.com to see who is watching my presence.

Template packages are never used directly – they must be applied to regular packages. In other words, it isn’t possible to subscribe to “winfo”, only to events like “presence.winfo” or “message-summary.winfo”.

The template package concept was introduced to make it easier to build packages that would extend every other existing package the same way. It would have been possible to build the same system without template packages by creating separate “presence-winfo”, “message-summary-winfo”, etc. packages, but each of those would have to respecify the common behavior. Having this meta-package tool avoids that extra specification work (and makes it less likely that watcher information for package “foo” and for package “bar” would behave in subtly different ways).

The concept has been with us for nearly a decade, and the only event-template package we’ve found a need for is winfo. It may be the only one that ever exists.

Like many aspects of SIP Events, winfo was driven by presence. When a new person tries to add me to their list, I need a way to find out so that I can give the service permission to hand my presence to that new person. My client needs a nudge so it can ask me whether I would like to allow or deny the subscription. Early attempts at a solution involved having the server send me a QAUTH request before answering the SUBSCRIBE from this new person. That turned out to be a dead-end for two reasons. First, like all SIP non-INVITE requests, QAUTH had to get an answer within 32 seconds (64*T1, where T1′s default value is 500ms). If I didn’t happen to be sitting in front of my computer, notice the dialog, and answer within that time, the wrong thing happened. Second, if this new person and I never happened to be online at the same time, authorization would never complete.

To solve these problems, we reused SIP Events itself – using the winfo template-event package to subscribe to changes in the set of watchers for any other package, like presence. The initial NOTIFY for a winfo subscription will describe each of the existing subscriptions detailing who the subscriber is, how long the subscription has been in place, when it will expire (if it isn’t refreshed), and what the current authorization state for the subscription is. (Remember that subscriptions can enter a “pending” state if a server doesn’t have authorization when the SUBSCRIBE arrives). To solve the never-online-at-the-same-time problem, winfo carries one more state, named “waiting”, for subscriptions which were attempted recently but for which authorization was not available.

Here’s a short example of winfo in action. Assume at the beginning of this flow that I’ve authorized Ben and Adam to see my presence, but not Theo. Note that in this flow, Theo and I are never online at the same time.

The winfo NOTIFY body format is XML. The initial NOTIFY for a winfo subscription will have a complete list of current watchers. Subsequent NOTIFYs will only contain information for those watchers whose subscription has changed state.

For more details on the format of the winfo NOTIFY bodies, see RFC 3858. The winfo template-package itself is in RFC 3857.