Request for Comments: 3666 MCI
BCP: 76 S. Donovan
Category: Best Current Practice R. Sparks
C. Cunningham
dynamicsoft
K. Summers
Sonus
December 2003
Session Initiation Protocol (SIP)
Public Switched Telephone Network (PSTN) Call Flows
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 (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.
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
1. Overview
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.
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.
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).
1.2. Legend for Message Flows
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.
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:
/* Comments. */
1.3. SIP Protocol Assumptions
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.
2. SIP to PSTN Dialing
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.
2.1. Successful SIP to ISUP PSTN call
Alice Proxy 1 NGW 1 Switch B
| | | |
| INVITE F1 | | |
|--------------->| | |
| 100 F2 | | |
|<---------------| INVITE F3 | |
| |--------------->| |
| | 100 F4 | |
| |<---------------| IAM F5 |
| | |--------------->|
| | | ACM F6 |
| | 183 F7 |<---------------|
| 183 F8 |<---------------| |
|<---------------| | |
| Both Way RTP Media | One Way Voice |
|<===============================>|<===============|
| | | ANM F9 |
| | 200 F10 |<---------------|
| 200 F11 |<---------------| |
|<---------------| | |
| ACK F12 | | |
|--------------->| ACK F13 | |
| |--------------->| |
| Both Way RTP Media | Both Way Voice |
|<===============================>|<==============>|
| BYE F14 | | |
|--------------->| BYE F15 | |
| |--------------->| |
| | 200 F16 | |
| 200 F17 |<---------------| REL F18 |
|<---------------| |--------------->|
| | | RLC F19 |
| | |<---------------|
| | | |
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
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.
This flow shows TCP transport.
Message Details
F1 INVITE Alice -> Proxy 1
INVITE sip:+19725552222@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:+19725552222@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="dc3a5ab25302aa931904ba7d88fa1cf5", opaque="",
uri="sip:+19725552222@ss1.a.example.com;user=phone",
response="ccdca50cb091d587421457305d097458c"
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 100 Trying Proxy 1 -> Alice
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.*/
F3 INVITE Proxy 1 -> NGW 1
INVITE sip:+19725552222@ngw1.a.example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP ss1.a.example.com:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip: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>
Call-ID: 2xTb9vxSit55XU7p8@a.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 154
v=0
o=alice 2890844526 2890844526 IN IP4 client.a.example.com
s=-
c=IN IP4 client.a.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 100 Trying NGW 1 -> Proxy 1
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 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 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
F6 ACM Bob -> NGW 1
ACM
F7 183 Session Progress NGW 1 -> Proxy 1
SIP/2.0 183 Session Progress
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
Record-Route: <sip: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 INVITE
Contact: <sip:ngw1@a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.example.com
s=-
c=IN IP4 ngw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
/* NGW 1 sends PSTN audio (ringing) in the RTP path to A */
F8 183 Session Progress Proxy 1 -> Alice
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
Record-Route: <sip: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 INVITE
Contact: <sip:ngw1@a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.example.com
s=-
c=IN IP4 ngw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F9 ANM Bob -> NGW 1
ANM
F10 200 OK NGW 1 -> Proxy 1
SIP/2.0 200 OK
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
Record-Route: <sip: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 INVITE
Contact: <sip:ngw1@a.example.com;transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.example.com
s=-
c=IN IP4 gw1.a.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F11 200 OK Proxy 1 -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9