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]