tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3398


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

Part 3 of 3, p. 48 to 68
Prev RFC Part


prevText      Top      Up      ToC       Page 48 
9. Suspend/Resume and Hold

9.1 Suspend (SUS) and Resume (RES) Messages

   In ISDN networks, a user can generate a SUS (timer T2, user
   initiated) in order to unplug the terminal from the socket and plug
   it in another one.  A RES is sent once the terminal has been
   reconnected and the T2 timer has not expired.  SUS is also frequently
   used to signaling an on-hook state for a remote terminal before
   timers leading to the transmission of a REL message are sent (this is
   the more common case by far).  While a call is suspended, no audio
   media is passed end-to-end.

   When a SUS is sent for a call that has a SIP leg, a gateway MAY
   suspend IP media transmission until a RES is received.  Putting the
   media on hold insures that bandwidth is conserved when no audio
   traffic needs to be transmitted.

   If media suspension is appropriate, then when a SUS arrives from the
   PSTN, the MGC MAY send an INVITE to request that the far-end's
   transmission of the media stream be placed on hold.  The subsequent
   reception of a RES from the PSTN SHOULD then trigger a re-INVITE that
   requests the resumption of the media stream.  Note that the MGC may
   or may not elect to stop transmitting any media itself when it
   requests the cessation of far-end transmission.

Top      Up      ToC       Page 49 
   If media suspension is not required by the MGC receiving the SUS from
   the PSTN, the SIP INFO [6] method MAY be used to transmit an
   encapsulated SUS rather than a re-INVITE.  Note that the recipient of
   such an INFO request may be a simple SIP phone that does not
   understand ISUP (and would therefore take no action on receipt of
   this message); if a prospective destination for an INFO-encapsulated
   SUS has not used encapsulated ISUP in any messages it has previously
   sent, the gateway SHOULD NOT relay the INFO method, but rather should
   handle the SUS and the corresponding RES without signaling their
   arrival to the SIP network.

   In any case, subsequent RES messages MUST be transmitted in the same
   method that was used for the corresponding SUS (i.e., if an INFO is
   used for a SUS, INFO should also be used for the subsequent RES).

   Regardless of whether the INFO or re-INVITE mechanism is used to
   carry a SUS message, neither has any implication that the originating
   side will cease sending IP media.  The recipient of an encapsulated
   SUS message MAY therefore elect to send a re-INVITE themselves to
   suspend media transmission from the MGC side if desired.

   The following example uses the INVITE mechanism. Note that this flow
   is informative, not proscriptive; compliant gateways are free to
   implement functionally equivalent flows, as described in the
   preceding paragraphs.

        SIP                       MGC/MG                       PSTN
          |                          |<-----------SUS-----------|1
         2|<--------INVITE-----------|                          |
         3|-----------200----------->|                          |
         4|<----------ACK------------|                          |
          |                          |<-----------RES-----------|5
         6|<--------INVITE-----------|                          |
         7|-----------200----------->|                          |
         8|<----------ACK------------|                          |

   The handling of a network-initiated SUS immediately prior to call
   teardown is handled in Section 10.2.2.

Top      Up      ToC       Page 50 
9.2 Hold (re-INVITE)

   After a call has been connected, a re-INVITE could be sent to a
   gateway from the SIP side in order to place the call on hold.  This
   re-INVITE will have an SDP offer indicating that the originator of
   the re-INVITE no longer wishes to receive media.

        SIP                       MGC/MG                       PSTN
         1|---------INVITE---------->|                          |
          |                          |------------CPG---------->|2
         3|<----------200------------|                          |
         4|-----------ACK----------->|                          |

   When such a re-INVITE is received, the gateway SHOULD send a CPG in
   order to express that the call has been placed on hold.  The CPG
   SHOULD contain a Generic Notification Indicator (or, in ANSI
   networks, a Notification Indicator) with a value of 'remote hold'.

   If, subsequent to the sending of the re-INVITE, the SIP side wishes
   to take the remote end off hold and begin receiving media again, it
   SHOULD repeat the flow above with an INVITE that contains an SDP
   offer with an appropriate media destination.  The Generic
   Notification Indicator would in this instance have a value of 'remote
   retrieval' (or in some variants 'remote hold released').

   Finally, note that a CPG with hold indicators may be received by a
   gateway from the PSTN.  In the interests of conserving bandwidth, the
   gateway SHOULD stop sending media until the call is resumed and
   SHOULD send a re-INVITE to the SIP leg of the call requesting that
   the remote side stop sending media.

