SIP-T 相关 RFC 重温

                                                       SIP for Telephones (SIP-T)

 

    SIP-T 是 IETF 制定的规范，由 RFC3372、RFC2976、RFC3204、RFC3398 等组成，用于阐
述 SIP 与 SS7 ISUP 的互通。
    SIP-T 定义了 SIP-ISUP Gateway 如何在 SIP 消息里面封装(Encapsulation, RFC 3204) ISUP 信

令，以便在 SIP 网络里面端到端传输 ISUP 信令。同时 SIP-T 也阐述了 SIP-ISUP Gateway 如何将

ISUP 信令映射(Translation, RFC 3398)成 SIP 请求，以及需要将 ISUP 信令里面的一些重要信息翻

译成 SIP headers，以便 SIP Proxy 等纯 SIP 设备可以路由这些呼叫。

    对于 mid-call 状态下的 ISUP 信令，SIP-T 使用 RFC 2976 定义的 SIP INFO 方法去封装传输这

些信息。

    下表是 RFC 3372 列举的 ISUP-SIP 互通的要求，以及 SIP-T 规范对应的解决方式

   SS7-SIP Interworking Requirements     SIP-T Functions
   ==================================================================
   Transparency of ISUP                  Encapsulation of ISUP in the
   Signaling                             SIP body

   Routability of SIP messages with      Translation of ISUP information
   dependencies on ISUP                  into the SIP header

   Transfer of mid-call ISUP signaling   Use of the INFO Method for mid-
   messages                              call signaling

   Table 1: SIP-T features that fulfill PSTN-IP inter-connection
            Requirements


   Originator requirements: encapsulate ISUP, translate information from
   ISUP to SIP, multipart MIME support (for gateways only)

   Terminator requirements: standard SIP processing, interpretation of
   encapsulated ISUP (for gateways only), support for multipart MIME,
   graceful handling of unknown MIME content (for non-gateways only)

   Proxy requirements: ability to route based on choice of routable
   elements


4.4 Behavioral Requirements Summary

   If the SIP-T originator is a gateway that received an ISUP request,
   it must always perform both encapsulation and translation ISUP,
   regardless of where the originator might guess that the request will
   terminate.

   If the terminator does not understand ISUP, it ignores it while
   performing standard SIP processing.  If the terminator does
   understand ISUP, and needs to signal to the PSTN, it should reuse the
   encapsulated ISUP if it understands the variant.  The terminator
   should perform the following steps:

   o  Extract the ISUP from the message body, and use this ISUP as a
      message template.  Note that if there is no encapsulated ISUP in
      the message, the gateway should use a canonical template for the
      message type in question (a pre-populated ISUP message configured
      in the gateway) instead.

   o  Translate the headers of the SIP request into ISUP parameters,
      overwriting any values in the message template.

   o  Apply any local policies in populating parameters.

   An intermediary must be able to route a call based on the choice of
   routable elements in the SIP headers.

    SIP-T 只界定基本呼叫，没有涉及补充业务。
    另外 RFC 3398 对于 ISUP 信令非呼叫控制部分的一些说明

   This document also only takes into account the call functionality of
   ISUP.  Maintenance messages dealing with PSTN trunks are treated only
   as far as they affect the control of an ongoing call; otherwise these
   messages neither have nor require any analog in SIP.

   Messages indicating error or congestion situations in the PSTN (MTP-
   3) and the recovery mechanisms used such as User Part Available and
   User Part Test ISUP messages are outside the scope of this document

 

    RFC 3398 对 SIP Stack 的一点要求

SIP Mechanisms Required

1. 'Transparent' Transit of ISUP Messages

    To allow gateways to take advantage of the full range of services
    afforded by the existing telephone network when placing calls from
    PSTN to PSTN across a SIP network, SIP messages MUST be capable of
    transporting ISUP payloads from gateway to gateway.

    "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.


2. Understanding MIME Multipart Bodies

    PSTN interworking nodes MUST understand the MIME type of
    "multipart/mixed" as defined in RFC2046 [4].  Clients express support
    for this by including "multipart/mixed" in an "Accept" header.

    "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types",
    RFC 2046, November 1996.


3. Transmission of Dual-Tone Multifrequency (DTMF) Information
    This transmission MAY be performed as described in RFC2833 [5].


4. Reliable Transmission of Provisional Responses
    When interworking with the PSTN, SIP messages MUST be sent reliably
    end-to-end; reliability of requests is guaranteed by the base
    protocol.  One application-layer provisional reliability mechanism
    for responses is described in [18].
 
   "Reliability of Provisional Responses in SIP", RFC 3262, June 2002.


5. Early Media
    One mechanism that provides a way of initiating a fully-featured early
    media system is described in [20].

    "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.


6. Mid-Call Transactions which do not change SIP state

    In support of mid-call transactions and other ISUP events that do not
    correspond to existing SIP methods, SIP gateways MUST support the
    INFO method, defined in RFC2976 [6].  Note that this document does
    not prescribe or endorse the use of INFO to carry DTMF digits.

    Gateways MUST accept "405 Method Not Allowed" and "501 Not
    Implemented" as non-fatal responses to INFO requests - that is, any
    call in progress MUST NOT be torn down if a destination so rejects an
    INFO request sent by a gateway.


7. Privacy Protection

    The base SIP protocol supports a method of specifying that a user is
    anonymous.  However, this system has a number of limitations - for
    example, it reveals the identity of the gateway itself, which could
    be a privacy-impacting disclosure.  Therefore gateways MAY support
    more sophisticated privacy systems.  One mechanism that provides a
    way of supporting fully-featured privacy negotiation (which interacts
    well with identity management systems) is described in [9B]

    "A Privacy Mechanism for the Session Initiation
        Protocol (SIP)", RFC 3323, November 2002.


8. CANCEL causes
    Therefore gateways MAY support a mechanism for end-to-end delivery of such failure
    reasons.  One mechanism that provides this capability is described in
        [9].

    "The Reason Header Field for the Session Initiation Protocol", RFC 3326, December
        2002.

 

    SIP to ISUP mapping 的一些细节, 查看 7.2.1 --- 7.3

   4.  The "called party status" code in the ACM message is mapped to a
       SIP provisional response (as described in Section 7.2.5 and
       Section 7.2.6) and returned to the SIP node.

   5.  If the ISUP variant permits, the remote ISUP node may issue a
       variety of Call Progress (CPG) messages to indicate, for example,
       that the call is being forwarded.

   6.  Upon receipt of a CPG message, the gateway will map the event
       code to a SIP provisional response (see Section 7.2.9) and send
       it to the SIP node.

    ISUP to SIP mapping 的一些细节, 查看 8.2.1 --- 8.2.8

   4.  Upon receipt of a provisional response of 180 or greater, the
       gateway will generate an ACM message.  If the response is not
       180, the ACM will carry a "called party status" value of "no
       indication."


Suspend/Resume and Hold, 查看 9.1 --- 9.2

Normal Release of the Connection, 查看 10.1 --- 10.2

ISUP Maintenance Messages, 查看 11.1 --- 11.3

Construction of Telephony URIs, 查看 12.1 --- 12.2

Other ISUP flavors, 查看 13.1