9.  Number Mapping

   In QSIG, users are identified by numbers, as defined in [1].  Numbers
   are conveyed within the Called party number, Calling party number,
   and Connected number information elements.  The Calling party number
   and Connected number information elements also contain a presentation
   indicator, which can indicate that privacy is required (presentation
   restricted), and a screening indicator, which indicates the source
   and authentication status of the number.

   In SIP, users are identified by Universal Resource Identifiers (URIs)
   conveyed within the Request-URI and various headers, including the
   From and To headers specified in [10] and optionally the P-Asserted-
   Identity header specified in [14].  In addition, privacy is indicated
   by the Privacy header specified in [13].

   This clause specifies the mapping between QSIG Called party number,
   Calling party number, and Connected number information elements and
   corresponding elements in SIP.

   A gateway MAY implement the P-Asserted-Identity header in accordance
   with [14].  If a gateway implements the P-Asserted-Identity header,
   it SHALL also implement the Privacy header in accordance with [13].
   If a gateway does not implement the P-Asserted-Identity header, it
   MAY implement the Privacy header.

9.1.  Mapping from QSIG to SIP

   The method used to convert a number to a URI is outside the scope of
   this specification.  However, the gateway SHOULD take account of the
   Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG
   information element concerned when interpreting a number.

   Some aspects of mapping depend on whether the gateway is in the same
   trust domain (as defined in [14]) as the next hop SIP node (i.e., the
   proxy or UA to which the INVITE request is sent or from which INVITE
   request is received) to honour requests for identity privacy in the
   Privacy header.  This will be network-dependent, and it is
   RECOMMENDED that gateways supporting the P-Asserted-Identity header
   hold a configurable list of next hop nodes that are to be trusted in
   this respect.

9.1.1.  Using Information from the QSIG Called Party Number Information
        Element

   When mapping a QSIG SETUP message to a SIP INVITE request, the
   gateway SHALL convert the number in the QSIG Called party number
   information to a URI and include that URI in the SIP Request-URI and
   in the To header.

9.1.2.  Using Information from the QSIG Calling Party Number Information
        Element

   When mapping a QSIG SETUP message to a SIP INVITE request, the
   gateway SHALL use the Calling party number information element, if
   present, as follows.

   If the information element contains a number, the gateway SHALL
   attempt to derive a URI from that number.  Further behaviour depends
   on whether a URI has been derived and the value of the presentation
   indication.

9.1.2.1.  No URI derived, and presentation indicator does not have value
          "presentation restricted"

   In this case (including the case where the Calling party number
   information element is absent), the gateway SHALL include a URI
   identifying the gateway in the From header.  Also, if the gateway
   supports the mechanism defined in [14], the gateway SHALL NOT
   generate a P-Asserted-Identity header.

9.1.2.2.  No URI derived, and presentation indicator has value
          "presentation restricted"

   In this case, the gateway SHALL generate an anonymous From header.
   Also, if the gateway supports the mechanism defined in [14], the
   gateway SHALL generate a Privacy header field with parameter
   priv-value = "id" and SHALL NOT generate a P-Asserted-Identity
   header.  The inclusion of additional values of the priv-value
   parameter in the Privacy header is outside the scope of this
   specification.

9.1.2.3.  URI derived, and presentation indicator has value
          "presentation restricted"

   If the gateway supports the P-Asserted-Identity header and trusts the
   next hop proxy to honour the Privacy header, the gateway SHALL
   generate a P-Asserted-Identity header containing the derived URI,
   SHALL generate a Privacy header with parameter priv-value = "id", and
   SHALL generate an anonymous From header.  The inclusion of additional
   values of the priv-value parameter in the Privacy header is outside
   the scope of this specification.

   If the gateway does not support the P-Asserted-Identity header or
   does not trust the proxy to honour the Privacy header, the gateway
   SHALL behave as in Section 9.1.2.2.

9.1.2.4.  URI derived, and presentation indicator does not have value
          "presentation restricted"

   In this case, the gateway SHALL generate a P-Asserted-Identity header
   containing the derived URI if the gateway supports this header, SHALL
   NOT generate a Privacy header, and SHALL include the derived URI in
   the From header.  In addition, the gateway MAY use S/MIME, as
   described in Section 23 of [10], to sign a copy of the From header
   included in a message/sipfrag body of the INVITE request as described
   in [20].