10. Normal Release of the Connection

   From the perspective of a gateway, either the SIP side or the ISUP
   side can release a call, regardless of which side initiated the call.
   Note that cancellation of a call setup request (either from the ISUP
   or SIP side) is discussed elsewhere in this document (in Section
   8.2.7 and Section 7.2.3, respectively).

   Gateways SHOULD implement functional equivalence with the flows in
   this section.

10.1 SIP initiated release

   For a normal termination of the dialog (receipt of a BYE request),
   the gateway MUST immediately send a 200 response.  The gateway then
   MUST release any media resources in the gateway (DSPs, TCIC locks,
   and so on) and send an REL with a cause code of 16 (normal call

Top      Up      ToC       Page 51 
   clearing) to the PSTN.  Release of resources is confirmed by the PSTN
   side with an RLC message.

   In SIP bridging situations, the cause code of any REL encapsulated in
   the BYE request SHOULD be re-used in any REL that the gateway sends
   to the PSTN.

        SIP                       MGC/MG                       PSTN
         1|-----------BYE----------->|                          |
          |            ** MG Releases IP Resources **           |
         2|<----------200------------|                          |
          |             ** MG Releases PSTN Trunk **            |
          |                          |------------REL---------->|3
          |                          |<-----------RLC-----------|4

10.2 ISUP initiated release

   If the release of the connection was caused by the reception of a
   REL, the REL SHOULD be encapsulated in the BYE sent by the gateway.
   Whether the caller or callee hangs up first, the gateway SHOULD
   release any internal resources used in support of the call and then
   MUST confirm that the circuit is ready for re-use by sending an RLC.

10.2.1 Caller hangs up

   When the caller hangs up, the SIP dialog MUST be terminated by
   sending a BYE request (which is confirmed with a 200).

        SIP                       MGC/MG                       PSTN
          |                          |<-----------REL-----------|1
          |             ** MG Releases PSTN Trunk **            |
          |                          |------------RLC---------->|2
         3|<----------BYE------------|                          |
          |            ** MG Releases IP Resources **           |
         4|-----------200----------->|                          |

Top      Up      ToC       Page 52 
10.2.2 Callee hangs up (SUS)

   In some PSTN scenarios, if the callee hangs up in the middle of a
   call, the local exchange sends a SUS instead of a REL and starts a
   timer (T6, SUS is network initiated).  When the timer expires, the
   REL is sent.  This necessitates a slightly different SIP flow; see
   Section 9 for more information on handling suspension.  It is
   RECOMMENDED that gateways implement functional equivalence with the
   following flow for this case:

        SIP                       MGC/MG                       PSTN
          |                          |<-----------SUS-----------|1
         2|<--------INVITE-----------|                          |
         3|-----------200----------->|                          |
         4|<----------ACK------------|                          |
          |                          |    *** T6 Expires ***    |
          |                          |<-----------REL-----------|5
          |             ** MG Releases PSTN Trunk **            |
          |                          |------------RLC---------->|6
         7|<----------BYE------------|                          |
          |            ** MG Releases IP Resources **           |
         8|-----------200----------->|                          |

11. ISUP Maintenance Messages

   ISUP contains a set of messages used for maintenance purposes.  They
   can be received during any ongoing call.  There are basically two
   kinds of maintenance messages (apart from the continuity check):
   messages for blocking circuits and messages for resetting circuits.

11.1 Reset messages

   Upon reception of an RSC message for a circuit currently being used
   by the gateway for a call, the call MUST be released immediately
   (this typically results from a serious maintenance condition).  RSC
   MUST be answered with an RLC after resetting the circuit in the
   gateway.  Group reset (GRS) messages which target a range of circuits
   are answered with a Circuit Group Reset ACK Message (GRA) after
   resetting all the circuits affected by the message.

   The gateways SHOULD behave as if a REL had been received in order to
   release the dialog on the SIP side.  A BYE or a CANCEL are sent
   depending of the status of the call.  See the procedures in Section

