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
`
` 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.
`
`Johnston, et al. Best Current Practice [Page 1]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`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
`
`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.
`
`Johnston, et al. Best Current Practice [Page 2]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`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].
`
`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 [Page 3]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`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).
`
`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.
`
`Johnston, et al. Best Current Practice [Page 4]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`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:
`
` /* 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.
`
`Johnston, et al. Best Current Practice [Page 5]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 5
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
`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.
`
`Johnston, et al. Best Current Practice [Page 6]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 6
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
`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
`
`Johnston, et al. Best Current Practice [Page 7]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`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.
`
` 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
`
`Johnston, et al. Best Current Practice [Page 8]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 8
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
` 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
`
`Johnston, et al. Best Current Practice [Page 9]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 9
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
` ;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 */
`
`Johnston, et al. Best Current Practice [Page 10]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 10
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
` 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
`
`Johnston, et al. Best Current Practice [Page 11]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 11
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
` 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
` ;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
`
` F12 ACK Alice -> Proxy 1
`
` ACK sip:ngw1@a.example.com SIP/2.0
` Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
` Max-Forwards: 70
` 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 ACK
`
`Johnston, et al. Best Current Practice [Page 12]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 12
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
` Content-Length: 0
`
` F13 ACK Proxy 1 -> NGW 1
`
` ACK sip:ngw1@a.example.com 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
` 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
`
` /* Alice Hangs Up with Bob. */
`
` F14 BYE Alice -> Proxy 1
`
` BYE sip:ngw1@a.example.com SIP/2.0
` Via: SIP/2.0/TCP client.a.example.com:5060;branch=z9hG4bK74bf9
` Max-Forwards: 70
` 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: 2 BYE
` Content-Length: 0
`
` F15 BYE Proxy 1 -> NGW 1
`
` BYE sip:ngw1@a.example.com 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
` 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
`
`Johnston, et al. Best Current Practice [Page 13]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 13
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
` CSeq: 2 BYE
` Content-Length: 0
`
` F16 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
` 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 200 OK Proxy 1 -> A
`
` SIP/2.0 200 OK
` 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>
` ;tag=314159
` Call-ID: 2xTb9vxSit55XU7p8@a.example.com
` CSeq: 2 BYE
` Content-Length: 0
`
` F18 REL NGW 1 -> B
`
` REL
` CauseCode=16 Normal
`
` F19 RLC B -> NGW 1
`
` RLC
`
`Johnston, et al. Best Current Practice [Page 14]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`Page 14
`
`

`

`
`RFC 3666 SIP PSTN Call Flows December 2003
`
`2.2. Successful SIP to ISDN PBX call
`
` Alice Proxy 1 GW 1 PBX C
` | | | |
` | INVITE F1 | | |
` |--------------->| | |
` | 100 F2 | | |
` |<---------------| INVITE F3 | |
` | |--------------->| |
` | | 100 F4 | |
` | |<---------------| SETUP F5 |
` | | |--------------->|
` | | | CALL PROC F6 |
` | | |<---------------|
` | | | PROGress F7 |
` | | 180 F8 |<---------------|
` | 180 F9 |<---------------| |
` |<---------------| | |
` | | | One Way Voice |
` | | |<===============|
` | | | CONNect F10 |
` | | |<---------------|
` | | | CONNect ACK F11|
` | | 200 F12 |--------------->|
` | 200 F13 |<---------------| |
` |<---------------| | |
` | ACK F14 | | |
` |--------------->| ACK F15 | |
` | |--------------->| |
` | Both Way RTP Media | Both Way Voice |
` |<===============================>|<==============>|
` | BYE F16 | | |
` |--------------->| BYE F17 | |
` | |--------------->| |
` | | 200 F18 | |
` | 200 F19 |<---------------| DISConnect F20 |
` |<---------------| |--------------->|
` | | | RELease F21 |
` | | |<---------------|
` | | | RELease COM F22|
` | | |--------------->|
` | | | |
`
` 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]
`
`AT&T Exhibit 1036
`AT&T v. VoIP, IPR 2017-01384
`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.
`
` Message Details
`
` F1 INVITE Alice -> Proxy 1
`
` INVITE sips:+19185553333@ss1.a.example.com;user=phone SIP/2.0
` Via: SIP/2.0/TLS client.a.example.com:5061;branch=z9hG4bK74bf9
` Max-Forwards: 70
` 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
` Contact: <sips:alice@client.a.example.com>
` Proxy-Authorization: Digest username="alice",
` realm="a.example.com", nonce="qo0dc3a5ab22aa931904badfa1cf5j9h",
` opaque="", uri="sips:+1918555