[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                      Jon Peterson
Internet Draft                            Level(3) Communications
draft-jfp-sip-isup-header-00.txt                       Lyndon Ong
Feb 2001                                     Point Reyes Networks
Expires: Aug 2001

           Mapping of ISUP parameters to SIP headers in SIP-T

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This document defines procedures within SIP-T for translation of ISUP
   call context to SIP call context and vice versa to allow ISUP calls
   to pass through SIP networks while preserving feature transparency.

1. Introduction

   SIP-T (or SIP for Telephones, described in [C&A]) is a system for
   seamlessly interworking SIP [2543] and ISUP [Q.76x] networks. SIP- T
   is not an extension to SIP, but is rather an application of existing
   SIP mechanisms to the problem of providing ISUP feature transparency.
   These mechanisms are typically implemented at an SS7-SIP gateway (or
   'gateway' for short) which serves as a point of conversion between
   SS7 and SIP networks, and generally also is responsible for the
   conversion of circuit-switched media into VoIP packet-switched media.
   Gateways should be interpreted broadly to encompass media gateway
   controller and softswitch architectures.

Peterson/Ong                                                    [Page 1]

Internet-Draft                SIP-T Header                      Feb 2001

   In order to allow ISUP calls to pass through SIP networks without any
   loss of call context, SIP-T employs both encapsulation of ISUP within
   SIP and translation of ISUP call context into SIP call context. This
   draft focuses on translation; other drafts (see [MIME]) examine the
   encapsulation mechanism of SIP-T. The purpose of translation is
   twofold: for ISUP calls that traverse a SIP network, translation
   allows SIP elements such as proxy servers to make routing decisions
   based on ISUP criteria such as the called party number; translation
   also provides critical information about the call to SIP endpoints
   that cannot understand encapsulated ISUP (or perhaps which merely
   cannot understand the particular ISUP variant in use).

   This draft 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-to-header mapping in SIP- T is confined more or
   less to the IAM and the INVITE. Note that this document does not
   explore the mapping from ISDN cause codes [Q.850] to SIP status codes
   as these are characterized elsewhere [SIP-ISUP].

   Many national ISUP variants have been widely implemented in the PSTN.
   This document attempts to document variations in ISUP signaling where

2. Construction of Telephony URIs

   SIP proxy servers may route SIP messages on any signaling criteria
   desired by network administrators, but generally the Request-URI is
   the foremost routing criterion. The To and From headers are also
   frequently of interest in making routing decisions. SIP-T assumes
   that proxy servers are interested in at least these three fields of
   SIP messages, all of which contain URIs.

   SIP-T frequently requires the representation of telephone numbers in
   these URIs. In some instances these numbers will be presented first
   in ISUP messages, and SS7-SIP gateways will need to translate the
   ISUP formats of these numbers into SIP URIs. In other cases the
   reverse transformation will be required.

   The most common format used in SIP for the representation of
   telephone numbers is the tel URL, defined in [2806]. The tel URL may
   constitute the entirety of a URI field in a SIP message, or it may
   appear as the user portion of a SIP URI. For example, a To field

Peterson/Ong                                                    [Page 2]

Internet-Draft                SIP-T Header                      Feb 2001

   might appear as:

     To: tel:+17208881000


     To: sip:+17208881000@level3.com

   Whether or not a particular gateway or endpoint should formulate URIs
   in the tel or SIP format is a matter of local administrative policy -
   if the presence of a host portion would aid the surrounding network
   in routing calls, the SIP format should be used. A gateway should
   accept either tel or SIP URIs from its peers.

   The '+' sign preceding the number in these examples indicates that
   the digits which follow constitute a fully-qualified E.164 [E.164]
   number; essentially, this means that a country code is provided
   before any national-specific area codes, exchange/city codes, or
   address codes. The absence of a '+' sign could mean that the number
   is nationally significant, or perhaps that a private dialing plan is
   in use. When the '+' sign is not present, but a telephone number is
   represented by the user portion of the URI, the tel URL should
   contain the optional ';user=phone' parameter; e.g.

     To: tel:83000;user=phone

   However, it is highly recommended that only internationally
   significant E.164 numbers be passed between SIP-T gateways,
   especially when such gateways are in different regions or different
   administrative domains. In many if not most SIP-T networks, gateways
   are not responsible for end-to-end routing of SIP calls; practically
   speaking, gateways have no way of knowing if the call will terminate
   in a local or remote administrative domain and/or region, and hence
   gateways should always assume that calls require an international
   numbering plan. There is no guarantee that recipients of SIP
   signaling will be capable of understanding national dialing plans
   used by the originators of calls - if the originating gateway does
   not internationalize the signaling, the context in which the digits
   were dialed cannot be extrapolated by far-end network elements.

   In ISUP signaling, a telephone number appears in a common format that
   is used in several parameters, including the Called Party's Number
   (CPN) and Calling Party's Number (CIN); when it represents a calling
   party number it sports some additional information (detailed below).
   For the purposes of this document, we will refer to this format as
   'ISUP format' - if the additional calling party information is
   present, the format shall be referred to as 'ISUP- calling format'.
   The format consists of a byte called the Nature of Address (NoA)

Peterson/Ong                                                    [Page 3]

Internet-Draft                SIP-T Header                      Feb 2001

   indicator, followed by another byte which contains the Numbering Plan
   Indicator (NPI), both of which are prefixed to a variable-length
   series of bytes that contains the digits of the telephone number in
   binary coded decimal (BCD) format. In the calling party number case,
   the NPI's byte also contains bit fields which represent the caller's
   presentation preferences and the status of any call screening checks
   performed up until this point in the call.

     H G F E D C B A       H G F E D C B A
    +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
    | |    NoA      |     | |    NoA      |
    +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
    | | NPI | spare |     | | NPI |PrI|ScI|
    +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
    | dig...| dig 1 |     | dig...| dig 1 |
    |      ...      |     |      ...      |
    | dig n | dig...|     | dig n | dig...|
    +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+

      ISUP format        ISUP calling format

        Figure 1. ISUP numbering formats

   The NPI field is generally set to the value 'ISDN (Telephony)
   numbering plan (Recommendation E.164)', but this does not mean that
   the digits which follow necessarily contain a country code; the NoA
   field dictates whether the telephone number is in a national or
   international format. When the represented number is not designated
   to be in an international format, the NoA generally provides
   information specific to the national dialing plan - based on this
   information one can usually determine how to convert the number in
   question into an international format. Note that if the NPI contains
   a value other than 'ISDN numbering plan', then the tel URL may not be
   suitable for carrying the address digits, and the handling for such
   calls is outside the scope of this document.

   Based on the above, conversion from ISUP format to a tel URL is as
   follows. First, provided that the NPI field indicates that the
   telephone number format uses E.164, the NoA should be consulted.  If
   the NoA indicates that the number is an international number, then
   the telephone number digits should be appended unmodified to a
   'tel:+' string. If the NoA has the value 'national (significant)
   number', then a country code must be prefixed to the telephone number
   digits before they are committed to a tel URL; if the gateway
   performing this conversion interconnects with switches homed to
   several different country codes, presumably the appropriate country
   code should be chosen based on the originating switch. If the NoA has

Peterson/Ong                                                    [Page 4]

Internet-Draft                SIP-T Header                      Feb 2001

   the value 'subscriber number', both a country code and any other
   numbering components necessary for the numbering plan in question
   (such as area codes or city codes) may need to be added in order for
   the number to be internationally significant - however, such
   procedures vary greatly from country to country, and hence they
   cannot be specified in detail here. Only if a country or network-
   specific value is used for the NoA should a tel URL not include a '+'
   sign; in these cases, gateways should simply copy the provided digits
   into the tel URL and append a 'user=phone' parameter. Any non-
   standard or proprietary mechanisms used to communicate further
   context for the call in ISUP are outside the scope this document.

   If ISUP calling format is used rather than ISUP format, then two
   additional pieces of information must be taken into account:
   presentation indicators and screening indicators. If the presentation
   indicators are set to 'presentation restricted', then a special URI
   should be created by the gateway which communicates to the far end
   that the caller's identity has been elided. This URI should be a SIP
   URI with the hostname of the gateway but with a username of
   'restricted', e.g.:

     From: sip:restricted@gw.level3.net

   If presentation is set to 'address unavailable', then gateways should
   treat the IAM as if the CIN parameter was omitted.  Screening
   indicators should not be translated, as they are only meaningful end-

   Conversion from tel URLs to ISUP format is simpler. If the URI is in
   international format, then the gateway should consult the leading
   country code of the URI. If the country code is local to the gateway
   (the gateway has one or more trunks that point to switches which are
   homed to the country code in question), the gateway should set the
   NoA to reflect 'national (significant) number' and strip the country
   code from the URI before populating the digits field. If the country
   code is not local to the gateway, the gateway should set the NoA to
   'international number' and retain the country code. In either case
   the NPI should be set to 'ISDN numbering plan'.

   If the URI is not in international format, the gateway should attempt
   to treat the telephone number within the URI as if it were
   appropriate to its national or network-specific dialing plan; if
   doing so gives rise to internal gateway errors, then this condition
   is most likely best handled with appropriate SIP status codes (e.g.

   When converting from a tel URL to ISUP calling format, the procedure
   is identical to that described in the preceding paragraphs, but

Peterson/Ong                                                    [Page 5]

Internet-Draft                SIP-T Header                      Feb 2001

   additionally, the presentation indicator should be set to
   'presentation allowed' and the screening indicator to 'network

   Gateways may also wish to make use of encapsulated ISUP in certain
   cases to assist in the translation from a tel URL. For example, use
   of encapsulated ISUP could allow the recovering of original
   presentation and screening indicators present in a CIN parameter.

3. Procedures

3.1 PSTN-to-SIP

   When an IAM arrives at a PSTN-SIP gateway, a SIP INVITE message will
   be created for transmission to the SIP network. This section details
   the process by which a gateway populates the INVITE based on
   parameters found within the IAM.

   Five mandatory parameters appear within the IAM message: the Called
   Party Number (CPN), the Nature of Connection Indicator (NCI), the
   Forward Call Indicators (FCI), the Calling Party's Category (CPC),
   and finally a parameter that indicates the desired bearer
   characteristics of the call - in some ISUP variants the Transmission
   Medium Requirement (TMR) is required, in others the User Service
   Information (USI) (or both).

   There are quite a few optional parameters that can appear in an IAM
   message; Q.763 lists 29 in all. However, each of these parameters
   need not to be translated in order to achieve the goals of SIP-T. As
   is stated above, translation allows SIP network elements to
   understand the PSTN context of the session if they are not capable of
   deciphering any encapsulated ISUP. Parameters that are only
   meaningful to the PSTN will be carried through PSTN-SIP- PSTN
   networks via encapsulation - translation is not necessary for these
   parameters. Of the aforementioned 29 parameters, only the following
   are immediately useful for SIP-T translation: the Calling Party's
   Number (CIN, which is commonly present), Transit Network Selection
   (TNS),  Carrier Identification Parameter (CIP, in ANSI networks
   only), Original Called Number (OCN), and the Generic Number or
   Generic Address Parameter, depending on one's variant (for the
   purposes of this document, this parameter will be abbreviated as

   The session context information discovered by the gateway in the IAM
   will be stored primarily in two URIs in the INVITE, one representing
   the originator of the session and the other the destination. The
   former will always appear in the From header, and the latter is
   almost always used for both the To header and the Request-URI.

Peterson/Ong                                                    [Page 6]

Internet-Draft                SIP-T Header                      Feb 2001

   The construction of destination URI begins with determining which
   ISUP parameter currently contains the called party number.  Usually,
   this will be the CPN parameter. However, if the destination number
   has been ported (see [QSUP-3]) and a dip to the relevant LNP database
   has already been performed, then the called party number may very
   well appear in the GAP. If the ISUP variant in question uses separate
   parameters for the Routing Number and original dialed number after a
   Local Number Portability (LNP) dip, then the 'number translated' bit
   of the FCI parameter should be consulted to determine whether the
   called party number is in the CPN parameter or the GAP parameter.
   Note that some ISUP variants concatenate the Routing Number with the
   dialed number in the CPN parameter; support for these variants will
   be specified in later iterations of this document.

   Once the location of the called party number has been determined, it
   should be translated into a tel URL through the mechanism described
   above. Some additional fields may need to be added to the tel URL
   after translation has been completed, namely:

     o If the FCI 'number translated' bit indicated that an LNP dip had
     been performed, an 'npdi=yes' field must be appended to the tel
     URL. If a GAP is present in the IAM, then the contents of the CPN
     should be translated from ISUP format (as described above) and
     copied into an 'rn=' field which must be appended to the tel URL.
     Note that Location Routing Numbers (LRNs) stored in CPN for calls
     to ported numbers are necessarily national in scope, and
     consequently they will not be preceded by a '+' in the 'rn='
     field. For further information on these tel URL fields see [tel-LNP].

     o If either the CIP or TNS is present, the carrier identification
     code (CIC) should be extracted from the parameter and analyzed by
     the gateway. If doing so is in keeping with local policy (i.e.
     provided that the CIC does not indicate the network which owns the
     gateway or some similar condition), a 'cic=' field with the value
     of the CIC should be appended to the tel URL. Note that the CIC
     should be prefixed with the country code used or implied in the
     called party number, so that CIC '5062' becomes, in the United
     States, '+1-5062'. For further information on the 'cic=' tel URL
     field see [tel-LNP].

   In most cases, the resulting URI should be used in the To field and
   Request-URI sent by the gateway. However, if the OCN parameter is
   present in the IAM, the To field is constructed from the translation
   of the OCN parameter, and hence the Request-URI and To field will be

   The construction of the From field is dependent on the presence of a
   CIN parameter. If the CIN is not present, then the gateway should

Peterson/Ong                                                    [Page 7]

Internet-Draft                SIP-T Header                      Feb 2001

   create a dummy From header containing a SIP URI without a user
   portion which communicates only the hostname of the gateway (e.g.
   'sip:gw.level3.net'). If the CIN is available, then it should be
   translated (in accordance with the procedure described above) into a
   tel URL which should populate the From field.

3.2 SIP-to-PSTN

   When a SIP INVITE arrives at a PSTN gateway, the gateway should
   attempt to make use of any encapsulated ISUP to assist in the
   formulation of outbound PSTN signaling. However, three conditions can
   complicate this process:

     o There is no ISUP encapsulated in the SIP INVITE - the SIP INVITE
     originated at a device other than an ISUP-SIP gateway.

     o There is encapsulated ISUP, but the gateway cannot understand
     the ISUP variant and therefore the ISUP must be discarded.

     o There is encapsulated ISUP, but there is more recent session
     context information available in the SIP headers, and consequently
     the SIP headers must 'overwrite' the encapsulated ISUP. (Specifically,
     when the Request-URI of a call has changed due to a redirection or
     similar condition, and the CPN parameter for further ISUP signaling must
     be modified accordingly).

   In all of these cases translation must be performed. Gateways should
   use default values for mandatory ISUP parameters that are not derived
   from translation or encapsulation (such as the NCI or TMR
   parameters). The FCI parameter should also have a default, although
   its 'number translated' bit may be overwritten during the process of
   translation as LNP procedures for the ISUP variant dictate.

   First, the Request-URI should be inspected.

   If there is no 'npdi=yes' field within the Request-URI, then the main
   telephone number in the tel URL (the digits immediately following
   'tel:') should be converted to ISUP format, following the procedure
   described above, and used to populate the CPN parameter.

   If the 'npdi=yes' field exists in the Request-URI, then the FCI
   parameter bit for 'number translated' within the IAM should reflect
   that a number portability dip has been performed (if applicable for
   the ISUP variant in question).

   If in addition to the 'ndpi=yes' field there is no 'rn=' field
   present, then the main telephone number in the tel URL should be
   converted to ISUP format and used to populate the CPN parameter.

Peterson/Ong                                                    [Page 8]

Internet-Draft                SIP-T Header                      Feb 2001

   If in addition to the 'npdi=yes' field an 'rn=' field is present,
   then the 'rn=' field should be converted to ISUP format and used to
   populate the CPN. The main telephone number in the tel URL should be
   converted to ISUP format and used to populate the GAP (again, if
   supported by the SUP variant - in some variants, the contents of the
   'rn=' field should be appended to the CPN).

   If main telephone number in the Request-URI and that of the To header
   are at variance, then the To header should be used to populate an OCN
   parameter. Otherwise the To header should be ignored.

   If the 'cic=' parameter is present in the Request-URI, the gateway
   should consult local policy to make sure that it is appropriate to
   transmit this Carrier Identification Code in the IAM. If the gateway
   supports many independent trunks, it may need to choose a particular
   trunk that points to the carrier identified by the CIC, or a tandem
   through which that carrier is reachable.

   If the ISUP variant in question supports only the TNS parameter, and
   not the CIP, then obviously the TNS should always be used to relay
   the Carrier Identification Code. If however the CIP is supported,
   then policies for outbound trunks (based on the preferences of the
   carriers with which the trunks are associated) may dictate whether
   the CIP or TNS parameter should be used. In the absence of any pre-
   arranged policies, the TNS always should be used when the CPN
   parameter is in an international format (i.e. the NoA field of the
   CPN indicates that this is an international number), and the CIP
   should be used in all other cases.

   If a SIP call has arrived at a gateway, then the Request-URI will
   most likely contain a tel URL (or a SIP URI with a tel URL user
   portion). However, if the call originated at a native IP endpoint
   such as a SIP phone, the From field may not reflect any telephone
   number - it may be a simple user@host construction. The CIN parameter
   should be omitted from the outbound IAM if the From field is

4. Security Issues

   As is described above, it is critical that SS7-SIP gateways honor the
   presentation indicators provided in ISUP in order to prevent any
   compromise of user privacy.

   Since native SIP elements (such as SIP phones) can populate their
   From fields arbitrarily, there is some potential for abuse if PSTN
   gateways naively accept the contents of the From field and dutifully
   populate the CIN parameter of IAMs accordingly. Thus, either the
   gateway itself or some trusted prior element in the network (such as

Peterson/Ong                                                    [Page 9]

Internet-Draft                SIP-T Header                      Feb 2001

   a proxy server that manages the gateways) should cryptographically
   authenticate signaling from native SIP elements and match the given
   From field against a database of acceptable values for that user.

5. Further Work

   Translation of CPC to From field

   Support for ISUP variants which concatenate RN and DN for LNP

6. Authors

   Jon Peterson                      Lyndon Ong
   Level(3) Communications           Point Reyes Networks
   Louisville, CO, USA               San Jose, CA, USA
   jon.peterson@level3.com           lyndon_ong@yahoo.com

7. References

   [2543] Handley, Schulzrinne, Schooler and Rosenberg, "Session
   Initiation Protocol (SIP)" RFC 2543, Internet Engineering Task Force,
   March 1999.

   [2806] Vaha-Sipila, "URLs for Telephone Calls", RFC 2806, Internet
   Engineering Task Force, April 2000

   [C&A] Vemuri, Peterson, "SIP-T: Context and Architectures", Internet-
   Draft, Internet Engineering Task Force, Nov 2000, work in progress.

   [Q.76x] ITU-T Recommendations Q.761, Q.762, Q.763, Q.764,
   "Specification of signaling system no. 7 - ISDN user part", 9/97

   [E.164] ITU-T Recommendation E.164, "The international public
   telecommunication numbering plan", 5/97

   [MIME] Zimmerer, Vemuri, Peterson, Ong, Zonoun, Watson, "MIME media
   types for ISUP and QSIG objects", Internet-Draft, Internet
   Engineering Task Force, Nov 2000, work in progress.

   [Q.850] ITU-T Recommendation Q.850, "Usage of cause and location in
   the Digital Subscriber Signalling System No . 1 and the Signalling
   System No.  7 ISDN User Part", 5/98

   [QSUP-3] ITU-T Q. Series Recommendations Supplement 3, "Number
   portability - scope and capability set 1 architecture", 5/98

   [SIP-ISUP] Roach, Camarillo, "ISUP to SIP mapping", Internet-Draft,
   Internet Engineering Task Force, Nov 2000, work in progress.

Peterson/Ong                                                   [Page 10]

Internet-Draft                SIP-T Header                      Feb 2001

   [tel-LNP], Yu, "Extensions to the 'tel' and 'fax' URLs to Support
   Number Portability and Freephone service", Internet-Draft, Internet
   Engineering Task Force, Feb 2001

   Full Copyright Statement

   Copyright (c) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Peterson/Ong                                                   [Page 11]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/