Top      Up      ToC       Page 53 
11.2 Blocking messages

   There are two kinds of blocking messages: maintenance messages or
   hardware-failure messages.  Maintenance blocking messages indicate
   that the circuit is to be blocked for any subsequent calls, but these
   messages do not affect any ongoing call.  This allows circuits to be
   gradually quiesced and taken out of service for maintenance.

   Hardware-oriented blocking messages have to be treated as reset
   messages.  They generally are sent only when a hardware failure has
   occurred.  Media transmission for all calls in progress on these
   circuits would be affected by this hardware condition, and therefore
   all calls must be released immediately.

   BLO is always maintenance oriented and it is answered by the gateway
   with a Blocking ACK Message (BLA) when the circuit is blocked - this
   requires no corresponding SIP actions.  Circuit Group Blocking (CGB)
   messages have a "type indicator" inside the Circuit Group Supervision
   Message Type Indicator.  It indicates if the CGB is maintenance or
   hardware failure oriented.  If the CGB results from a hardware
   failure, then each call in progress in the affected range of circuits
   MUST be terminated immediately as if a REL had been received,
   following the procedures in Section 10.  CGBs MUST be answered with

11.3  Continuity Checks

   A continuity check is a test performed on a circuit that involves the
   reflection of a tone generated at the originating switch by a
   loopback at the destination switch.  Two variants of the continuity
   check appear in ISUP: the implicit continuity check request within an
   IAM (in which case the continuity check takes place as a precondition
   before call setup begins), and the explicit continuity check signaled
   by a Continuity Check Request (CCR) message.  PSTN gateways in
   regions that support continuity checking generally SHOULD have some
   way of accommodating these tests (if they hope to be fielded by
   providers that interconnect with any major carrier).

   When a CCR is received by a PSTN-SIP gateway, the gateway SHOULD NOT
   send any corresponding SIP messages; the scope of the continuity
   check applies only to the PSTN trunks, not to any IP media paths
   beyond the gateway.  CCR messages also do not designate any called
   party number, or any other way to determine what SIP user agent
   server should be reached.

   When an IAM with the Continuity Check Indicator flag set within the
   NCI parameter is received, the gateway MUST process the continuity
   check before sending an INVITE message (and proceeding normally with

Top      Up      ToC       Page 54 
   call setup); if the continuity check fails (a COT with Continuity
   Indicator of 'failed' is received), then an INVITE MUST NOT be sent.

12. 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-ISUP mapping
   assumes that proxy servers are interested in at least these three
   fields of SIP messages, all of which contain URIs.

   SIP-ISUP mapping 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 [7].  When converting between
   formats, 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 might appear as:

   To: tel:+17208881000



   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 MUST
   accept either tel or SIP URIs from its peers.

   The '+' sign preceding the number in tel URLs indicates that the
   digits which follow constitute a fully-qualified E.164 [16] 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 MAY signify that the number is merely
   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 SIP URI SHOULD
   contain the optional ';user=phone' parameter; e.g.,


Top      Up      ToC       Page 55 
   However, it is strongly 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 CPN and 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) 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

              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

Top      Up      ToC       Page 56 
   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.

12.1 ISUP format to tel URL mapping

   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 is 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 or trunk group.  If
   the NoA has 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 if a SIP URI
   format is used.  Any non-standard or proprietary mechanisms used to
   communicate further context for the call in ISUP are outside the
   scope of this document.

   If a nationally-specific parameter is present that allows for the
   transmission of the calling party's name (such as the Generic Name
   Parameter in ANSI), then generally, if presentation is not
   restricted, this information SHOULD be used to populate the display-
   name portion of the From field.

Top      Up      ToC       Page 57 
   If ISUP calling format is being converted 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 is created by the gateway which communicates to the far
   end that the caller's identity has been omitted.  This URI SHOULD be
   a SIP URI with a display-name and username of 'Anonymous', e.g.:

   From: Anonymous <sip:anonymous@anonymous.invalid>

   For further information about privacy in SIP, see Section 5.7.

   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

12.2 tel URL to ISUP format mapping

   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 MUST be set to 'ISDN numbering plan'.

   If the URI is not in international format, the gateway MAY 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 or the gateway does not support such
   procedures, then the gateway SHOULD respond with appropriate SIP
   status codes to express that the URI could not be understood (if the
   URI in question is the Request-URI, a 484).

   When converting from a tel URL to ISUP calling format, the procedure
   is identical to that described in the preceding paragraphs, but
   additionally, the presentation indicator SHOULD be set to
   'presentation allowed' and the screening indicator to 'network
   provided', unless some service provider policy or user profile
   specifically disallows presentation.

