Implementing CMMSS

An embryonic form of CMM/SS was first attempted in accessing the IN services from H.323 endpoints [CHI00]; we subsequently groomed the technique and formalized it through its application to accessing services from SIP endpoints as well [GUR02, GUR03d]. The results of that effort are discussed in this section.

Recall from Chapter 2 that services in the PSTN are provided by the IN. A PSTN switch, while processing a phone call, may temporarily suspend processing and consult the Service Control Point (SCP) on how to handle a particular call. The SCP executes the service and passes the results back to the switch in the form of instructions on the continuation of call processing. Thus, there is a close coupling between a switch and the SCP (or any other entity in the core providing value-added services) and all but the most basic of services are provided by the entities in the core of the network. In the Internet, by contrast, endpoints are themselves capable of executing complex services without the need for a centralized service platform. Thus, a preliminary step for implementing CMM/SS is to reconcile these two divergent views because the request for service will be placed by a SIP endpoint (and not a telephone endpoint connected to a traditional switch), while the service itself will be executed by traditional telephony equipment in the network core.

From the vantage point of the IN elements like the SCP, the fact that the request originated from a SIP entity versus a call processing function on a traditional switch is immaterial (assuming, of course, that the SCP does have access to the Internet, which all of them do because an SCP is nothing but a Sun Microsystems computer tuned to the telephony domain). It is also important that the SIP entity be able to provide features normally provided by the traditional switch, including interfacing with the IN network to access services. It should also maintain call state and trigger queries to the IN-based services, just as traditional switches do. Clearly, doing this in a SIP endpoint itself is not feasible because every SIP endpoint in existence would have to be upgraded to understand the IN call model and its interactions with the PSTN/IN for service signaling. Instead, a SIP intermediary, such as a proxy server or a Back-to-Back UA (B2BUA), may act as the functional equivalent of a traditional switch while processing a call from a SIP endpoint that requires access to the IN services. Generally speaking, proxy servers can be used for the IN services that occur during a call setup and teardown. For the IN services requiring specialized media handling (such as dual tone multifrequency (DTMF) detection) or specialized call control (such as placing parties on hold), B2BUAs will be required.

The most expeditious manner for providing existing IN services in IP is to use the deployed IN infrastructure as much as possible. The logical point in SIP to tap into for accessing existing IN services is an intermediary located physically closest to the SIP endpoint issuing the request (for originating IN services) or terminating the request (for terminating IN services). However, SIP intermediaries do not run an IN call model; to access the IN services transparently, the trick is to overlay the state machine of the SIP entity with an IN layer such that call acceptance and routing is performed by the native SIP state machine and services are accessed through the IN layer using an IN call model. Such an IN-enabled SIP intermediary, operating in synchrony with the events occurring at the SIP transaction level and interacting with the IN elements, is depicted in Figure 5.5.

The SIP intermediary of Figure 5.5, which we will refer to as a CMM/SS entity in the rest of the chapter, accepts a session setup request and processes it initially using the normal SIP state machines. However, at certain pivot states, a service-state handoff occurs to the IN layer, which performs further processing by interfacing with the PSTN/IN layer. The list of pivot states for SIP and its mapping into PSTN/IN Q.1204 BCSM will be detailed in Section 5.4.4.

0 0

Post a comment