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

   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.

   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.