Top      Up      ToC       Page 58 
13. Other ISUP flavors

   Other flavors of ISUP different than ITU-T ISUP have different
   parameters and more features.  Some of the parameters have more
   possible values and provide more information about the status of the

   The Circuit Query Message (CQM) and Circuit Query Response (CQR) are
   used in many ISUP variants.  These messages have no analog in SIP,
   although receipt of a CQR may cause state reconciliation if the
   originating and destination switches have become desynchronized; as
   states are reconciled some calls may be terminated, which may cause
   SIP or ISUP messages to be sent (as described in Section 10).

   However, differences in the message flows are more important.  In
   ANSI [11] ISUP, the CON message MUST NOT be sent; an ANM is sent
   instead (when no ACM has been sent before the call is answered).  In
   call forwarding situations, CPGs MAY be sent before the ACM is sent.
   SAMs MUST NOT be sent; 'en-bloc' signaling is always used.  The ANSI
   Exit Message (EXM) SHOULD NOT result in any SIP signaling in
   gateways.  ANSI also uses the Circuit Reservation Message (CRM) and
   Circuit Reservation Acknowledgment (CRA) as part of its interworking
   procedures - in the event that an MGC does receive a CRM, a CRA
   SHOULD be sent in return (in some implementations, transmissions of a
   CRA could conceivably be based on a resource reservation system);
   after a CRA is sent, the MGC SHOULD wait for a subsequent IAM and
   process it normally.  Any further circuit reservation mechanism is
   outside the scope of this document.

   Although receipt of a Confusion (CFN) message is an indication of a
   protocol error, corresponding SIP messages SHOULD NOT be sent on
   receipt of a CFN - the CFN should be handled with ISUP-specific
   procedures by the gateway (usually by retransmission of the packet to
   which the CFN responded).  Only if ISUP procedures fails repeatedly
   should this cause a SIP error condition (and call failure) to arise.

   In TTC ISUP CPGs MAY be sent before the ACM is sent.  Messages such
   as a Charging Information Message (CHG) MAY be sent between ACM and
   ANM.  'En-bloc' signaling is always used and there is no T9 timer.

13.1 Guidelines for sending other ISUP messages

   Some ISUP variants send more messages than the ones described in this
   document.  Therefore, some guidelines are provided here with regard
   to transport and mapping of these ISUP message.

Top      Up      ToC       Page 59 
   From the caller to the callee, other ISUP messages SHOULD be
   encapsulated (see [3]) inside INFO messages, even if the INVITE
   transaction is still not finished.  Note that SIP does not ensure
   that INFO requests are delivered in order, and therefore in adverse
   network conditions an egress gateway might process INFOs out of
   order.  This issue, however, does not represent an important problem
   since it is not likely to happen and its effects are negligible in
   most of the situations.  The Information (INF) message and
   Information Response (INR) are examples of messages that should be
   encapsulated within an INFO.  Gateway implementers might also
   consider building systems that wait for each INFO transaction to
   complete before initiating a new INFO transaction.

   From the callee to the caller, if a message is received by a gateway
   before the call has been answered (i.e., ANM is received) it SHOULD
   be encapsulated in an INFO, provided that this will not be the first
   SIP message sent in the backwards direction (in which case it SHOULD
   be encapsulated in a provisional 1xx response).  Similarly a message
   which is received on the originating side (probably in response to an
   INR) before a 200 OK has been received by the gateway should be
   carried within an INFO.  In order for this mechanism to function
   properly in the forward direction, any necessary Contact or To-tag
   must have appeared in a previous provisional response or the message
   might not be correctly routed to its destination.  As such all SIP-T
   gateways MUST send all provisional responses with a Contact header
   and any necessary tags in order to enable proper routing of new
   requests issued before a final response has been received.  When the
   INVITE transaction is finished INFO requests SHOULD also be used in
   this direction.