9.1.3.  Using Information from the QSIG Connected Number Information
        Element

   When mapping a QSIG CONNECT message to a SIP 200 (OK) response to an
   INVITE request, the gateway SHALL use the Connected number
   information element, if present, as follows.

   If the information element contains a number, the gateway SHALL
   attempt to derive a URI from that number.  Further behaviour depends
   on whether a URI has been derived and the value of the presentation
   indication.

9.1.3.1.  No URI derived, and presentation indicator does not have value
          "presentation restricted"

   In this case (including the case where the Connected number
   information element is absent), the gateway SHALL NOT generate a
   P-Asserted-Identity header and SHALL NOT generate a Privacy header.

9.1.3.2.  No URI derived, and presentation indicator has value
          "presentation restricted"

   In this case, if the gateway supports the mechanism defined in [14],
   the gateway SHALL generate a Privacy header field with parameter
   priv-value = "id" and SHALL NOT generate a P-Asserted-Identity
   header.  The inclusion of additional values of the priv-value
   parameter in the Privacy header is outside the scope of this
   specification.

9.1.3.3.  URI derived, and presentation indicator has value
          "presentation restricted"

   If the gateway supports the P-Asserted-Identity header and trusts the
   next hop proxy to honour the Privacy header, the gateway SHALL
   generate a P-Asserted-Identity header containing the derived URI and
   SHALL generate a Privacy header with parameter priv-value = "id".
   The inclusion of additional values of the priv-value parameter in the
   Privacy header is outside the scope of this specification.

   If the gateway does not support the P-Asserted-Identity header or
   does not trust the proxy to honour the Privacy header, the gateway
   SHALL behave as in Section 9.1.3.2.

9.1.3.4.  URI derived, and presentation indicator does not have value
          "presentation restricted"

   In this case, the gateway SHALL generate a P-Asserted-Identity header
   containing the derived URI if the gateway supports this header and
   SHALL NOT generate a Privacy header.  In addition, the gateway MAY
   use S/MIME, as described in Section 23 of [10], to sign a To header
   containing the derived URI, the To header being included in a
   message/sipfrag body of the INVITE response as described in [20].

   NOTE: The To header in the message/sipfrag body may differ from the
   to header in the response's headers.

9.2.  Mapping from SIP to QSIG

   The method used to convert a URI to a number is outside the scope of
   this specification.  However, NPI and TON fields in the QSIG
   information element concerned SHALL be set to appropriate values in
   accordance with [1].

   Some aspects of mapping depend on whether the gateway trusts the next
   hop SIP node (i.e., the proxy or UA to which the INVITE request is
   sent or from which INVITE request is received) to provide accurate
   information in the P-Asserted-Identity header.  This will be
   network-dependent, and it is RECOMMENDED that gateways hold a
   configurable list of next hop nodes that are to be trusted in this
   respect.

   Some aspects of mapping depend on whether the gateway is prepared to
   use a URI in the From header to derive a number for the Calling party
   number information element.  The default behaviour SHOULD be not to
   use an unsigned or unvalidated From header for this purpose, since in
   principle the information comes from an untrusted source (the remote
   UA).  However, it is recognised that some network administrations may
   believe that the benefits to be derived from supplying a calling
   party number outweigh any risks of supplying false information.
   Therefore, a gateway MAY be configurable to use an unsigned or
   unvalidated From header for this purpose.

9.2.1.  Generating the QSIG Called Party Number Information Element

   When mapping a SIP INVITE request to a QSIG SETUP message, the
   gateway SHALL convert the URI in the SIP Request-URI to a number and
   include that number in the QSIG Called party number information
   element.

   NOTE: The To header should not be used for this purpose.  This is
   because re-targeting of the request in the SIP network can change the
   Request-URI but leave the To header unchanged.  It is important that
   routing in the QSIG network be based on the final target from the SIP
   network.

