SIP-T RFC 3372 摘要

 SIP-T SIP for Telephones RFC 3372

This framework addresses the overall context in which PSTN-SIP interworking gateways might
be deployed, provides use cases and identifies the mechanisms necessary for interworking.

'encapsulation' and 'translation

   At a SIP-ISUP
   gateway, SS7 ISUP messages are encapsulated within SIP in order that
   information necessary for services is not discarded in the SIP
   request.  However, intermediaries like proxy servers that make
   routing decisions for SIP requests cannot be expected to understand
   ISUP, so simultaneously, some critical information is translated from
   an ISUP message into the corresponding SIP headers in order to
   determine how the SIP request will be routed.

Problem definition: To provide ISUP transparency across SS7-SIP
   interworking

   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

 A very elementary call-flow for SIP bridging is shown below.

       PSTN            MGC#1   Proxy    MGC#2          PSTN
       |-------IAM------>|       |        |              |
       |                 |-----INVITE---->|              |
       |                 |       |        |-----IAM----->|
       |                 |<--100 TRYING---|              |
       |                 |       |        |<----ACM------|
       |                 |<-----18x-------|              |
       |<------ACM-------|       |        |              |
       |                 |       |        |<----ANM------|
       |                 |<----200 OK-----|              |
       |<------ANM-------|       |        |              |
       |                 |------ACK------>|              |
       |====================Conversation=================|
       |-------REL------>|       |        |              |
       |<------RLC-------|------BYE------>|              |
       |                 |       |        |-----REL----->|
       |                 |<----200 OK-----|              |
       |                 |       |        |<----RLC------|
       |                 |       |        |              |

   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)

   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.

   The INFO [3]
   method should be used for this purpose.  Note however that INFO is
   not suitable for managing overlap dialing (for one way of
   implementing overlap dialing see [11]).  Also note that the use of
   INFO for signaling mid-call DTMF signals is not recommended (see
   RFC2833 [9] for a recommended mechanism).

      (Content-type:multipart/mixed;
      Content-type: application/sdp;
      Content-disposition: session; handling=required;
      Content-type: application/isup;
      Content-disposition: signal; handling=optional;)