Top      Up      ToC       Page 60 
14. Acronyms

   ACK                Acknowledgment
   ACM                Address Complete Message
   ANM                Answer Message
   ANSI               American National Standards Institute
   BLA                Blocking ACK message
   BLO                Blocking Message
   CGB                Circuit Group Blocking Message
   CGBA               Circuit Group Blocking ACK Message
   CHG                Charging Information Message
   CON                Connect Message
   CPG                Call Progress Message
   CUG                Closed User Group
   GRA                Circuit Group Reset ACK Message
   GRS                Circuit Group Reset Message
   HLR                Home Location Register
   IAM                Initial Address Message
   IETF               Internet Engineering Task Force
   IP                 Internet Protocol
   ISDN               Integrated Services Digital Network
   ISUP               ISDN User Part
   ITU-T              International Telecommunication Union
                      Telecommunication Standardization Sector
   MG                 Media Gateway
   MGC                Media Gateway Controller
   MTP                Message Transfer Part
   REL                Release Message
   RES                Resume Message
   RLC                Release Complete Message
   RTP                Real-time Transport Protocol
   SCCP               Signaling Connection Control Part
   SG                 Signaling Gateway
   SIP                Session Initiation Protocol
   SS7                Signaling System No. 7
   SUS                Suspend Message
   TTC                Telecommunication Technology Committee
   UAC                User Agent Client
   UAS                User Agent Server
   UDP                User Datagram Protocol
   VoIP               Voice over IP

15. Security Considerations

   The translation of ISUP parameters into SIP headers may introduce
   some privacy and security concerns above and beyond those that have
   been identified for other functions of SIP-T [9A].  Merely securing
   encapsulated ISUP, for example, would not provide adequate privacy

Top      Up      ToC       Page 61 
   for a user requesting presentation restriction if the Calling Party
   Number parameter is openly mapped to the From header.  Section 12.2
   shows how SIP Privacy [9B] should be used for this function.  Since
   the scope of SIP-ISUP mapping has been restricted to only those
   parameters that will be translated into the headers and fields used
   to route SIP requests, gateways consequently reveal through
   translation the minimum possible amount of information.

   A security analysis of ISUP is beyond the scope of this document.
   ISUP bridging across SIP is discussed more fully in [9A], but Section discusses processing the translated ISUP values in relation
   to any embedded ISUP in a request arriving at PSTN gateway.  Lack of
   ISUP security analysis may pose some risks if embedded ISUP is
   blindly interpreted.  Accordingly, gateways SHOULD NOT blindly trust
   embedded ISUP unless the request was strongly authenticated [9A], and
   the sender is trusted, e.g., is another MGC that is authorized to use
   ISUP over SIP in bridge mode.  When requests are received from
   arbitrary end points, gateways SHOULD filter any received ISUP.  In
   particular, only known-safe commands and parameters should be
   accepted or passed through.  Filtering by deleting believed-to-be
   dangerous entries does not work well.

   In most respects, the information that is translated from ISUP to SIP
   has no special security requirements.  In order for translated
   parameters to be used to route requests, they should be legible to
   intermediaries; end-to-end confidentiality of this data would be
   unnecessary and most likely detrimental.  There are also numerous
   circumstances under which intermediaries can legitimately overwrite
   the values that have been provided by translation, and hence
   integrity over these headers is similarly not desirable.

   There are some concerns however that arise from the other direction
   of mapping, the mapping of SIP headers to ISUP parameters, which are
   enumerated in the following paragraphs.  When end users dial numbers
   in the PSTN today, their selections populate the telephone number
   portion of the Called Party Number parameter, as well as the digit
   portions of the Carrier Identification Code and Transit Network
   Selection parameters of an ISUP IAM.  Similarly, the tel URL and its
   optional parameters in the Request-URI of a SIP, which can be created
   directly by end users of a SIP device, map to those parameters at a
   gateway.  However, in the PSTN, policy can prevent the user from
   dialing certain (invalid or restricted) numbers, or selecting certain
   carrier identification codes.  Thus, gateway operators MAY wish to
   use corresponding policies to restrict the use of certain tel URLs,
   or tel URL parameters, when authorizing a call.

