doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc3372.txt b/doc/rfc/rfc3372.txt
new file mode 100644
index 0000000..3320f93
--- /dev/null
+++ b/doc/rfc/rfc3372.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                          A. Vemuri
+Request for Comments: 3372                          Qwest Communications
+BCP: 63                                                      J. Peterson
+Category: Best Current Practice                                  NeuStar
+                                                          September 2002
+
+
+          Session Initiation Protocol for Telephones (SIP-T):
+                       Context and Architectures
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The popularity of gateways that interwork between the PSTN (Public
+   Switched Telephone Network) and SIP networks has motivated the
+   publication of a set of common practices that can assure consistent
+   behavior across implementations.  This document taxonomizes the uses
+   of PSTN-SIP gateways, provides uses cases, and identifies mechanisms
+   necessary for interworking.  The mechanisms detail how SIP provides
+   for both 'encapsulation' (bridging the PSTN signaling across a SIP
+   network) and 'translation' (gatewaying).
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  SIP-T for ISUP-SIP Interconnections  . . . . . . . . . . . . .  4
+   3.  SIP-T Flows  . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   3.1 SIP Bridging (PSTN - IP - PSTN)  . . . . . . . . . . . . . . .  8
+   3.2 PSTN origination - IP termination  . . . . . . . . . . . . . .  9
+   3.3 IP origination - PSTN termination  . . . . . . . . . . . . . . 11
+   4.  SIP-T Roles and Behavior . . . . . . . . . . . . . . . . . . . 12
+   4.1 Originator . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+   4.2 Terminator . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+   4.3 Intermediary . . . . . . . . . . . . . . . . . . . . . . . . . 14
+   4.4 Behavioral Requirements Summary  . . . . . . . . . . . . . . . 15
+   5.  Components of the SIP-T Protocol . . . . . . . . . . . . . . . 16
+   5.1 Core SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+   5.2 Encapsulation  . . . . . . . . . . . . . . . . . . . . . . . . 16
+   5.3 Translation  . . . . . . . . . . . . . . . . . . . . . . . . . 16
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 1]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   5.4 Support for mid-call signaling . . . . . . . . . . . . . . . . 17
+   6.  SIP Content Negotiation  . . . . . . . . . . . . . . . . . . . 17
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   10  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+   A.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
+
+1. Introduction
+
+   The Session Initiation Protocol (SIP [1]) is an application-layer
+   control protocol that can establish, modify and terminate multimedia
+   sessions or calls.  These multimedia sessions include multimedia
+   conferences, Internet telephony and similar applications.  SIP is one
+   of the key protocols used to implement Voice over IP (VoIP).
+   Although performing telephony call signaling and transporting the
+   associated audio media over IP yields significant advantages over
+   traditional telephony, a VoIP network cannot exist in isolation from
+   traditional telephone networks.  It is vital for a SIP telephony
+   network to interwork with the PSTN.
+
+   The popularity of gateways that interwork between the PSTN and SIP
+   networks has motivated the publication of a set of common practices
+   that can assure consistent behavior across implementations.  The
+   scarcity of SIP expertise outside the IETF suggests that the IETF is
+   the best place to stage this work, especially since SIP is in a
+   relative state of flux compared to the core protocols of the PSTN.
+   Moreover, the IETF working groups that focus on SIP (SIP and SIPPING)
+   are best positioned to ascertain whether or not any new extensions to
+   SIP are justified for PSTN interworking.  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.
+
+   An important characteristic of any SIP telephony network is feature
+   transparency with respect to the PSTN.  Traditional telecom services
+   such as call waiting, freephone numbers, etc., implemented in PSTN
+   protocols such as Signaling System No. 7 (SS7 [6]) should be offered
+   by a SIP network in a manner that precludes any debilitating
+   difference in user experience while not limiting the flexibility of
+   SIP.  On the one hand, it is necessary that SIP support the
+   primitives for the delivery of such services where the terminating
+   point is a regular SIP phone (see definition in Section 2 below)
+   rather than a device that is fluent in SS7.  However, it is also
+   essential that SS7 information be available at gateways, the points
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 2]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   of SS7-SIP interconnection, to ensure transparency of features not
+   otherwise supported in SIP.  If possible, SS7 information should be
+   available in its entirety and without any loss to trusted parties in
+   the SIP network across the PSTN-IP interface; one compelling need to
+   do so also arises from the fact that certain networks utilize
+   proprietary SS7 parameters to transmit certain information through
+   their networks.
+
+   Another important characteristic of a SIP telephony network is
+   routability of SIP requests - a SIP request that sets up a telephone
+   call should contain sufficient information in its headers to enable
+   it to be appropriately routed to its destination by proxy servers in
+   the SIP network.  Most commonly this entails that parameters of a
+   call like the dialed number should be carried over from SS7 signaling
+   to SIP requests.  Routing in a SIP network may in turn be influenced
+   by mechanisms such as TRIP [8] or ENUM [7].
+
+   The SIP-T (SIP for Telephones) effort provides a framework for the
+   integration of legacy telephony signaling into SIP messages.  SIP-T
+   provides the above two characteristics through techniques known as
+   'encapsulation' and 'translation' respectively.  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.
+
+   While pure SIP has all the requisite instruments for the
+   establishment and termination of calls, it does not have any baseline
+   mechanism to carry any mid-call information (such as the ISUP INF/INR
+   query) along the SIP signaling path during the session.  This mid-
+   call information does not result in any change in the state of SIP
+   calls or the parameters of the sessions that SIP initiates.  A
+   provision to transmit such optional application-layer information is
+   also needed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 3]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   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
+
+   While this document specifies the requirements above, it provide
+   mechanisms to satisfy them - however, this document does serve as an
+   framework for the documents that do provide these mechanisms, all of
+   which are referenced in Section 5.
+
+   Note that many modes of signaling are used in telephony (SS7 ISUP,
+   BTNUP, Q.931, MF etc.).  This document focuses on SS7 ISUP and aims
+   to specify the behavior across ISUP-SIP interfaces only.  The scope
+   of the SIP-T enterprise may, over time, come to encompass other
+   signaling systems as well.
+
+2. SIP-T for ISUP-SIP Interconnections
+
+   SIP-T is not a new protocol - it is a set of mechanisms for
+   interfacing traditional telephone signaling with SIP.  The purpose of
+   SIP-T is to provide protocol translation and feature transparency
+   across points of PSTN-SIP interconnection.  It intended for use where
+   a VoIP network (a SIP network, for the purposes of this document)
+   interfaces with the PSTN.
+
+   Using SIP-T, there are three basic models for how calls interact with
+   gateways.  Calls that originate in the PSTN can traverse a gateway to
+   terminate at a SIP endpoint, such as an IP phone.  Conversely, an IP
+   phone can make a call that traverses a gateway to terminate in the
+   PSTN.  Finally, an IP network using SIP may serve as a transit
+   network between gateways - a call may originate and terminate in the
+   PSTN, but cross a SIP-based network somewhere in the middle.
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 4]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   The SS7 interfaces of a particular gateway determine the ISUP
+   variants that that gateway supports.  Whether or nor a gateway
+   supports a particular version of ISUP determines whether it can
+   provide feature transparency while terminating a call.
+
+   The following are the primary agents in a SIP-T-enabled network.
+
+   o  PSTN (Public Switched Telephone Network): This refers to the
+      entire interconnected collection of local, long-distance and
+      international phone companies.  In the examples below, the term
+      Local Exchange Carrier (LEC) is used to denote a portion (usually,
+      a regional division) of the PSTN.
+
+   o  IP endpoints: Any SIP user agent that can act as an originator or
+      recipient of calls.  Thus, the following devices are classified as
+      IP endpoints:
+
+      *  Gateways: A telephony gateway provides a point of conversion
+         between signaling protocols (such as ISUP and SIP) as well as
+         circuit-switch and packet-switched audio media.  The term Media
+         Gateway Controller (MGC) is also used in the examples and
+         diagrams in this document to denote large-scale clusters of
+         decomposed gateways and control logic that are frequently
+         deployed today.  So for example, a SIP-ISUP gateway speaks ISUP
+         to the PSTN and SIP to the Internet and is responsible for
+         converting between the types of signaling, as well as
+         interchanging any associated bearer audio media.
+
+      *  SIP phones: The term used to represent all end-user devices
+         that originate or terminate SIP VoIP calls.
+
+      *  Interface points between networks where administrative policies
+         are enforced (potentially middleboxes, proxy servers, or
+         gateways).
+
+   o  Proxy Servers: A proxy server is a SIP intermediary that routes
+      SIP requests to their destinations.  For example, a proxy server
+      might direct a SIP request to another proxy, a gateway or a SIP
+      phone.
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 5]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+                           ********************
+                        ***                    ***
+                       *                         *
+                      *    -------                *
+                     *     |proxy|                 *
+                    *      -------                  *
+                |----|                            |----|
+               /|MGC1|       VoIP Network         |MGC2|\
+              /  ----                              ----  \
+      SS7    /       *                               *    \ SS7
+            /         *           -------           *      \
+           /           *          |proxy|          *        \
+       --------         *         -------         *     ---------
+       | LEC1 |          **                     **      | LEC2  |
+       --------            *********************        ---------
+
+   Figure 1: Motivation for SIP-T in ISUP-SIP interconnection
+
+   In Figure 2 a VoIP cloud serves as a transit network for telephone
+   calls originating in a pair of LECs, where SIP is employed as the
+   VoIP protocol used to set up and tear down these VoIP calls.  At the
+   edge of the depicted network, an MGC converts the ISUP signals to SIP
+   requests,  and sends them to a proxy server which in turn routes
+   calls on other MGCs.  Although this figure depicts only two MGCs,
+   VoIP deployments would commonly have many such points of
+   interconnection with the PSTN (usually to diversify among PSTN rate
+   centers).  For a call originating from LEC1 and be terminating in
+   LEC2, the originator in SIP-T is the gateway that generates the SIP
+   request for a VoIP call, and the terminator is the gateway that is
+   the consumer of the SIP request; MGC1 would thus be the originator
+   and MGC2, the terminator.  Note that one or more proxies may be used
+   to route the call from the originator to the terminator.
+
+   In this flow, in order to seamlessly integrate the IP network with
+   the PSTN, it is important to preserve the received SS7 information
+   within SIP requests at the originating gateway and reuse this SS7
+   information when signaling to the PSTN at the terminating gateway.
+   By encapsulating ISUP information in the SIP signaling, a SIP network
+   can ensure that no SS7 information that is critical to the
+   instantiation of features is lost when SIP bridges calls between two
+   segments of the PSTN.
+
+   That much said, if only the exchange of ISUP between gateways were
+   relevant here, any protocol for the transport of signaling
+   information may be used to achieve this, obviating the need for SIP
+   and consequently that of SIP-T.  SIP-T is employed in order to
+   leverage the intrinsic benefits of utilizing SIP: request routing and
+   call control leveraging proxy servers (including the use of forking),
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 6]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   ease of SIP service creation, SIP's capability negotiation systems,
+   and so on.  Translation of information from the received ISUP message
+   parameters to SIP header fields enables SIP intermediaries to
+   consider this information as they handle requests.  SIP-T thus
+   facilitates call establishment and the enabling of new telephony
+   services over the IP network while simultaneously providing a method
+   of feature-rich interconnection with the PSTN.
+
+   Finally, the scenario in Figure 2 is just one of several flows in
+   which SIP-T can be used - voice calls do not always both originate
+   and terminate in the PSTN (via gateways); SIP phones can also be
+   endpoints in a SIP-T session.  In subsequent sections, the following
+   possible flows will be further detailed:
+
+   1.  PSTN origination - PSTN termination: The originating gateway
+       receives ISUP from the PSTN and it preserves this information
+       (via encapsulation and translation) in the SIP messages that it
+       transmits towards the terminating gateway.  The terminator
+       extracts the ISUP content from the SIP message that it receives
+       and it reuses this information in signaling sent to the PSTN.
+
+   2.  PSTN origination - IP termination: The originating gateway
+       receives ISUP from the PSTN and it preserves this ISUP
+       information in the SIP messages (via encapsulation and
+       translation) that it directs towards the terminating SIP user
+       agent.  The terminator has no use for the encapsulated ISUP and
+       ignores it.
+
+   3.  IP origination - PSTN termination: A SIP phone originates a VoIP
+       call that is routed by one or more proxy servers to the
+       appropriate terminating gateway.  The terminating gateway
+       converts to ISUP signaling and directs the call to an appropriate
+       PSTN interface, based on information that is present in the
+       received SIP header.
+
+   4.  IP origination - IP termination: This is a case for pure SIP.
+       SIP-T (either encapsulation or translation of ISUP) does not come
+       into play as there is no PSTN interworking.
+
+3. SIP-T Flows
+
+   The follow sections explore the essential SIP-T flows in detail.
+   Note that because proxy servers are usually responsible for routing
+   SIP requests (based on the Request-URI) the eventual endpoints at
+   which a SIP request will terminate is generally not known to the
+   originator.  So the originator does not select from the flows
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 7]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   described in this section, as a matter of static configuration or on
+   a per-call basis - rather, each call is routed by the SIP network
+   independently, and it may instantiate any of the flows below as the
+   routing logic of the network dictates.
+
+3.1 SIP Bridging (PSTN - IP - PSTN)
+
+                         ********************
+                      ***                    ***
+                     *                         *
+                    *    -------                *
+                   *     |proxy|                 *
+                  *      -------                  *
+               |---|                             |---|
+              /|MGC|       VoIP Network          |MGC|\
+             /  ---                               ---  \
+            /     *                               *     \
+           /       *            -------           *      \
+          /          *          |proxy|          *        \
+      --------         *         -------         *     ---------
+      | PSTN |          ***                    ***      | PSTN  |
+      --------            *********************        ---------
+
+   Figure 2: PSTN origination - PSTN termination (SIP Bridging)
+
+   A scenario in which a SIP network connects two segments of the PSTN
+   is referred to as 'SIP bridging'.  When a call destined for the SIP
+   network originates in the PSTN, an SS7 ISUP message will eventually
+   be received by the gateway that is the point of interconnection with
+   the PSTN network.  This gateway is from the perspective of the SIP
+   protocol the user agent client for this call setup request.
+   Traditional SIP routing is used in the IP network to determine the
+   appropriate point of termination (in this instance a gateway) and to
+   establish a SIP dialog and begin negotiation of a media session
+   between the origination and termination endpoints.  The egress
+   gateway then signals ISUP to the PSTN, reusing any encapsulated ISUP
+   present in the SIP request it receives as appropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 8]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   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------|
+       |                 |       |        |              |
+
+3.2 PSTN origination - IP termination
+
+                           ********************
+                        ***                    ***
+                       *                         *
+                      *                           *
+                     *                             *
+                    *                               *
+                |----|                            |-----|
+               /|MGC |       VoIP Network         |proxy|\
+              /  ----                              -----  \
+             /       *                               *     \
+            /         *                             *       \
+           /           *                           *         \
+      --------         *                         *     -------------
+      | PSTN |          **                     **      | SIP phone |
+      --------            *********************        -------------
+
+   Figure 3: PSTN origination - IP termination
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                  [Page 9]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   A call originates from the PSTN and terminates at a SIP phone.  Note
+   that in Figure 5, the proxy server acts as the registrar for the SIP
+   phone in question.
+
+   A simple call-flow depicting the ISUP and SIP signaling for a PSTN-
+   originated call terminating at a SIP endpoint follows:
+
+   PSTN           MGC                  Proxy              SIP phone
+     |----IAM----->|                     |                     |
+     |             |--------INVITE------>|                     |
+     |             |                     |-------INVITE------->|
+     |             |<------100 TRYING----|                     |
+     |             |                     |<-------18x----------|
+     |             |<---------18x--------|                     |
+     |<----ACM-----|                     |                     |
+     |             |                     |<-------200 OK-------|
+     |             |<-------200 OK-------|                     |
+     |<----ANM-----|                     |                     |
+     |             |---------ACK-------->|                     |
+     |             |                     |---------ACK-------->|
+     |=====================Conversation========================|
+     |-----REL---->|                     |                     |
+     |             |----------BYE------->|                     |
+     |<----RLC-----|                     |---------BYE-------->|
+     |             |                     |<-------200 OK-------|
+     |             |<-------200 OK-------|                     |
+     |             |                     |                     |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 10]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+3.3 IP origination - PSTN termination
+
+                          ********************
+                        ***                    ***
+                       *                         *
+                      *                           *
+                     *                             *
+                    *                               *
+               |-----|                            |----|
+              /|proxy|       VoIP Network         |MGC |\
+             /  -----                              ----  \
+            /       *                               *     \
+           /         *                             *       \
+          /           *                           *         \
+      ------------     *                         *     ---------
+      |SIP phone |      **                     **      | PSTN  |
+      ------------        *********************        ---------
+
+   Figure 4: IP origination - PSTN termination
+
+   A call originates from a SIP phone and terminates in the PSTN.
+   Unlike the previous two flows, there is therefore no ISUP
+   encapsulation in the request - the terminating gateway therefore only
+   performs translation on the SIP headers to derive values for ISUP
+   parameters.
+
+   A simple call-flow illustrating the different legs in the call is as
+   shown below.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 11]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+        SIP phone         Proxy                    MGC          PSTN
+     |-----INVITE----->|                       |             |
+     |                 |--------INVITE-------->|             |
+     |<---100 TRYING---|                       |-----IAM---->|
+     |                 |<------100 TRYING------|             |
+     |                 |                       |<----ACM-----|
+     |                 |<---------18x----------|             |
+     |<------18x-------|                       |             |
+     |                 |                       |<----ANM-----|
+     |                 |<--------200 OK--------|             |
+     |<-----200 OK-----|                       |             |
+     |-------ACK------>|                       |             |
+     |                 |----------ACK--------->|             |
+     |========================Conversation===================|
+     |-------BYE------>|                       |             |
+     |                 |----------BYE--------->|             |
+     |                 |                       |-----REL---->|
+     |                 |<--------200 OK--------|             |
+     |<-----200 OK-----|                       |<----RLC-----|
+
+4. SIP-T Roles and Behavior
+
+   There are three distinct sorts of elements (from a functional point
+   of view) in a SIP VoIP network that interconnects with the PSTN:
+
+   1.  The originators of SIP signaling
+
+   2.  The terminators of SIP signaling
+
+   3.  The intermediaries that route SIP requests from the originator to
+       the terminator
+
+   Behavior for the Section 4.1, Section 4.2 and Section 4.3
+   intermediary roles in a SIP-T call are described in the following
+   sections.
+
+4.1 Originator
+
+   The function of the originating user agent client is to generate the
+   SIP Call setup requests (i.e., INVITEs).  When a call originates in
+   the PSTN, a gateway is the UAC; otherwise some native SIP endpoint is
+   the UAC.  In either case, note that the originator generally cannot
+   anticipate what sort of entity the terminator will be, i.e., whether
+   final destination of the request is in a SIP network or the PSTN.
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 12]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   In the case of calls originating in the PSTN (see Figure 3 and Figure
+   5), the originating gateway takes the necessary steps to preserve the
+   ISUP information by encapsulating it in the SIP request it creates.
+   The originating gateway is entrusted with the responsibility of
+   identifying the version of the ISUP (ETSI, ANSI, etc.) that it has
+   received and providing this information in the encapsulated ISUP
+   (usually by adding a multipart MIME body with appropriate MIME
+   headers).  It then formulates the headers of the SIP INVITE request
+   from the parameters of the ISUP that it has received from the PSTN as
+   appropriate (see Section 5).  This might, for instance, entail
+   setting the 'To:' header field in the INVITE to the reflect dialed
+   number (Called Party Number) of the received ISUP IAM.
+
+   In other cases (like Figure 7), a SIP phone is the originator of a
+   VoIP call.  Usually, the SIP phone sends requests to a SIP proxy that
+   is responsible for routing the request to an appropriate destination.
+   There is no ISUP to encapsulate at the user agent client, as there is
+   no PSTN interface.  Although the call may terminate in the telephone
+   network and need to signal ISUP in order for that to take place, the
+   originator has no way to anticipate this and it would be foolhardy to
+   require that all SIP VoIP user agents have the capability to generate
+   ISUP.  It is therefore not the responsibility of an IP endpoints like
+   a SIP phone to generate encapsulated ISUP.  Thus, an originator must
+   generate the SIP signaling while performing ISUP encapsulation and
+   translation when possible (meaning when the call has originated in
+   the PSTN).
+
+   Originator requirements: encapsulate ISUP, translate information from
+   ISUP to SIP, multipart MIME support (for gateways only)
+
+4.2 Terminator
+
+   The SIP-T terminator is a consumer of the SIP calls.  The terminator
+   is a standard SIP UA that can be either a gateway that interworks
+   with the PSTN or a SIP phone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 13]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   In case of PSTN terminations (see Figure 3 and Figure 7) the egress
+   gateway terminates the call to its PSTN interface.  The terminator
+   generates the ISUP appropriate for signaling to the PSTN from the
+   incoming SIP message.  Values for certain ISUP parameters may be
+   gleaned from the SIP headers or extracted directly from an
+   encapsulated ISUP body.  Generally speaking, a gateway uses any
+   encapsulated ISUP as a template for the message it will send, but it
+   overwrites parameter values in the template as it translates SIP
+   headers or adds any parameter values that reflect its local policies
+   (see Appendix A item 1).
+
+   In case of an IP termination (Figure 5), the SIP UAS that receives
+   SIP messages with encapsulated ISUP typically disregards the ISUP
+   message.  This does introduce a general requirement, however, that
+   devices like SIP phones handle multipart MIME messages and unknown
+   MIME types gracefully (this is a baseline SIP requirement, but also a
+   place where vendors have been known to make shortcuts).
+
+   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)
+
+4.3 Intermediary
+
+   Intermediaries like proxy servers are entrusted with the task of
+   routing messages to one another, as well as gateways and SIP phones.
+   Each proxy server makes a forwarding decision for a SIP request based
+   on values of various headers, or 'routable elements' (including the
+   Request-URI, route headers, and potentially many other elements of a
+   SIP request).
+
+   SIP-T does introduce some additional considerations for forwarding a
+   request that could lead to new features and requirements for
+   intermediaries.  Feature transparency of ISUP is central to the
+   notion of SIP-T.  Compatibility between the ISUP variants of the
+   originating and terminating PSTN interfaces automatically leads to
+   feature transparency.  Thus, proxy servers might take an interest in
+   the variants of ISUP that are encapsulated with requests - the
+   variant itself could become a routable element.  The termination of a
+   call at a point that results in greater proximity to the final
+   destination (rate considerations) is also an important consideration.
+   The preference of one over the other results in a trade-off between
+   simplicity of operation and cost.  The requirement of procuring a
+   reasonable rate may dictate that a SIP-T call spans dissimilar PSTN
+   interfaces (SIP bridging across different gateways that don't support
+   any ISUP variants in common).  In order to optimize for maximum
+   feature transparency and rate, some operators of intermediaries might
+   want to consider practices along the following lines:
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 14]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   a) The need for ISUP feature transparency may necessitate ISUP
+      variant translation (conversion), i.e., conversion from one
+      variant of ISUP to another in order to facilitate the termination
+      of that call over a gateway interface that does not support the
+      ISUP variant of the originating PSTN interface.  (See Appendix A
+      item 2.) Although in theory conversion may be performed at any
+      point in the path of the request, it is optimal to perform it at a
+      point that is at the greatest proximity to the terminating
+      gateway.  This could be accomplished by delivering the call to an
+      application that might perform the conversion between variants.
+      Feature transparency in this case is contingent on the
+      availability of resources to perform ISUP conversion, and it
+      incurs an increase in the call-set up time.
+
+   b) An alternative would be to sacrifice ISUP transparency by handing
+      the call off to a gateway that does not support the version of the
+      originating ISUP.  The terminating MGC would then just ignore the
+      encapsulated ISUP and use the information in the SIP header to
+      terminate the call.
+
+   So, it may be desirable for proxy servers to have the intelligence to
+   make a judicious choice given the options available to it.
+
+   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.
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 15]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   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.
+
+5. Components of the SIP-T Protocol
+
+   The mechanisms described in the following sections are the components
+   of SIP-T that provide the protocol functions entailed by the
+   requirements.
+
+5.1 Core SIP
+
+   SIP-T uses the methods and procedures of SIP as defined by RFC 3261.
+
+5.2 Encapsulation
+
+   Encapsulation of the PSTN signaling is one of the major requirements
+   of SIP-T.  SIP-T uses multipart MIME bodies to enable SIP messages to
+   contain multiple payloads (Session Description Protocol or SDP [5],
+   ISUP, etc.).  Numerous ISUP variants are in existence today; the ISUP
+   MIME type enable recipients too recognize the ISUP type (and thus
+   determine whether or not they support the variant) in the most
+   expeditious possible manner.  One scheme for performing ISUP
+   encapsulation using multi-part MIME has been described in [2].
+
+5.3 Translation
+
+   Translation encompasses all aspects of signaling protocol conversion
+   between SIP and ISUP.  There are essentially two components to the
+   problem of translation:
+
+   1.  ISUP SIP message mapping:  This describes a mapping between ISUP
+       and SIP at the message level.  In SIP-T deployments gateways are
+       entrusted with the task of generating a specific ISUP message for
+       each SIP message received and vice versa.  It is necessary to
+       specify the rules that govern the mapping between ISUP and SIP
+       messages (i.e., what ISUP messages is sent when a particular SIP
+       message is received: an IAM must be sent on receipt of an INVITE,
+       a REL for BYE, and so on).  A potential mapping between ISUP and
+       SIP messages has been described in [10].
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 16]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   2.  ISUP parameter-SIP header mapping:  A SIP request that is used to
+       set up a telephone call should contain information that enables
+       it to be appropriately routed to its destination by proxy servers
+       in the SIP network - for example, the telephone number dialed by
+       the originating user.  It is important to standardize a set of
+       practices that defines the procedure for translation of
+       information from ISUP to SIP (for example, the Called Party
+       Number in an ISUP IAM must be mapped onto the SIP 'To' header
+       field and Request-URI, etc.).  This issue becomes inherently more
+       complicated by virtue of the fact that the headers of a SIP
+       request (especially an INVITE) may be transformed by
+       intermediaries, and that consequently, the SIP headers and
+       encapsulated ISUP bodies come to express conflicting values -
+       effectively, a part of the encapsulated ISUP may be rendered
+       irrelevant and obsolete.
+
+5.4 Support for mid-call signaling
+
+   Pure SIP does not have any provision for carrying any mid-call
+   control information that is generated during a session.  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).
+
+6. SIP Content Negotiation
+
+   The originator of a SIP-T request might package both SDP and ISUP
+   elements into the same SIP message by using the MIME multipart
+   format.  Traditionally in SIP, if the terminating device does not
+   support a multipart payload (multipart/mixed) and/or the ISUP MIME
+   type, it would then reject the SIP request with a 415 Unsupported
+   Media Type specifying the media types it supports (by default,
+   'application/SDP').  The originator would subsequently have to re-
+   send the SIP request after stripping out the ISUP payload (i.e.  with
+   only the SDP payload) and this would then be accepted.
+
+   This is a rather cumbersome flow, and it is thus highly desirable to
+   have a mechanism by which the originator could signify which bodies
+   are required and which are optional so that the terminator can
+   silently discard optional bodies that it does not understand
+   (allowing a SIP phone to ignore an ISUP payload when processing ISUP
+   is not critical).  This is contingent upon the terminator having
+   support for a Content-type of multipart/mixed and access to the
+   Content-Disposition header to express criticality.
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 17]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   1.  Support for ISUP is optional.  Therefore, UA2 accepts the INVITE
+       irrespective of whether it can process the ISUP.
+
+   UA1                    UA2
+   INVITE-->
+      (Content-type:multipart/mixed;
+      Content-type: application/sdp;
+      Content-disposition: session; handling=required;
+      Content-type: application/isup;
+      Content-disposition: signal; handling=optional;)
+
+                         <--18x
+
+   2.  Support for ISUP is preferred.  UA2 does not support the ISUP and
+       rejects the INVITE with a 415 Unsupported Media Type.  UA1 strips
+       off the ISUP and re-sends the INVITE with SDP only and this is
+       the accepted.
+
+   UA1                    UA2
+   INVITE--> (Content-type:multipart/mixed;
+      Content-type: application/sdp;
+      Content-disposition: session; handling=required;
+      Content-type: application/isup;
+      Content-disposition: signal; handling=required;)
+
+
+                           <--415
+                     (Accept: application/sdp)
+
+   ACK-->
+
+   INVITE-->
+   (Content-type: application/sdp)
+
+                           <--18x
+
+   3.  Support for ISUP is mandatory for call establishment.  UA2 does
+       not support the ISUP and rejects the INVITE with a 415
+       Unsupported Media type.  UA1 then directs its request to UA3.
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 18]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   UA1                    UA2
+   INVITE--> (Content-type:multipart/mixed;
+      Content-type: application/sdp;
+      Content-disposition: session; handling=required;
+      Content-type: application/isup;
+      Content-disposition: signal; handling=required;)
+
+                        <--415
+                  (Accept: application/sdp)
+
+   ACK-->
+
+   UA1                   UA3
+   INVITE--> (Content-type:multipart/mixed;
+       Content-type: application/sdp;
+       Content-disposition: session; handling=required;
+       Content-type: application/isup;
+       Content-disposition: signal; handling=required;)
+
+   Note that the exchanges of messages above are not complete; only the
+   messages relevant to this discussion are shown.  Specifics of the
+   ISUP MIME type can be obtained from [2].  The 'version' and 'base'
+   parameters are not shown here, but must be used in accordance with
+   the rules of [2].
+
+7. Security Considerations
+
+   SIP-T can be employed as an interdomain signaling mechanism that may
+   be subject to pre-existing trust relationships between administrative
+   domains.  In many legal environments, distribution of ISUP is
+   restricted to licensed carriers; SIP-T introduces some challenges in
+   so far as it bridges carrier signaling with end-user signaling.  Any
+   administrative domain implementing SIP-T should have an adequate
+   security apparatus (including elements that manage any appropriate
+   policies to manage fraud and billing in an interdomain environment)
+   in place to ensure that the transmission of ISUP information does not
+   result in any security violations.
+
+   Transporting ISUP in SIP bodies may provide opportunities for abuse,
+   fraud, and privacy concerns, especially when SIP-T requests can be
+   generated, inspected or modified by arbitrary SIP endpoints.  ISUP
+   MIME bodies should be secured (preferably with S/MIME [4]) to
+   alleviate this concern, as is described in the Security
+   Considerations of the core SIP specification [1].  Authentication
+   properties provided by S/MIME would allow the recipient of a SIP-T
+   message to ensure that the ISUP MIME body was generated by an
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 19]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   authorized entity.  Encryption would ensure that only carriers
+   possessing a particular decryption key are capable of inspecting
+   encapsulated ISUP MIME bodies in a SIP request.
+
+   SIP-T endpoints MUST support S/MIME signatures (CMS SignedData), and
+   SHOULD support encryption (CMS EnvelopedData).
+
+8. IANA Considerations
+
+   This document introduces no new considerations for IANA.
+
+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, May 2002.
+
+   [2]   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.
+
+   [3]   Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
+
+   [4]   Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
+         2633, June 1999.
+
+   [5]   Handley, M. and V. Jacobson, "SDP: Session Description
+         Protocol", RFC 2327, April 1998.
+
+Non-Normative References
+
+   [6]   International Telecommunications Union, "Signaling System No.
+         7; ISDN User Part Signaling procedures", ITU-T Q.764, September
+         1997, <http://www.itu.int>.
+
+   [7]   Faltstrom, P., "E.164 number and DNS", RFC 2916, September
+         2000.
+
+   [8]   Rosenberg, J., Salama, H. and M. Squire, "Telephony Routing
+         over IP (TRIP)", RFC 3219, January 2002.
+
+   [9]   Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
+         Telephony Tones and Telephony Signals", RFC 2833, May 2000.
+
+   [10]  Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to SIP
+         Mapping",  Work in Progress.
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 20]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+   [11]  Camarillo, G., Roach, A., Peterson, J. and L. Ong, "Mapping of
+         ISUP Overlap Signaling to SIP", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 21]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+Appendix A. Notes
+
+   1.  Some terminating MGCs may alter the encapsulated ISUP in order to
+       remove any conditions specific to the originating circuit; for
+       example, continuity test flags in the Nature of Connection
+       Indicators, etc.
+
+   2.  Even so, the relevance of ANSI-specific information in an ETSI
+       network (or vice versa) is questionable.  Clearly, the strength
+       of SIP-T is realized when the encapsulated ISUP involves the
+       usage of proprietary parameters.
+
+Appendix B. Acknowledgments
+
+   We thank Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan
+   Rosenberg, Dean Willis, Robert F.  Penfield, Steve Donovan, Allison
+   Mankin, Scott Bradner and Steve Bellovin for their valuable comments.
+
+   The original 'SIP+' proposal for interconnecting portions of the PSTN
+   with SIP bridging was developed by Eric Zimmerer.
+
+Authors' Addresses
+
+   Aparna Vemuri-Pattisam
+   Qwest Communications
+   6000 Parkwood Pl
+   Dublin, OH  43016 US
+   EMail: Aparna.Vemuri@Qwest.com
+          vaparna10@yahoo.com
+
+   Jon Peterson
+   NeuStar, Inc.
+   1800 Sutter St
+   Suite 570
+   Concord, CA  94520 US
+   Phone: +1 925/363-8720
+   EMail: jon.peterson@neustar.biz
+   URI:   http://www.neustar.biz/
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 22]
+
+RFC 3372                         SIP-T                    September 2002
+
+
+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
+   English.
+
+   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
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vemuri & Peterson        Best Current Practice                 [Page 23]
+