IETF - RFC 3398
Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
|Publication Date:||1 November 2002|
This document focuses on the translation of ISUP messages into SIP messages, and the mapping of ISUP parameters into SIP headers. For ISUP calls that traverse a SIP network, the purpose of translation is to allow SIP elements such as proxy servers (which do not typically understand ISUP) to make routing decisions based on ISUP criteria such as the called party number. This document consequently provides a SIP mapping only for those ISUP parameters which might be used by intermediaries in the routing of SIP requests. As a side effect of this approach, translation also increases the overall interoperability by providing critical information about the call to SIP endpoints that cannot understand encapsulated ISUP, or perhaps which merely cannot understand the particular ISUP variant encapsulated in a message.
This document also only takes into account the call functionality of ISUP. Maintenance messages dealing with PSTN trunks are treated only as far as they affect the control of an ongoing call; otherwise these messages neither have nor require any analog in SIP.
Messages indicating error or congestion situations in the PSTN (MTP- 3) and the recovery mechanisms used such as User Part Available and User Part Test ISUP messages are outside the scope of this document
There are several flavors of ISUP. International Telecommunication Union Telecommunication Standardization Sector (ITU-T) International ISUP  is used through this document; some differences with the American National Standards Institute (ANSI)  ISUP and the Telecommunication Technology Committee (TTC) ISUP are also outlined. ITU-T ISUP is used in this document because it is the most widely known of all the ISUP flavors. Due to the small number of fields that map directly from ISUP to SIP, the signaling differences between ITU-T ISUP and specific national variants of ISUP will generally have little to no impact on the mapping. Note, however, that the ITU-T has not substantially standardized practices for Local Number Portability (LNP) since portability tends to be grounded in national numbering plan practices, and that consequently LNP must be described on a virtually per-nation basis. The number portability practices described in this document are presented as an optional mechanism.
Mapping of SIP headers to ISUP parameters in this document focuses largely on the mapping between the parameters found in the ISUP Initial Address Message (IAM) and the headers associated with the SIP INVITE message; both of these messages are used in their respective protocols to request the establishment of a call. Once an INVITE has been sent for a particular session, such headers as the To and From field become essentially fixed, and no further translation will be required during subsequent signaling, which is routed in accordance with Via and Route headers. Hence, the problem of parameter-toheader mapping in SIP-T is confined more or less to the IAM and the INVITE. Some additional detail is given in the population of parameters in the ISUP messages Address Complete Message (ACM) and Release Message (REL) based on SIP status codes.
This document describes when the media path associated with a SIP call is to be initialized, terminated, modified, etc., but it does not go into details such as how the initialization is performed or which protocols are used for that purpose.