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.