9.2.2.  Generating the QSIG Calling Party Number Information Element

   When mapping a SIP INVITE request to a QSIG SETUP message, the
   gateway SHALL generate a Calling party number information element as
   follows.

   If the SIP INVITE request contains an S/MIME signed message/sipfrag
   body [20] containing a From header, and if the gateway supports this
   capability and can verify the authenticity and trustworthiness of
   this information, the gateway SHALL attempt to derive a number from
   the URI in that header.  If no number is derived from a
   message/sipfrag body, if the SIP INVITE request contains a P-
   Asserted-Identity header, and if the gateway supports that header and
   trusts the information therein, the gateway SHALL attempt to derive a
   number from the URI in that header.  If a number is derived from one
   of these headers, the gateway SHALL include it in the Calling party
   number information element and include value "network provided" in
   the screening indicator.

   If no number is derivable as described above and if the gateway is
   prepared to use the unsigned or unvalidated From header, the gateway
   SHALL attempt to derive a number from the URI in the From header.  If
   a number is derived from the From header, the gateway SHALL include
   it in the Calling party number information element and include value
   "user provided, not screened" in the screening indicator.

   If no number is derivable, the gateway SHALL NOT include a number in
   the Calling party number information element.

   If the SIP INVITE request contains a Privacy header with value "id"
   in parameter priv-value and the gateway supports this header, or if
   the value in the From header indicates anonymous, the gateway SHALL
   include value "presentation restricted" in the presentation
   indicator.  Based on local policy, the gateway MAY use the presence
   of other priv-values to set the presentation indicator to
   "presentation restricted".  Otherwise the gateway SHALL include value
   "presentation allowed" if a number is present or "not available due
   to interworking" if no number is present.

   If the resulting Calling party number information element contains no
   number and contains value "not available due to interworking" in the
   presentation indicator, the gateway MAY omit the information element
   from the QSIG SETUP message.

9.2.3.  Generating the QSIG Connected Number Information Element

   When mapping a SIP 2xx response to an INVITE request to a QSIG
   CONNECT message, the gateway SHALL generate a Connected number
   information element as follows.

   If the SIP 2xx response contains an S/MIME signed message/sipfrag
   [20] body containing a To header and the gateway supports this
   capability and can verify the authenticity and trustworthiness of
   this information, the gateway SHALL attempt to derive a number from
   the URI in that header.  If no number is derived from a
   message/sipfrag body, if the SIP 2xx response contains a
   P-Asserted-Identity header, and if the gateway supports that header
   and trusts the information therein, the gateway SHALL attempt to
   derive a number from the URI in that header.  If a number is derived
   from one of these headers, the gateway SHALL include it in the
   Connected number information element and include value "network
   provided" in the screening indicator.

   If no number is derivable as described above, the gateway SHOULD NOT
   include a number in the Connected number information element.

   If the SIP 2xx response contains a Privacy header with value "id" in
   parameter priv-value and the gateway supports this header, the
   gateway SHALL include value "presentation restricted" in the
   presentation indicator.  Based on local policy, the gateway MAY use
   the presence of other priv-values to set the presentation indicator
   to "presentation restricted".  Otherwise, the gateway SHALL include
   value "presentation allowed" if a number is present or "not available
   due to interworking" if no number is present.

   If the resulting Connected number information element contains no
   number and value "not available due to interworking" in the
   presentation indicator, the gateway MAY omit the information element
   from the QSIG CONNECT message.

10.  Requirements for Support of Basic Services

   This document specifies signalling interworking for basic services
   that provide a bi-directional transfer capability for speech,
   facsimile, and modem media between the two networks.

10.1.  Derivation of QSIG Bearer Capability Information Element

   The gateway SHALL generate the Bearer Capability Information Element
   in the QSIG SETUP message based on SDP offer information received
   along with the SIP INVITE request.  If the SIP INVITE request does
   not contain SDP offer information or the media type in the SDP offer
   information is only 'audio', then the Bearer capability information
   element SHALL BE generated according to Table 3.  Coding of the
   Bearer capability information element for other media types is
   outside the scope of this specification.

   In addition, the gateway MAY include a Low layer compatibility
   information element and/or High layer compatibility information in
   the QSIG SETUP message if the gateway is able to derive relevant
   information from the SDP offer information.  Specific mappings are
   outside the scope of this specification.

      Table 3: Bearer capability encoding for 'audio' transfer

   Field                          Value
   -----------------------------------------------------------------
   Coding Standard                "CCITT standardized coding" (00)
   Information transfer           "3,1 kHz audio" (10000)
   capability
   Transfer mode                  "circuit mode" (00)
   Information transfer rate      "64 Kbits/s" (10000)
   Multiplier                     Octet omitted
   User information layer 1       Generated by gateway based on
   protocol                       Information of the PISN.  Supported
                                  values are
                                  "CCITT recommendation G.711 mu-law"
                                  (00010)
                                  "CCITT recommendation G.711 A-law"
                                  (00011)

