Network Working Group A. Johnston Request for Comments: 3666 MCI BCP: 76 S. Donovan Category: Best Current Practice R. Sparks C. Cunningham dynamicsoft K. Summers Sonus December 2003
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 (2003). All Rights Reserved.
Abstract
This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.
Johnston, et al. Best Current Practice [Page 1]
RFC 3666 SIP PSTN Call Flows December 2003
Table of Contents
1. Overview..................................................... 2 1.1. General Assumptions.................................... 3 1.2. Legend for Message Flows............................... 4 1.3. SIP Protocol Assumptions............................... 5 2. SIP to PSTN Dialing.......................................... 6 2.1. Successful SIP to ISUP PSTN call....................... 7 2.2. Successful SIP to ISDN PBX call........................ 15 2.3. Successful SIP to ISUP PSTN call with overflow......... 23 2.4. Session established using ENUM Query................... 32 2.5. Unsuccessful SIP to PSTN call: Treatment from PSTN..... 38 2.6. Unsuccessful SIP to PSTN: REL w/Cause from PSTN........ 45 2.7. Unsuccessful SIP to PSTN: ANM Timeout.................. 49 3. PSTN to SIP Dialing.......................................... 54 3.1. Successful PSTN to SIP call............................ 55 3.2. Successful PSTN to SIP call, Fast Answer............... 62 3.3. Successful PBX to SIP call............................. 68 3.4. Unsuccessful PSTN to SIP REL, SIP error mapped to REL.. 74 3.5. Unsuccessful PSTN to SIP REL, SIP busy mapped to REL... 76 3.6. Unsuccessful PSTN->SIP, SIP error interworking to tones 80 3.7. Unsuccessful PSTN->SIP, ACM timeout.................... 84 3.8. Unsuccessful PSTN->SIP, ACM timeout, stateless Proxy... 88 3.9. Unsuccessful PSTN->SIP, Caller Abandonment............. 91 4. PSTN to PSTN Dialing via SIP Network......................... 96 4.1. Successful ISUP PSTN to ISUP PSTN call................. 97 4.2. Successful FGB PBX to ISDN PBX call with overflow...... 105 5. Security Considerations...................................... 113 6. References................................................... 115 6.1. Normative References................................... 115 6.2. Informative References................................. 115 7. Acknowledgments.............................................. 116 8. Intellectual Property Statement.............................. 116 9. Authors' Addresses........................................... 117 10. Full Copyright Statement..................................... 118
The call flows shown in this document were developed in the design of a SIP IP communications network. They represent an example of a minimum set of functionality.
It is the hope of the authors that this document will be useful for SIP implementers, designers, and protocol researchers alike and will help further the goal of a standard implementation of RFC 3261 [2]. These flows represent carefully checked and working group reviewed scenarios of the most common SIP/PSTN interworking examples as a companion to the specifications.
Johnston, et al. Best Current Practice [Page 2]
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].
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 [Page 3]
RFC 3666 SIP PSTN Call Flows December 2003
Gateways provide tones (ringing, busy, etc) and announcements to the PSTN side based on SIP response messages, or pass along audio in-band tones (ringing, busy tone, etc.) in an early media stream to the SIP side.
The interactions between the Proxy and Gateway can be summarized as follows:
- The SIP Proxy Server performs digit analysis and lookup and locates the correct gateway.
- The SIP Proxy Server performs gateway location based on primary and secondary routing.
Telephone numbers are usually represented as SIP URIs. Note that an alternative is the use of the tel URI [6].
This document shows typical examples of SIP/ISUP interworking. Although in the spirit of the SIP-T framework [7], these examples do not represent a complete implementation of the framework. The examples here represent more of a minimal set of examples for very basic SIP to ISUP interworking, rather than the more complex goal of ISUP transparency. In particular, there are NO examples of encapsulated ISUP in this document. If present, these messages would show S/MIME encryption due to the sensitive nature of this information, as discussed in the SIP-T Framework security considerations section. (Note - RFC 3204 [8] contains an example of an INVITE with encapsulated ISUP.) See the Security Considerations section for a more detailed discussion on the security of these call flows.
In ISUP, the Calling Party Number is abbreviated as CgPN and the Called Party Number is abbreviated as CdPN. Other abbreviations include Numbering Plan Indicator (NPI) and Nature of Address (NOA).
Dashed lines (---) represent signaling messages that are mandatory to the call scenario. These messages can be SIP or PSTN signaling. The arrow indicates the direction of message flow.
Double dashed lines (===) represent media paths between network elements.
Messages with parentheses around their name represent optional messages.
Johnston, et al. Best Current Practice [Page 4]
RFC 3666 SIP PSTN Call Flows December 2003
Messages are identified in the Figures as F1, F2, etc. This references the message details in the list that follows the Figure. Comments in the message details are shown in the following form:
This document does not prescribe the flows precisely as they are shown, but rather the flows illustrate the principles for best practice. They are best practices usages (orderings, syntax, selection of features for the purpose, handling of error) of SIP methods, headers and parameters. IMPORTANT: The exact flows here must not be copied as is by an implementer due to specific incorrect characteristics that were introduced into the document for convenience and are listed below. To sum up, the SIP/PSTN call flows represent well-reviewed examples of SIP usage, which are best common practice according to IETF consensus.
For simplicity in reading and editing the document, there are a number of differences between some of the examples and actual SIP messages. For example, the SIP Digest responses are not actual MD5 encodings. Call-IDs are often repeated, and CSeq counts often begin at 1. Header fields are usually shown in the same order. Usually only the minimum required header field set is shown, others that would normally be present, such as Accept, Supported, Allow, etc. are not shown.
Actors:
Element Display Name URI IP Address ------- ------------ --- ----------
User Agent Alice sip:alice@a.example.com 192.0.2.101 User Agent Bob sip:bob@b.example.com 192.0.2.200 Proxy Server sip:ss1.a.example.com 192.0.2.111 User Agent (Gateway) sip:gw1.a.example.com 192.0.2.201 User Agent (Gateway) sip:gw2.a.example.com 192.0.2.202 User Agent (Gateway) sip:gw3.a.example.com 192.0.2.203 User Agent (Gateway) sip:ngw1.a.example.com 192.0.2.103 User Agent (Gateway) sip:ngw2.a.example.com 192.0.2.102
Note that NGW 1 and NGW 2 also have device URIs (Contacts) of sip:ngw1@a.example.com and sip:ngw2@a.example.com which resolve to the Proxy Server sip:ss1.wcom.com using DNS SRV records.
In the following scenarios, Alice (sip:alice@a.example.com) is a SIP phone or other SIP-enabled device. Bob is reachable via the PSTN at global telephone number +19725552222. Alice places a call to Bob through a Proxy Server, Proxy 1, and a Network Gateway. In other scenarios, Alice places calls to Carol, who is served via a PBX (Private Branch Exchange) and is identified by a private extension 444-3333, or global number +1-918-555-3333. Note that Alice uses his/her global telephone number +1-314-555-1111 in the From header in the INVITE messages. This then gives the Gateway the option of using this header to populate the calling party identification field in subsequent signaling. Left open is the issue of how the Gateway can determine the accuracy of the telephone number which is necessary before passing it as a valid calling party number in the PSTN.
In these scenarios, Alice is a SIP phone or other SIP-enabled device. Alice places a call to Bob in the PSTN or Carol on a PBX through a Proxy Server and a Gateway.
In the failure scenarios, the call does not complete. In some cases however, a media stream is still setup. This is due to the fact that some failures in dialing to the PSTN result in in-band tones (busy, reorder tones or announcements - "The number you have dialed has changed. The new number is..."). The 183 Session Progress response containing SDP media information is used to setup this early media path so that the caller Alice knows the final disposition of the call.
The media stream is either terminated by the caller after the tone or announcement has been heard and understood, or by the Gateway after a timer expires.
In other failure scenarios, a SS7 Release with Cause Code is mapped to a SIP response. In these scenarios, the early media path is not used, but the actual failure code is conveyed to the caller by the SIP User Agent Client.
Alice dials the globalized E.164 number +19725552222 to reach Bob. Note that A might have only dialed the last 7 digits, or some other dialing plan. It is assumed that the SIP User Agent Client converts the digits into a global number and puts them into a SIP URI. Note that tel URIs could be used instead of SIP URIs.
Alice could use either their SIP address (sip:alice@a.example.com) or SIP telephone number (sip:+13145551111@ss1.a.example.com;user=phone) in the From header. In this example, the telephone number is included, and it is shown as being passed as calling party identification through the Network Gateway (NGW 1) to Bob (F5). Note
Johnston, et al. Best Current Practice [Page 7]
RFC 3666 SIP PSTN Call Flows December 2003
that for this number to be passed into the SS7 network, it would have to be somehow verified for accuracy.
In this scenario, Bob answers the call, then Alice disconnects the call. Signaling between NGW 1 and Bob's telephone switch is ANSI ISUP. For the details of SIP to ISUP mapping, refer to [4].
In this flow, notice that the Contact returned by NGW 1 in messages F7-11 is sip:ngw1@a.example.com. This is because NGW 1 only accepts SIP messages that come through Proxy 1 - any direct signaling will be ignored. Since this Contact URI may be used outside of this dialog and must be routable (Section 8.1.1.8 in RFC 3261 [2]) the Contact URI for NGW 1 must resolve to Proxy 1. This Contact URI resolves via DNS to Proxy 1 (sip:ss1.a.example.com) which then resolves it to sip:ngw1.a.example.com which is the address of NGW 1.
SIP/2.0 100 Trying Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Content-Length: 0
/* Proxy 1 uses a Location Service function to determine the gateway for terminating this call. The call is forwarded to NGW 1. Client for A prepares to receive data on port 49172 from the network.*/
;received=192.0.2.111 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Content-Length: 0
F5 IAM NGW 1 -> Bob
IAM CdPN=972-555-2222,NPI=E.164,NOA=National CgPN=314-555-1111,NPI=E.164,NOA=National
Alice is a SIP device while Carol is connected via a Gateway (GW 1) to a PBX. The PBX connection is via a ISDN trunk group. Alice dials Carol's telephone number (918-555-3333) which is globalized and put into a SIP URI.
Johnston, et al. Best Current Practice [Page 15]
RFC 3666 SIP PSTN Call Flows December 2003
The host portion of the Request-URI in the INVITE F3 is used to identify the context (customer, trunk group, or line) in which the private number 444-3333 is valid. Otherwise, this INVITE message could get forwarded by GW 1 and the context of the digits could become lost and the call unroutable.
Proxy 1 looks up the telephone number and locates the gateway that serves Carol. Carol is identified by its extension (444-3333) in the Request-URI sent to GW 1.
Note that the Contact URI for GW 1, as used in messages F8, F9, F12, and F13, is sips:4443333@gw1.a.example.com, which resolves directly to the gateway.
This flow shows the use of Secure SIP (sips) URIs.
SIP/2.0 100 Trying Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 From: Alice <sips:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Carol <sips:+19185553333@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Content-Length: 0
Johnston, et al. Best Current Practice [Page 17]
RFC 3666 SIP PSTN Call Flows December 2003
F5 SETUP GW 1 -> Carol
Protocol discriminator=Q.931 Message type=SETUP Bearer capability: Information transfer capability=0 (Speech) or 16 (3.1 kHz audio) Channel identification=Preferred or exclusive B-channel Progress indicator=1 (Call is not end-to-end ISDN;further call progress information may be available inband) Called party number: Type of number unknown Digits=444-3333
Protocol discriminator=Q.931 Message type=PROG Progress indicator=1 (Call is not end-to-end ISDN;further call progress information may be available inband)
F8 180 Ringing GW 1 -> Proxy 1
SIP/2.0 180 Ringing Via: SIP/2.0/TLS ss1.a.example.com:5061;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: <sips:ss1.a.example.com;lr> From: Alice <sips:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Carol <sips:+19185553333@ss1.a.example.com;user=phone> ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: <sips:4443333@gw1.a.example.com> Content-Length: 0
Johnston, et al. Best Current Practice [Page 18]
RFC 3666 SIP PSTN Call Flows December 2003
F9 180 Ringing Proxy 1 -> Alice
SIP/2.0 180 Ringing Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: <sips:ss1.a.example.com;lr> From: Alice <sips:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Carol <sips:+19185553333@ss1.a.example.com;user=phone> ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: <sips:4443333@gw1.a.example.com> Content-Length: 0
Alice calls Bob through Proxy 1. Proxy 1 tries to route to a Network Gateway NGW 1. NGW 1 is not available and responds with a 503 Service Unavailable (F4). The call is then routed to Network Gateway NGW 2. Bob answers the call. The call is terminated when Alice disconnects the call. NGW 2 and Bob's telephone switch use ANSI ISUP signaling.
Johnston, et al. Best Current Practice [Page 23]
RFC 3666 SIP PSTN Call Flows December 2003
NGW 2 also only accepts SIP messages that come through Proxy 1, so the Contact URI sip:ngw2@a.example.com is used in this flow.
/* Proxy 1 uses a Location Service function to determine where B is located. Proxy 1 receives a primary route NGW 1 and a secondary route NGW 2. NGW 1 is tried first */
ACK sip:ngw2@a.example.com SIP/2.0 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: <ss1.a.example.com;lr> From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 ACK Content-Length: 0
F15 ACK Proxy 1 -> NGW 2
ACK sip:ngw2@a.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Max-Forwards: 69 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 ACK
Johnston, et al. Best Current Practice [Page 29]
RFC 3666 SIP PSTN Call Flows December 2003
Content-Length: 0
/* RTP streams are established between A and B(via the GW) */
/* Alice Hangs Up with Bob. */
F16 BYE Alice -> Proxy 1
BYE sip:ngw2@a.example.com SIP/2.0 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: <ss1.a.example.com;lr> From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 BYE Content-Length: 0
F17 BYE Proxy 1 -> NGW 2
BYE sip:ngw2@a.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Max-Forwards: 69 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 BYE Content-Length: 0
F18 200 OK NGW 2 -> Proxy 1
SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.2 ;received=192.0.2.111 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
In this scenario, Alice places a call to Bob by dialing Bob's telephone number (9725552222). Alice's UA converts the phone number to an E.164 number (+19725552222), and performs an ENUM query [9] on the E.164 number (2.2.2.2.5.5.5.2.7.9.1.e164.arpa), which returns a NAPTR record containing a SIP AOR URI for Bob (sip:+19725552222@b.example.com). As a result, Alice's UA sends an INVITE and the call completes over IP bypassing the PSTN.
The call is terminated when Bob sends a BYE message.
Message Details
F1 ENUM Query Alice -> DNS Server
2.2.2.2.5.5.5.2.7.9.1.e164.arpa
Johnston, et al. Best Current Practice [Page 32]
RFC 3666 SIP PSTN Call Flows December 2003
F2 ENUM NAPTR Set DNS Server -> Alice
$ORIGIN 2.2.2.2.5.5.5.2.7.9.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:+19725552222@b.example.com!".
Alice calls Bob in the PSTN through a proxy server Proxy 1 and a Network Gateway NGW 1. The call is rejected by the PSTN with an in-band treatment (tone or recording) played. Alice hears the treatment and then hangs up, which results in a CANCEL (F9) being sent to terminate the call. (A BYE is not sent since no final response was ever received by Alice.)
SIP/2.0 100 Trying Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Content-Length: 0
/* Proxy 1 uses a Location Service function to determine where B is located. Based upon location analysis the call is forwarded to NGW 1. Client for A prepares to receive data on port 49172 from the network. */
/* Caller hears the recorded announcement, then hangs up */
F9 CANCEL Alice -> Proxy 1
CANCEL sip:+19725552222@ss1.a.example.com;user=phone SIP/2.0 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 CANCEL Content-Length: 0
F10 200 OK Proxy 1 -> A
SIP/2.0 200 OK Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 CANCEL Content-Length: 0
F11 CANCEL Proxy 1 -> NGW 1
CANCEL sip:+19725552222@ss1.a.example.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 CANCEL Content-Length: 0
Johnston, et al. Best Current Practice [Page 42]
RFC 3666 SIP PSTN Call Flows December 2003
F12 200 OK NGW 1 -> Proxy 1
SIP/2.0 200 OK Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 CANCEL Content-Length: 0
F13 REL NGW 1 -> B
REL CauseCode=18 No user responding
F14 RLC B -> NGW 1
RLC
F15 487 Request Terminated NGW 1 -> Proxy 1
SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Content-Length: 0
F16 ACK Proxy 1 -> NGW 1
ACK sip:+19725552222@ss1.a.example.com;user=phone SIP/2.0 Via: SIP/2.0/UDP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone>
Alice calls PSTN Bob through a Proxy Server Proxy 1 and a Network Gateway NGW 1. The call is rejected by the PSTN with a ANSI ISUP Release message REL containing a specific Cause code. This cause value (1) is mapped by the Gateway to a SIP 404 Address Incomplete response which is proxied back to Alice. For more details of ISUP cause value to SIP response mapping, refer to [4].
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:+44-1234@ss1.a.example.com;user=phone SIP/2.0 Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+44-1234@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Contact: <sip:alice@client.a.example.com;transport=tcp> Proxy-Authorization: Digest username="alice", realm="a.example.com", nonce="j1c3b0b01cf832da2c5ac51bb59a05b40", opaque="", uri="sip:+44-1234@ss1.a.example.com;user=phone",
SIP/2.0 100 Trying Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+44-1234@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Content-Length: 0
/* Proxy 1 uses a Location Service function to determine where B is located. Based upon location analysis the call is forwarded to NGW1. Client for A prepares to receive data on port 49172 from the network. */
SIP/2.0 100 Trying Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+44-1234@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Content-Length: 0
F5 IAM NGW 1 -> Bob
IAM CdPN=44-1234,NPI=E.164,NOA=International CgPN=314-555-1111,NPI=E.164,NOA=National
F6 REL Bob -> NGW 1
REL CauseValue=1 Unallocated number
F7 RLC NGW 1 -> Bob
RLC
/* Network Gateway maps CauseValue=1 to the SIP message 404 Not Found */
Johnston, et al. Best Current Practice [Page 47]
RFC 3666 SIP PSTN Call Flows December 2003
F8 404 Not Found NGW 1 -> Proxy 1
SIP/2.0 404 Not Found Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1 ;received=192.0.2.111 Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+44-1234@ss1.a.example.com;user=phone>;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Error-Info: <sip:not-found-ann@ann.a.example.com> Content-Length: 0
F9 ACK Proxy 1 -> NGW 1
ACK sip:+44-1234@ngw1.a.example.com;user=phone SIP/2.0 Max-Forwards: 70 Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+44-1234@ss1.a.example.com;user=phone>;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 ACK Content-Length: 0
F10 404 Not Found Proxy 1 -> Alice
SIP/2.0 404 Not Found Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+44-1234@ss1.a.example.com;user=phone>;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Error-Info: <sip:not-found-ann@ann.a.example.com> Content-Length: 0
From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+44-1234@ss1.a.example.com;user=phone>;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 ACK Content-Length: 0
Alice calls Bob in the PSTN through a proxy server Proxy 1 and Network Gateway NGW 1. The call is released by the Gateway after a timer expires due to no ANswer Message (ANM) being received. The Gateway sends an ISUP Release REL message to the PSTN and a 480 Temporarily Unavailable response to Alice in the SIP network.
/* Proxy 1 uses a Location Service function to determine where B is located. Based upon location analysis the call is forwarded to NGW 1. Client for A prepares to receive data on port 49172 from the network.*/
F2 100 Trying Proxy 1 -> A
SIP/2.0 100 Trying Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:+13145551111@ss1.a.example.com;user=phone> ;tag=9fxced76sl To: Bob <sip:+19725552222@ss1.a.example.com;user=phone> Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 INVITE Content-Length: 0
In these scenarios, Alice is placing calls from the PSTN to Bob in a SIP network. Alice's telephone switch signals to a Network Gateway (NGW 1) using ANSI ISUP.
Since the called SIP User Agent does not send in-band signaling information, no early media path needs to be established on the IP side. As a result, the 183 Session Progress response is not used. However, NGW 1 will establish a one way speech path prior to call completion, and generate ringing for the PSTN caller. Any tones or
Johnston, et al. Best Current Practice [Page 54]
RFC 3666 SIP PSTN Call Flows December 2003
recordings are generated by NGW 1 and played in this speech path. When the call completes successfully, NGW 1 bridges the PSTN speech path with the IP media path.
To reduce the number of messages, only a single proxy server is shown in these flows, which means that the a.example.com proxy server has access to the b.example.com location service.
In this scenario, Alice from the PSTN calls Bob through a Network Gateway NGW1 and Proxy Server Proxy 1. When Bob answers the call, the media path is setup end-to-end. The call terminates when Alice hangs up the call, with Alice's telephone switch sending an ISUP RELease message that is mapped to a BYE by NGW 1.
Johnston, et al. Best Current Practice [Page 55]
RFC 3666 SIP PSTN Call Flows December 2003
Message Details
F1 IAM Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-2222,NPI=E.164,NOA=National
/* Proxy 1 uses a Location Service function to determine where B is located. Based upon location analysis the call is forwarded to NGW 1. NGW 1 prepares to receive data on port 3456 from Alice.*/
This "fast answer" scenario is similar to 3.1., except that Bob immediately accepts the call, sending a 200 OK (F5) without sending a 180 Ringing response. The Gateway then sends an Answer Message (ANM) without sending an Address Complete Message (ACM). Note that for ETSI and some other ISUP variants, a CONnect message (CON) would be sent instead of the ANM.
Message Details
F1 IAM Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-2222,NPI=E.164,NOA=National
/* Proxy 1 uses a Location Service function to determine where B is located. Based upon location analysis the call is forwarded to User B. Bob prepares to receive data on port 3456 from Alice.*/
In this scenario, Alice dials from PBX A to Bob through GW 1 and Proxy 1. This is an example of a call that appears destined for the PSTN but is instead routed to a SIP Client.
Signaling between PBX A and GW 1 is Feature Group B (FGB) circuit associated signaling, in-band Mult-Frequency (MF) outpulsing. After the receipt of the 180 Ringing from Bob, GW 1 generates a ringing tone for Alice.
Bob answers the call by sending a 200 OK. The call terminates when Alice hangs up, causing GW1 to send a BYE.
Johnston, et al. Best Current Practice [Page 68]
RFC 3666 SIP PSTN Call Flows December 2003
The Gateway can only identify the trunk group that the call came in on; it cannot identify the individual line on PBX A that is placing the call. The SIP URI used to identify the caller is shown in these flows as sip:551313@gw1.a.example.com.
/* Proxy 1 uses a Location Service function to determine where the phone number +19725552222 is located. Based upon location analysis the call is forwarded to SIP Bob. */
Alice attempts to place a call through Gateway GW 1 and Proxy 1, which is unable to find any routing for the number. The call is rejected by Proxy 1 with a REL message containing a specific Cause value mapped by the gateway based on the SIP error.
Message Details
F1 IAM Alice -> GW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-9999,NPI=E.164,NOA=National
In this scenario, Alice calls Bob through Network Gateway NGW 1 and Proxy 1. The call is routed to Bob by Proxy 1. The call is rejected by Bob who sends a 600 Busy Everywhere response. The Gateway sends a REL message containing a specific Cause value mapped by the gateway based on the SIP error.
Since no interworking is indicated in the IAM (F1), the busy tone is generated locally by Alice's telephone switch. In some scenarios, the busy signal is generated by the Gateway since interworking is indicated. For more discussion on interworking, refer to [4].
Johnston, et al. Best Current Practice [Page 76]
RFC 3666 SIP PSTN Call Flows December 2003
Message Details
F1 IAM Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-2222,NPI=E.164,NOA=National
In this scenario, Alice calls Bob through Network Gateway NGW 1 and Proxy 1. The call is routed to Bob by Proxy 1. The call is rejected by the Bob client. NGW 1 sets up a two way voice path to Alice and plays busy tone. The caller then disconnects
NGW 1 plays the busy tone since the IAM (F1) indicates the interworking is present. In scenario 5.2.2., with no interworking, the busy indication is carried in the REL Cause value and is generated locally instead.
Again, note that for ETSI or ITU ISUP, a CONnect message would be sent instead of the Answer Message.
Message Details
F1 IAM Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-2222,NPI=E.164,NOA=National Interworking=encountered
Alice calls Bob through NGW 1 and Proxy 1. Proxy 1 re-sends the INVITE after the expiration of SIP timer T1 without receiving any response from Bob. Bob never responds with 180 Ringing or any other response (it is reachable but unresponsive). After the expiration of a timer, Alice's network disconnects the call by sending a Release message REL. The Gateway maps this to a CANCEL.
Message Details
F1 IAM Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-2222,NPI=E.164,NOA=National
In this scenario, Alice calls Bob through NGW 1 and Proxy 1. Since Proxy 1 is stateless (it does not send a 100 Trying response), NGW 1 re-sends the INVITE message after the expiration of SIP timer T1. Bob does not respond with 180 Ringing. Alice's network disconnects the call with a release REL (CauseCode=102 Timeout).
Message Details
F1 IAM Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-2222,NPI=E.164,NOA=National
In this scenario, Alice calls Bob through NGW 1 and Proxy 1. Bob does not respond with 200 OK. NGW 1 plays ringing tone since the ACM indicates that interworking has been encountered. Alice disconnects the call with a Release message REL which is mapped by NGW 1 to a
Johnston, et al. Best Current Practice [Page 91]
RFC 3666 SIP PSTN Call Flows December 2003
CANCEL. Note that if Bob had sent a 200 OK response after the REL, NGW 1 would have sent an ACK and then a BYE to properly terminate the call.
Message Details
F1 IAM Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=972-555-2222,NPI=E.164,NOA=National
In these scenarios, both the caller and the called party are in the telephone network, either normal PSTN subscribers or PBX extensions. The calls route through two Gateways and at least one SIP Proxy Server. The Proxy Server performs the authentication and location of the Gateways.
Again it is noted that the intent of this call flows document is not to provide a detailed parameter level mapping of SIP to PSTN protocols. For information on SIP to ISUP mapping, the reader is referred to other references [4].
In these scenarios, the call is successfully completed between the two Gateways, allowing the PSTN or PBX users to communicate. The 183 Session Progress response is used to indicate that in-band alerting may flow from the called party telephone switch to the caller.
In this scenario, Alice in the PSTN calls Carol who is an extension on a PBX. Alice's telephone switch signals via SS7 to the Network Gateway NGW 1, while Carol's PBX signals via SS7 with the Gateway GW 2. The CdPN and CgPN are mapped by GW 1 into SIP URIs and placed in the To and From headers. Proxy 1 looks up the dialed digits in the Request-URI and maps the digits to the PBX extension of Carol, which
Johnston, et al. Best Current Practice [Page 97]
RFC 3666 SIP PSTN Call Flows December 2003
is served by GW 2. The Proxy in F3 uses the host portion of the Request-URI to identify what private dialing plan is being referenced. The INVITE is then forwarded to GW 2 for call completion. An early media path is established end-to-end so that Alice can hear the ringing tone generated by PBX C.
Carol answers the call and the media path is cut through in both directions. Bob hangs up terminating the call.
Message Details
F1 IAM Switch Alice -> NGW 1
IAM CgPN=314-555-1111,NPI=E.164,NOA=National CdPN=918-555-3333,NPI=E.164,NOA=National
PBX Alice calls PBX Carol via Gateway GW 1 and Proxy 1. During the attempt to reach Carol via GW 2, an error is encountered - Proxy 1 receives a 503 Service Unavailable (F4) response to the forwarded INVITE. This could be due to all circuits being busy, or some other outage at GW 2. Proxy 1 recognizes the error and uses an alternative route via GW 3 to terminate the call. From there, the call proceeds normally with Carol answering the call. The call is terminated when Carol hangs up.
/* Proxy 1 uses a Location Service function to determine where B is located. Response is returned listing alternative routes, GW2 and GW3, which are then tried sequentially. */
Protocol discriminator=Q.931 Message type=SETUP Bearer capability: Information transfer capability=0 (Speech) or 16 (3.1 kHz audio) Channel identification=Preferred or exclusive B-channel Progress indicator=1 (Call is not end-to-end ISDN; further call progress information may be available inband) Called party number: Type of number and numbering plan ID=33 (National number in ISDN numbering plan) Digits=918-555-3333
This document provides examples of mapping from SIP to ISUP and ISUP to SIP. The gateways in these examples are compliant with the Security Considerations Section of RFC 3398 [4] which is summarized here.
Johnston, et al. Best Current Practice [Page 113]
RFC 3666 SIP PSTN Call Flows December 2003
There are few security concerns relating to the mapping of ISUP to SIP besides privacy considerations in the calling party number passing. Some concerns relating to the mapping from tel URI parameters to ISUP include the user creation of parameters and codes relating to called number and local number portability (LNP). An operator of a gateway should use policies similar to those present in PSTN switches to avoid security problems.
The mapping from a SIP response code to an ISUP Cause Code presents a theoretical risk, so a gateway operator may implement policies controlling this mapping. Gateways should also not rely on the contents of the From header field for identity information, as it may be arbitrarily populated by a user. Instead, some sort of cryptographic authentication and authorization should be used for identity determination. These flows show both HTTP Digest for authentication of users, although for brevity, the challenge is not always shown.
The early media cut-through shown in some flows is another potential security risk, but it is also required for proper interaction with the PSTN. Again, a gateway operator should use proper policies relating to early media to prevent fraud and misuse. Finally, a user agent (even a properly authenticated one) can launch multiple simultaneous requests through a gateway, constituting a denial of service attack. The adoption of policies to limit the number of simultaneous requests from a single entity may be used to prevent this attack.
As discussed in the SIP-T framework [7], SIP/ISUP interworking can be employed as an interdomain signaling mechanism that may be subject to pre-existing trust relationships between administrative domains. Any administrative domain implementing SIP-T or SIP/ISUP interworking 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 translation of ISUP information does not result in any security violations.
Although no examples of this are shown in this document, 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 as detailed in RFC 3261 [2]) to alleviate this concern. 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 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.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. E. and Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Camarillo, G., Roach, A. B., Peterson, J. and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[7] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002.
[8] 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.
[9] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[10] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", RFC 3665, December 2003.
Thanks to Rohan Mahy, Adam Roach, Gonzalo Camarillo, Cullen Jennings, and Tom Taylor for their detailed comments during the final review. Thanks to Dean Willis for his early contributions to the development of this document. Thanks to Jon Peterson for his help on the security section.
The authors wish to thank Kundan Singh for performing parser validation of messages.
The authors wish to thank the following individuals for their participation in a detailed review of this call flows document: Aseem Agarwal, Rafi Assadi, Ben Campbell, Sunitha Kumar, Jon Peterson, Marc Petit-Huguenin, Vidhi Rastogi, and Bodgey Yin Shaohua.
The authors also wish to thank the following individuals for their assistance: Jean-Francois Mule, Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, Matt Cannon, John Hearty, the whole MCI WorldCom IPOP Design team, Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI WorldCom, 3Com, Cisco, Lucent and Nortel.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2003). 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 assignees.
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.