Interface between SIP servers and INAP/SCP

Service control points (SCPs) provide advanced telephony services in the PSTN Intelligent Network. Examples of such services include load-balancing call routing, 800-number services and interaction with the caller, such as digit collection for calling card verification or IVR systems. Service switching points (SSPs) communicate with SCPs via a transaction-oriented protocol called INAP. SCP services are requested at various points during call setup, so-called trigger points. The points in time where trigger points are reached is defined by the Basic Call Model (BCM) [citation]. Preliminary work on a logical mapping between SIP protocol states and the BCM have already begun [citation].

                                [   SCP  ]
                                       |
                                  INAP
                                       |
          |------------|
-- SIP -->| SIP entity |...SIP...>
          |------------|

When interworking between VoIP networks and IN, it is useful to have a common understanding of how to translate from the states produced by VoIP signaling to those familiar with IN service creation. 

We use the term SIP entities to refer to SIP proxy servers and SIP UAs. This interface is appropriate only for SIP entities that maintain call state. (Even so-called "stateful" proxy servers generally only have to maintain SIP transaction state.)

In this model, each SIP server is pre-configured to communicate with one logical SCP server, using whatever communication mechanism is appropriate. (In particular, the mechanism may not use an IP network.). Different SIP servers, e.g., in different administrative domains, may communicate with different SCP servers, so that there is no single SCP server responsible for all SIP servers. Even within a single call, the outbound and other SIP servers may well use different SCPs, particularly if they are located within different administrative domains.

Not every SIP server needs to have this interface. Instead, SIP server may proxy requests to servers that are capable of conversing with an SCP.

This model can be viewed as a specialized cousin of the CPL and sip-cgi interfaces already being defined. Similar to sip-cgi, it is anticipated that this interface will be specified as an informational RFC.


Notes:

1) This proposal is applicable only when SIP-controlled Internet telephony devices are to interoperate with PSTN devices. The SIP proxy servers using this interface would typically appear together with a media gateway. It is *not* applicable within an all-IP network and is not needed where only PSTN gateways need to communicate with SCPs.

2) This proposal is not a wire protocol, but rather an abstract interface mechanism that simplifies the construction of SIP servers that want to access IN services. (On initial inspection, it does not seem appropriate to repackage SIP requests and responses.)

3) Since SIP proxy and redirect servers do not have access to the media data path, special mechanisms need to be deployed to enable IN services such as digit collection or announcement services. Announcement services can use the mechanism in draft-ietf-sip-183 to deliver messages or can proxy the call to a SIP UAS that also terminates the data stream. That UAS may then transfer the call (draft-sparks-sip-cc-transfer) to the final destination.