RFC 3666 (rfc3666) - Page 3 of 118

Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows

RFC 3666                  SIP PSTN Call Flows              December 2003


   These call flows are based on the current version 2.0 of SIP in RFC
   3261 [2] with SDP usage described in RFC 3264 [3].  Other RFCs also
   comprise the SIP standard but are not used in this set of basic call
   flows.  The SIP/ISUP mapping is based on RFC 3398 [4].

   Various PSTN signaling protocols are illustrated in this document:
   ISDN (Integrated Services Digital Network), ISUP (ISDN User Part) and
   FGB (Feature Group B) circuit associated signaling.  This document
   shows mainly ANSI ISUP due to its practical origins.  However, as
   used in this document, the usage is virtually identical to the ITU-T
   International ISUP used as the reference in [4].

   Basic SIP call flow examples are contained in a companion document,
   RFC 3665 [10].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

1.1.  General Assumptions

   A number of architecture, network, and protocol assumptions underlie
   the call flows in this document.  Note that these assumptions are not
   requirements.  They are outlined in this section so that they may be
   taken into consideration and to aid in the understanding of the call
   flow examples.

   The authentication of SIP User Agents in these example call flows is
   performed using HTTP Digest as defined in [3] and [5].

   Some Proxy Servers in these call flows insert Record-Route headers
   into requests to ensure that they are in the signaling path for
   future message exchanges.

   These flows show TLS, TCP, and UDP for transport.  SCTP could also be
   used.  See the discussion in RFC 3261 [2] for details on the
   transport issues for SIP.

   The SIP Proxy Server has access to a Location Service and other
   databases.  Information present in the Request-URI and the context
   (From header) is sufficient to determine to which proxy or gateway
   the message should be routed.  In most cases, a primary and secondary
   route will be determined in case of a Proxy or Gateway failure
   downstream.







Johnston, et al.         Best Current Practice