Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping

Voir toute la rfc dans une seule page

Télécharger le PDF

RFC 3398                  ISUP to SIP Mapping              December 2002


   be confused with the MTP3 'circuit 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.
   Policies for such trunks (based on the preferences of the carriers
   with which the trunks are associated and the ISUP variant in use)
   SHOULD dictate whether the CIP or TNS parameter is used to carry the
   CIC.  In the absence of any pre-arranged policies, the TNS should be
   used when the CPN parameter is in an international format (i.e., the
   tel URL portion of the Request-URI is preceded by a '+', which will
   generate a CPN in international format), and (where supported) the
   CIP should be used in other cases.

   When a SIP call has been routed to a gateway, then the Request-URI
   will most likely contain a tel URL (or a SIP URI with a tel URL user
   portion) - SIP-ISUP gateways that receive Request-URIs that do not
   contain valid telephone numbers SHOULD reject such requests with an
   appropriate response code.  Gateways SHOULD however continue to
   process requests with a From header field that does not contain a
   telephone number, as will sometimes be the case if a call originated
   at a SIP phone that employs a SIP URI user@host convention.  The CIN
   parameter SHOULD be omitted from the outbound IAM if the From field
   is unusable.  Note that as an alternative, gateway implementers MAY
   consider some non-standard way of mapping particular SIP URIs to
   telephone numbers.

   When a gateway receives a message with (comprehensible) encapsulated
   ISUP, it MUST set the FCI indicator in the generated IAM so that all
   interworking-related bits have the same values as their counterparts
   in the encapsulated ISUP.  In most cases, these indicators will state
   that no interworking was encountered, unless interworking has been
   encountered somewhere else in the call path.  If usable encapsulated
   ISUP is not present in an INVITE received by the gateway, it is
   STRONGLY RECOMMENDED that the gateway set the Interworking Indicator
   bit of the FCI to 'no interworking' and the ISDN User Part Indicator
   to 'ISUP used all the way'; the gateway MAY also set the Originating
   Access indicator to 'Originating access non-ISDN' (generally, it is
   not safe to assume that SIP phones will support ISDN endpoint
   services, and the procedures in this document do not detail mappings
   to translate all such services).

   Note that when 'interworking encountered' is set in the FCI parameter
   of the IAM, this indicates that ISUP is interworking with a network
   which is not capable of providing as many services as ISUP does.
   ISUP networks will therefore not employ certain features they
   otherwise normally would, including potentially the use of ISDN cause
   codes in failure conditions (as opposed to sending ACMs followed by
   audible announcements).  If desired, gateway vendors MAY provide a



Camarillo, et. al.          Standards Track                    [Page 22]