Top      Up      ToC       Page 62 
   The fields relevant to number portability, which include in ANSI ISUP
   the LRN portion of the Generic Address Parameter and the 'M' bit of
   the Forward Call Indicators, are used to route calls in the PSTN.
   Since these fields are rendered as tel URL parameters in the SIP-ISUP
   mapping, users can set the value of these fields arbitrarily.
   Consequently, an end-user could change the end office to which a call
   would be routed (though if LRN value were chosen at random, it is
   more likely that it would prevent the call from being delivered
   altogether).  The PSTN is relatively resilient to calls that have
   been misrouted on account of local number portability, however.  In
   some networks, a REL message with some sort of "misrouted ported
   number" cause code is sent in the backwards direction when such a
   condition arises.  Alternatively, the PSTN switch to which a call was
   misrouted can forward the call along to the proper switch after
   making its own number portability query - this is an interim number
   portability practice that is still common in most segments of the
   PSTN that support portability.  It is not anticipated that end users
   will typically set these SIP fields, and the risks associated with
   allowing an adventurous or malicious user to set the LRN do not seem
   to be grave, but they should be noted by network operators.  The
   limited degree to which SIP signaling contributes to the interworking
   indicators of the Forward Call Indicators and Backward Call Indicator
   parameters incurs no foreseeable risks.

   Some additional risks may result from the SIP response code to ISUP
   Cause Code parameter mapping.  SIP user agents could conceivably
   respond to an INVITE from a gateway with any arbitrary SIP response
   code, and thus they can dictate (within the boundaries of the
   mappings supported by the gateway) the Q.850 cause code that will be
   sent by the gateway in the resulting REL message.  Generally
   speaking, the manner in which a call is rejected is unlikely to
   provide any avenue for fraud or denial of service - to the best
   knowledge of the authors there is no cause code identified in this
   document that would signal that some call should not be billed, or
   that the network should take critical resources off-line.  However,
   operators may want to scrutinize the set of cause codes that could be
   mapped from SIP response codes (listed in to make sure that
   no undesirable network-specific behavior could result from operating
   a gateway supporting the recommended mappings.  In some cases,
   operators MAY wish to implement gateway policies that use alternative
   mappings, perhaps selectively based on authorization data.

   If the Request-URI and the To header field of a request received at a
   gateway differ, Section recommends that the To header (if it
   is a telephone number) should map to the Original Called Number
   parameter, and the Request-URI to the Called Party Number parameter.
   However, the user can, at the outset of a request, select a To header
   field value that differs from the Request-URI; these two field values

Top      Up      ToC       Page 63 
   are not required to be the same.  This essentially allows a user to
   set the ISUP Original Called Number parameter arbitrarily.  Any
   applications that rely on the Original Called Number for settlement
   purposes could be affected by this mapping recommendation.  It is
   anticipated that future SIP work in this space will arrive at a
   better general account of the re-targeting of SIP requests that may
   be applicable to the OCN mapping.

   The arbitrary population of the From header of requests by SIP user
   agents has some well-understood security implications for devices
   that rely on the From header as an accurate representation of the
   identity of the originator.  Any gateway that intends to use the From
   header to populate the called party's number parameter of an ISUP IAM
   message should authenticate the originator of the request and make
   sure that they are authorized to assert that calling number (or make
   use of some more secure method to ascertain the identity of the
   caller).  Note that gateways, like all other SIP user agents, MUST
   support Digest authentication as described in [1].

   There is another class of potential risk that is related to the cut-
   through of the backwards media path before the call is answered.
   Several practices described in this document recommend that a gateway
   signal an ACM when a called user agent returns a 18x provisional
   response code.  At that time, backwards media will be cut through
   end-to-end in the ISUP network, and it is possible for the called
   user agent then to play arbitrary audio to the caller for an
   indefinite period of time before transmitting a final response (in
   the form of a 2xx or higher response code).  There are conceivable
   respects in which this capability could be used illegitimately by the
   called user agent.  It is also however a useful feature to allow
   progress tones and announcements to be played in the backwards
   direction in the 'ACM sent' state (so that the caller won't be billed
   for calls that don't actually complete but for which failure
   conditions must be rendered to the user as in-band audio).  In fact,
   ISUP commonly uses this backwards cut-through capability in order to
   pass tones and announcements relating to the status of a call when an
   ISUP network interworks with legacy networks that are not capable of
   expressing Q.850 cause codes.

   It is the contention of the authors that SIP introduces no risks with
   regard to backwards media that do not exist in Q.931-ISUP mapping,
   but gateways implementers MAY develop an optional mechanism (possibly
   something that could be configured by an operator) that would cut off
   such 'early media' on a brief timer - it is unlikely that more than
   20 or 30 seconds of early media is necessary to convey status
   information about the call (see Section 7.2.6).  A more conservative
   approach would be to never cut through backwards media in the gateway
   until a 2xx final response has been received, provided that the

Top      Up      ToC       Page 64 
   gateway implements some way of prevent clipping of the initial media
   associated with the call.

   Unlike a traditional PSTN phone, a SIP user agent can launch multiple
   simultaneous requests in order to reach a particular resource.  It
   would be trivial for a SIP user agent to launch 100 SIP requests at a
   100 port gateway, thereby tying up all of its ports.  A malicious
   user could choose to launch requests to telephone numbers that are
   known never to answer, which would saturate these resources
   indefinitely and potentially without incurring any charges.  Gateways
   therefore MAY support policies that restrict the number of
   simultaneous requests originating from the same authenticated source,
   or similar mechanisms to address this possible denial-of-service

16. IANA Considerations

   This document introduces no new considerations for IANA.

17. Acknowledgments

   This document existed as an Internet-Draft for four years, and it
   received innumerable contributions from members of the various
   Transport Area IETF working groups that it called home (which
   included the MMUSIC, SIP and SIPPING WGs).  In particular, the
   authors would like to thank Olli Hynonen, Tomas Mecklin, Bill
   Kavadas, Jonathan Rosenberg, Henning Schulzrinne, Takuya Sawada,
   Miguel A. Garcia, Igor Slepchin, Douglas C. Sicker, Sam Hoffpauir,
   Jean-Francois Mule, Christer Holmberg, Doug Hurtig, Tahir Gun, Jan
   Van Geel, Romel Khan, Mike Hammer, Mike Pierce, Roland Jesske, Moter
   Du, John Elwell, Steve Bellovin, Mark Watson, Denis Alexeitsev, Lars
   Tovander, Al Varney and William T.  Marshall for their help and
   feedback on this document.  The authors would also like to thank
   ITU-T SG11 for their advice on ISUP procedures.

18. Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", BCP 14, RFC 2119, March 1997.

   [3]  Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
        Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
        objects", RFC 3204, December 2001.

Top      Up      ToC       Page 65 
   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November

   [5]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
        Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [6]  Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [7]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April

   [8]  Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.

   [9]  Schulzrinne, H., Camarillo, G. and D. Oran, "The Reason Header
        Field for the Session Initiation Protocol", RFC 3326, December

   [9A] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
        Telephones (SIP-T): Context and Architectures", BCP 63, RFC
        3372, September 2002.

   [9B] Peterson, J., "A Privacy Mechanism for the Session Initiation
        Protocol (SIP)", RFC 3323, November 2002.

19. Non-Normative References

   [10] International Telecommunications Union, "Application of the ISDN
        user part of CCITT Signaling System No. 7 for international ISDN
        interconnection", ITU-T Q.767, February 1991,

   [11] American National Standards Institute, "Signaling System No. 7;
        ISDN User Part", ANSI T1.113, January 1995,

   [12] International Telecommunications Union, "Signaling System No. 7;
        ISDN User Part Signaling procedures", ITU-T Q.764, December
        1999, <>.

   [13] International Telecommunications Union, "Abnormal conditions -
        Special release", ITU-T Q.118, September 1997,

   [14] International Telecommunications Union, "Specifications of
        Signaling System No. 7 - ISDN supplementary services", ITU-T
        Q.737, June 1997, <>.

Top      Up      ToC       Page 66 
   [15] International Telecommunications Union, "Usage of cause location
        in the Digital Subscriber Signaling System No. 1 and the
        Signaling System No. 7 ISDN User Part", ITU-T Q.850, May 1998,

   [16] International Telecommunications Union, "The international
        public telecommunications numbering plan", ITU-T E.164, May
        1997, <>.

   [17] International Telecommunications Union, "Formats and codes of
        the ISDN User Part of Signaling System No. 7", ITU-T Q.763,
        December 1999, <>.

   [18] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
        Responses in SIP", RFC 3262, June 2002.

   [19] Stewart, R., "Stream Control Transmission Protocol", RFC 2960,
        October 2000.

   [20] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
        Method", RFC 3311, October 2002.

   [21] Yu, J., "Extensions to the 'tel' and 'fax' URL in support of
        Number Portability and Freephone Service", Work in Progress.

Top      Up      ToC       Page 67 
Authors' Addresses

   Gonzalo Camarillo
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas

   Phone: +358 9 299 3371

   Adam Roach
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520

   Phone: +1 925/363-8720

   Lyndon Ong
   10480 Ridgeview Court
   Cupertino, CA  95014


Top      Up      ToC       Page 68 
Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.