rfc3372.txt

Session Initiation Protocol for Telephones (SIP-T)

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.