10.2.  Derivation of Media Type in SDP

   The gateway SHALL generate SDP offer information to include in the
   SIP INVITE request based on information in the QSIG SETUP message.
   The gateway MAY take account of QSIG Low layer compatibility and/or
   High layer compatibility information elements, if present in the QSIG
   SETUP message, when deriving SDP offer information, in which case

   specific mappings are outside the scope of this specification.
   Otherwise, the gateway shall generate SDP offer information based
   only on the Bearer capability information element in the QSIG SETUP
   message, in which case the media type SHALL be derived according to
   Table 4.

      Table 4: Media type setting in SDP based on Bearer capability
      information element

   Information transfer capability in          Media type in SDP
   Bearer capability information element
   ---------------------------------------------------------------
   "speech" (00000)                            audio
   "3,1 kHz audio" (10000)                     audio

11.  Security Considerations

11.1.  General

   Normal considerations apply for UA use of SIP security measures,
   including digest authentication, TLS, and S/MIME as described in
   [10].

   The translation of QSIG information elements into SIP headers can
   introduce some privacy and security concerns.  For example, care
   needs to be taken to provide adequate privacy for a user requesting
   presentation restriction if the Calling party number information
   element is openly mapped to the From header.  Procedures for dealing
   with this particular situation are specified in Section 9.1.2.
   However, since the mapping specified in this document is mainly
   concerned with translating information elements into the headers and
   fields used to route SIP requests, gateways consequently reveal
   (through this translation process) the minimum possible amount of
   information.

   There are some concerns, however, that arise from the other direction
   of mapping, the mapping of SIP headers to QSIG information elements,
   which are enumerated in the following paragraphs.

11.2.  Calls from QSIG to Invalid or Restricted Numbers

   When end users dial numbers in a PISN, their selections populate the
   Called party number information element in the QSIG SETUP message.
   Similarly, the SIP URI or tel URL and its optional parameters in the
   Request-URI of a SIP INVITE request, which can be created directly by
   end users of a SIP device, map to that information element at a
   gateway.  However, in a PISN, policy can prevent the user from
   dialing certain (invalid or restricted) numbers.  Thus, gateway

   implementers may wish to provide a means for gateway administrators
   to apply policies restricting the use of certain SIP URIs or tel
   URLs, or SIP URI or tel URL parameters, when authorizing a call from
   SIP to QSIG.

11.3.  Abuse of SIP Response Code

   Some additional risks may result from the mapping of SIP response
   codes to QSIG cause values.  SIP user agents could conceivably
   respond to an INVITE request 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 QSIG call clearing message.
   Generally speaking, the manner in which a call is rejected is
   unlikely to provide any avenue for fraud or denial of service (e.g.,
   by signalling that a call should not be billed, or that the network
   should take critical resources off-line).  However, gateway
   implementers may wish to make provision for gateway administrators to
   modify the response code to cause value mappings to avoid any
   undesirable network-specific behaviour resulting from the mappings
   recommended in Section 8.4.4.

11.4.  Use of the To Header URI

   This specification requires the gateway to map the Request-URI rather
   than the To header in a SIP INVITE request to the Called party number
   information element in a QSIG SETUP message.  Although a SIP UA is
   expected to put the same URI in the To header and in the Request-URI,
   this is not policed by other SIP entities.  Therefore, a To header
   URI that differs from the Request-URI received at the gateway cannot
   be used as a reliable indication that the call has been re-targeted
   in the SIP network or as a reliable indication of the original
   target. Gateway implementers making use of the To header for mapping
   to QSIG elements (e.g., as part of QSIG call diversion signalling)
   may wish to make provision for disabling this mapping when deployed
   in situations where the reliability of the QSIG elements concerned is
   important.

