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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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 applicable. 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 Or 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- to-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. 484). 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 provided'. 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 GAP). 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 different. 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 unusable. 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 English. 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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Peterson/Ong [Page 11]