11.5.  Use of the From Header URI

   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 an
   unsigned or unverified From header to populate the Calling party
   number information element of a QSIG SETUP message should
   authenticate the originator of the request and make sure that it is
   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 [10].  Similar considerations apply to
   the use of the SIP P-Asserted-Identity header for mapping to the QSIG
   Calling party number or Connected number information element, i.e.,
   the source of this information should be authenticated.  Use of a
   signed message/sipfrag body to derive a QSIG Calling party number or
   Connected number information element is another secure alternative.

11.6.  Abuse of Early Media

   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 involve the connection
   of media streams to user information channels on inter-PINX links and
   the sending of progress description number 1 or 8 in a backward QSIG
   message.  This can result in media being cut through end-to-end, 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) to an
   INVITE request.  This is useful since it also permits network
   entities (particularly legacy networks that are incapable of
   transmitting Q.850 cause values) to play tones and announcements to
   indicate call failure or call progress, without triggering charging
   by transmitting a 2xx response.  Also, early cut-through can help
   prevent clipping of the initial media when the call is answered.
   There are conceivable respects in which this capability could be used
   fraudulently by the called user agent for transmitting arbitrary
   information without answering the call or before answering the call.
   However, in corporate networks, charging is often not an issue, and
   for calls arriving at a corporate network from a carrier network, the
   carrier network normally takes steps to prevent fraud.

   The usefulness of this capability appears to outweigh any risks
   involved, which may in practice be no greater than in existing
   PISN/ISDN environments.  However, gateway implementers may wish to
   make provision for gateway administrators to turn off cut-through or
   minimise its impact (e.g., by imposing a time limit) when deployed in
   situations where problems can arise.

11.7.  Protection from Denial-of-Service Attacks

   Unlike a traditional PISN 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 INVITE
   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, or, where overlap signalling is used,

   to incomplete addresses.  This could saturate resources at the
   gateway indefinitely, potentially without incurring any charges.
   Gateway implementers may therefore wish to provide means of
   restricting according to policy the number of simultaneous requests
   originating from the same authenticated source, or similar mechanisms
   to address this possible denial-of-service attack.

12.  Acknowledgements

   This document is a product of the authors' activities in Ecma
   (www.ecma-international.org) on interoperability of QSIG with IP
   networks.  An earlier version is published as Standard ECMA-339.
   Ecma has made this work available to the IETF as the basis for
   publishing an RFC.

   The authors wish to acknowledge the assistance of Francois Audet,
   Adam Roach, Jean-Francois Rey, Thomas Stach, and members of Ecma
   TC32-TG17 in preparing and commenting on this document.

13.  Normative References

   [1]  International Standard ISO/IEC 11571 "Private Integrated
        Services Networks (PISN) - Addressing" (also published by Ecma
        as Standard ECMA-155).

   [2]  International Standard ISO/IEC 11572 "Private Integrated
        Services Network - Circuit-mode Bearer Services - Inter-Exchange
        Signalling Procedures and Protocol" (also published by Ecma as
        Standard ECMA-143).

   [3]  International Standard ISO/IEC 11582 "Private Integrated
        Services Network - Generic Functional Protocol for the Support
        of Supplementary Services - Inter-Exchange Signalling Procedures
        and Protocol" (also published by Ecma as Standard ECMA-165).

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [6]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
        1980.

   [7]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

   [8]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [9]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
        "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [10] 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.

   [11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
        Responses in Session Initiation Protocol (SIP)", RFC 3262, June
        2002.

   [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

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

   [14] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
        to the Session Initiation Protocol (SIP) for Asserted Identity
        within Trusted Networks", RFC 3325, November 2002.

   [15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [16] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, December 1998.

   [17] ITU-T Recommendation E.164, "The International Public
        Telecommunication Numbering Plan", (1997-05).

   [18] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Mapping of
        Integrated Services Digital Network (ISDN) User Part (ISUP)
        Overlap Signalling to the Session Initiation Protocol (SIP)",
        RFC 3578, August 2003.

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

   [20] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
        November 2002.