throbber
Network Working Group A. Johnston
`Request for Comments: 3665 MCI
`BCP: 75 S. Donovan
`Category: Best Current Practice R. Sparks
` C. Cunningham
` dynamicsoft
` K. Summers
` Sonus
` December 2003
`
` Session Initiation Protocol (SIP) Basic Call Flow Examples
`
`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 gives examples of Session Initiation Protocol (SIP)
` call flows. Elements in these call flows include SIP User Agents and
` Clients, SIP Proxy and Redirect Servers. Scenarios include SIP
` Registration and SIP session establishment. Call flow diagrams and
` message details are shown.
`
`Johnston, et al. Best Current Practice [Page 1]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 1
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`Table of Contents
`
` 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
` 1.1. General Assumptions. . . . . . . . . . . . . . . . . . . 3
` 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . 3
` 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . 4
` 2. SIP Registration . . . . . . . . . . . . . . . . . . . . . . . 4
` 2.1. Successful New Registration. . . . . . . . . . . . . . . 5
` 2.2. Update of Contact List . . . . . . . . . . . . . . . . . 7
` 2.3. Request for Current Contact List . . . . . . . . . . . . 8
` 2.4. Cancellation of Registration . . . . . . . . . . . . . . 9
` 2.5. Unsuccessful Registration. . . . . . . . . . . . . . . . 10
` 3. SIP Session Establishment. . . . . . . . . . . . . . . . . . . 12
` 3.1. Successful Session Establishment . . . . . . . . . . . . 12
` 3.2. Session Establishment Through Two Proxies. . . . . . . . 15
` 3.3. Session with Multiple Proxy Authentication . . . . . . . 26
` 3.4. Successful Session with Proxy Failure. . . . . . . . . . 37
` 3.5. Session Through a SIP ALG. . . . . . . . . . . . . . . . 46
` 3.6. Session via Redirect and Proxy Servers with SDP in ACK . 54
` 3.7. Session with re-INVITE (IP Address Change) . . . . . . . 61
` 3.8. Unsuccessful No Answer . . . . . . . . . . . . . . . . . 67
` 3.9. Unsuccessful Busy. . . . . . . . . . . . . . . . . . . . 75
` 3.10. Unsuccessful No Response from User Agent . . . . . . . . 80
` 3.11. Unsuccessful Temporarily Unavailable . . . . . . . . . . 85
` 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 91
` 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
` 5.1. Normative References . . . . . . . . . . . . . . . . . . 91
` 5.2. Informative References . . . . . . . . . . . . . . . . . 91
` 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 91
` 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 92
` 8. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 93
` 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 94
`
`1. Overview
`
` The call flows shown in this document were developed in the design of
` a SIP IP communications network. They represent an example 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 [1].
` These flows represent carefully checked and working group reviewed
` scenarios of the most basic examples as a companion to the
` specifications.
`
`Johnston, et al. Best Current Practice [Page 2]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 2
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` These call flows are based on the current version 2.0 of SIP in RFC
` 3261 [1] with SDP usage described in RFC 3264 [2]. Other RFCs also
` comprise the SIP standard but are not used in this set of basic call
` flows.
`
` Call flow examples of SIP interworking with the PSTN through gateways
` are contained in a companion document, RFC 3666 [5].
`
` 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 [4].
`
`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 [1] and [3].
`
` 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 TCP, TLS, and UDP for transport. See the discussion
` in RFC 3261 for details on the transport issues for SIP.
`
`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. */
`
`Johnston, et al. Best Current Practice [Page 3]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 3
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`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 basic 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 HTTP 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 alice@atlanta.example.com 192.0.2.101
` User Agent Bob bob@biloxi.example.com 192.0.2.201
` User Agent bob@chicago.example.com 192.0.2.100
` Proxy Server ss1.atlanta.example.com 192.0.2.111
` Proxy/Registrar ss2.biloxi.example.com 192.0.2.222
` Proxy Server ss3.chicago.example.com 192.0.2.233
` ALG alg1.atlanta.example.com 192.0.2.128
`
`2. SIP Registration
`
` Registration binds a particular device Contact URI with a SIP user
` Address of Record (AOR).
`
`Johnston, et al. Best Current Practice [Page 4]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 4
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`2.1. Successful New Registration
`
` Bob SIP Server
` | |
` | REGISTER F1 |
` |------------------------------>|
` | 401 Unauthorized F2 |
` |<------------------------------|
` | REGISTER F3 |
` |------------------------------>|
` | 200 OK F4 |
` |<------------------------------|
` | |
`
` Bob sends a SIP REGISTER request to the SIP server. The request
` includes the user’s contact list. This flow shows the use of HTTP
` Digest for authentication using TLS transport. TLS transport is used
` due to the lack of integrity protection in HTTP Digest and the danger
` of registration hijacking without it, as described in RFC 3261 [1].
` The SIP server provides a challenge to Bob. Bob enters her/his valid
` user ID and password. Bob’s SIP client encrypts the user information
` according to the challenge issued by the SIP server and sends the
` response to the SIP server. The SIP server validates the user’s
` credentials. It registers the user in its contact database and
` returns a response (200 OK) to Bob’s SIP client. The response
` includes the user’s current contact list in Contact headers. The
` format of the authentication shown is HTTP digest. It is assumed
` that Bob has not previously registered with this Server.
`
` Message Details
`
` F1 REGISTER Bob -> SIP Server
`
` REGISTER sips:ss2.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` Max-Forwards: 70
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Contact: <sips:bob@client.biloxi.example.com>
` Content-Length: 0
`
`Johnston, et al. Best Current Practice [Page 5]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 5
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` F2 401 Unauthorized SIP Server -> Bob
`
` SIP/2.0 401 Unauthorized
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` ;received=192.0.2.201
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth",
` nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
` opaque="", stale=FALSE, algorithm=MD5
` Content-Length: 0
`
` F3 REGISTER Bob -> SIP Server
`
` REGISTER sips:ss2.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
` Max-Forwards: 70
` From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
` To: Bob <sips:bob@biloxi.example.com>
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 2 REGISTER
` Contact: <sips:bob@client.biloxi.example.com>
` Authorization: Digest username="bob", realm="atlanta.example.com"
` nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
` uri="sips:ss2.biloxi.example.com",
` response="dfe56131d1958046689d83306477ecc"
` Content-Length: 0
`
` F4 200 OK SIP Server -> Bob
`
` SIP/2.0 200 OK
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
` ;received=192.0.2.201
` From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
` To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 2 REGISTER
` Contact: <sips:bob@client.biloxi.example.com>;expires=3600
` Content-Length: 0
`
`Johnston, et al. Best Current Practice [Page 6]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 6
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`2.2. Update of Contact List
`
` Bob SIP Server
` | |
` | REGISTER F1 |
` |------------------------------>|
` | 200 OK F2 |
` |<------------------------------|
` | |
`
` Bob wishes to update the list of addresses where the SIP server will
` redirect or forward INVITE requests.
`
` Bob sends a SIP REGISTER request to the SIP server. Bob’s request
` includes an updated contact list. Since the user already has
` authenticated with the server, the user supplies authentication
` credentials with the request and is not challenged by the server. The
` SIP server validates the user’s credentials. It registers the user
` in its contact database, updates the user’s contact list, and returns
` a response (200 OK) to Bob’s SIP client. The response includes the
` user’s current contact list in Contact headers.
`
` Message Details
`
` F1 REGISTER Bob -> SIP Server
`
` REGISTER sips:ss2.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` Max-Forwards: 70
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Contact: mailto:bob@biloxi.example.com
` Authorization: Digest username="bob", realm="atlanta.example.com",
` qop="auth", nonce="1cec4341ae6cbe5a359ea9c8e88df84f", opaque="",
` uri="sips:ss2.biloxi.example.com",
` response="71ba27c64bd01de719686aa4590d5824"
` Content-Length: 0
`
` F2 200 OK SIP Server -> Bob
`
` SIP/2.0 200 OK
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` ;received=192.0.2.201
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>;tag=34095828jh
`
`Johnston, et al. Best Current Practice [Page 7]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 7
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Contact: <sips:bob@client.biloxi.example.com>;expires=3600
` Contact: <mailto:bob@biloxi.example.com>;expires=4294967295
` Content-Length: 0
`
`2.3. Request for Current Contact List
`
` Bob SIP Server
` | |
` | REGISTER F1 |
` |------------------------------>|
` | 200 OK F2 |
` |<------------------------------|
` | |
`
` Bob sends a register request to the Proxy Server containing no
` Contact headers, indicating the user wishes to query the server for
` the user’s current contact list. Since the user already has
` authenticated with the server, the user supplies authentication
` credentials with the request and is not challenged by the server.
` The SIP server validates the user’s credentials. The server returns
` a response (200 OK) which includes the user’s current registration
` list in Contact headers.
`
` Message Details
`
` F1 REGISTER Bob -> SIP Server
`
` REGISTER sips:ss2.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` Max-Forwards: 70
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Authorization: Digest username="bob", realm="atlanta.example.com",
` nonce="df84f1cec4341ae6cbe5ap359a9c8e88", opaque="",
` uri="sips:ss2.biloxi.example.com",
` response="aa7ab4678258377c6f7d4be6087e2f60"
` Content-Length: 0
`
` F2 200 OK SIP Server -> Bob
`
` SIP/2.0 200 OK
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` ;received=192.0.2.201
`
`Johnston, et al. Best Current Practice [Page 8]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 8
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>;tag=jqoiweu75
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Contact: <sips:bob@client.biloxi.example.com>;expires=3600
` Contact: <mailto:bob@biloxi.example.com>;expires=4294967295
` Content-Length: 0
`
`2.4. Cancellation of Registration
`
` Bob SIP Server
` | |
` | REGISTER F1 |
` |------------------------------>|
` | 200 OK F2 |
` |<------------------------------|
` | |
`
` Bob wishes to cancel their registration with the SIP server. Bob
` sends a SIP REGISTER request to the SIP server. The request has an
` expiration period of 0 and applies to all existing contact locations.
` Since the user already has authenticated with the server, the user
` supplies authentication credentials with the request and is not
` challenged by the server. The SIP server validates the user’s
` credentials. It clears the user’s contact list, and returns a
` response (200 OK) to Bob’s SIP client.
`
` Message Details
`
` F1 REGISTER Bob -> SIP Server
`
` REGISTER sips:ss2.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` Max-Forwards: 70
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Expires: 0
` Contact: *
` Authorization: Digest username="bob", realm="atlanta.example.com",
` nonce="88df84f1cac4341aea9c8ee6cbe5a359", opaque="",
` uri="sips:ss2.biloxi.example.com",
` response="ff0437c51696f9a76244f0cf1dbabbea"
` Content-Length: 0
`
` F2 200 OK SIP Server -> Bob
`
`Johnston, et al. Best Current Practice [Page 9]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 9
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` SIP/2.0 200 OK
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` ;received=192.0.2.201
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>;tag=1418nmdsrf
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Content-Length: 0
`
`2.5. Unsuccessful Registration
`
` Bob SIP Server
` | |
` | REGISTER F1 |
` |------------------------------>|
` | 401 Unauthorized F2 |
` |<------------------------------|
` | REGISTER F3 |
` |------------------------------>|
` | 401 Unauthorized F4 |
` |<------------------------------|
` | |
`
` Bob sends a SIP REGISTER request to the SIP Server. The SIP server
` provides a challenge to Bob. Bob enters her/his user ID and
` password. Bob’s SIP client encrypts the user information according
` to the challenge issued by the SIP server and sends the response to
` the SIP server. The SIP server attempts to validate the user’s
` credentials, but they are not valid (the user’s password does not
` match the password established for the user’s account). The server
` returns a response (401 Unauthorized) to Bob’s SIP client.
`
` Message Details
`
` F1 REGISTER Bob -> SIP Server
`
` REGISTER sips:ss2.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` ;received=192.0.2.201
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` Contact: <sips:bob@client.biloxi.example.com>
` Content-Length: 0
`
`Johnston, et al. Best Current Practice [Page 10]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 10
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` F2 Unauthorized SIP Server -> Bob
`
` SIP/2.0 401 Unauthorized
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
` ;received=192.0.2.201
` From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
` To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 1 REGISTER
` WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth",
` nonce="f1cec4341ae6ca9c8e88df84be55a359",
` opaque="", stale=FALSE, algorithm=MD5
` Content-Length: 0
`
` F3 REGISTER Bob -> SIP Server
`
` REGISTER sips:ss2.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
` Max-Forwards: 70
` From: Bob <sips:bob@biloxi.example.com>;tag=JueHGuidj28dfga
` To: Bob <sips:bob@biloxi.example.com>
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 2 REGISTER
` Contact: <sips:bob@client.biloxi.example.com>
` Authorization: Digest username="bob", realm="atlanta.example.com",
` nonce="f1cec4341ae6ca9c8e88df84be55a359", opaque="",
` uri="sips:ss2.biloxi.example.com",
` response="61f8470ceb87d7ebf508220214ed438b"
` Content-Length: 0
`
` /* The response above encodes the incorrect password */
`
` F4 401 Unauthorized SIP Server -> Bob
`
` SIP/2.0 401 Unauthorized
` Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
` ;received=192.0.2.201
` From: Bob <sips:bob@biloxi.example.com>;tag=JueHGuidj28dfga
` To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
` Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
` CSeq: 2 REGISTER
` WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth",
` nonce="84f1c1ae6cbe5ua9c8e88dfa3ecm3459",
` opaque="", stale=FALSE, algorithm=MD5
` Content-Length: 0
`
`Johnston, et al. Best Current Practice [Page 11]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 11
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`3. SIP Session Establishment
`
` This section details session establishment between two SIP User
` Agents (UAs): Alice and Bob. Alice (sip:alice@atlanta.example.com)
` and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or
` SIP-enabled devices. The successful calls show the initial
` signaling, the exchange of media information in the form of SDP
` payloads, the establishment of the media session, then finally the
` termination of the call.
`
` HTTP Digest authentication is used by Proxy Servers to authenticate
` the caller Alice. It is assumed that Bob has registered with Proxy
` Server Proxy 2 as per Section 2 to be able to receive the calls via
` the Proxy.
`
`3.1. Successful Session Establishment
`
` Alice Bob
` | |
` | INVITE F1 |
` |----------------------->|
` | 180 Ringing F2 |
` |<-----------------------|
` | |
` | 200 OK F3 |
` |<-----------------------|
` | ACK F4 |
` |----------------------->|
` | Both Way RTP Media |
` |<======================>|
` | |
` | BYE F5 |
` |<-----------------------|
` | 200 OK F6 |
` |----------------------->|
` | |
`
` In this scenario, Alice completes a call to Bob directly.
`
` Message Details
`
` F1 INVITE Alice -> Bob
`
` INVITE sip:bob@biloxi.example.com SIP/2.0
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
` Max-Forwards: 70
` From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` To: Bob <sip:bob@biloxi.example.com>
`
`Johnston, et al. Best Current Practice [Page 12]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 12
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 INVITE
` Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
` Content-Type: application/sdp
` Content-Length: 151
`
` v=0
` o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
` s=-
` c=IN IP4 192.0.2.101
` t=0 0
` m=audio 49172 RTP/AVP 0
` a=rtpmap:0 PCMU/8000
`
` F2 180 Ringing Bob -> Alice
`
` SIP/2.0 180 Ringing
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
` ;received=192.0.2.101
` From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 INVITE
` Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
` Content-Length: 0
`
` F3 200 OK Bob -> Alice
`
` SIP/2.0 200 OK
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
` ;received=192.0.2.101
` From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 INVITE
` Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
` Content-Type: application/sdp
` Content-Length: 147
`
` v=0
` o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
` s=-
` c=IN IP4 192.0.2.201
` t=0 0
` m=audio 3456 RTP/AVP 0
` a=rtpmap:0 PCMU/8000
`
`Johnston, et al. Best Current Practice [Page 13]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 13
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` F4 ACK Alice -> Bob
`
` ACK sip:bob@client.biloxi.example.com SIP/2.0
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
` Max-Forwards: 70
` From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 ACK
` Content-Length: 0
`
` /* RTP streams are established between Alice and Bob */
`
` /* Bob Hangs Up with Alice. Note that the CSeq is NOT 2, since
` Alice and Bob maintain their own independent CSeq counts.
` (The INVITE was request 1 generated by Alice, and the BYE is
` request 1 generated by Bob) */
`
` F5 BYE Bob -> Alice
`
` BYE sip:alice@client.atlanta.example.com SIP/2.0
` Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
` Max-Forwards: 70
` From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
` To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 BYE
` Content-Length: 0
`
` F6 200 OK Alice -> Bob
`
` SIP/2.0 200 OK
` Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
` ;received=192.0.2.201
` From: Bob <sip:bob@biloxi.example.com>;tag=8321234356
` To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 BYE
` Content-Length: 0
`
`Johnston, et al. Best Current Practice [Page 14]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 14
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
`3.2. Session Establishment Through Two Proxies
`
` Alice Proxy 1 Proxy 2 Bob
` | | | |
` | INVITE F1 | | |
` |--------------->| | |
` | 407 F2 | | |
` |<---------------| | |
` | ACK F3 | | |
` |--------------->| | |
` | INVITE F4 | | |
` |--------------->| INVITE F5 | |
` | 100 F6 |--------------->| INVITE F7 |
` |<---------------| 100 F8 |--------------->|
` | |<---------------| |
` | | | 180 F9 |
` | | 180 F10 |<---------------|
` | 180 F11 |<---------------| |
` |<---------------| | 200 F12 |
` | | 200 F13 |<---------------|
` | 200 F14 |<---------------| |
` |<---------------| | |
` | ACK F15 | | |
` |--------------->| ACK F16 | |
` | |--------------->| ACK F17 |
` | | |--------------->|
` | Both Way RTP Media |
` |<================================================>|
` | | | BYE F18 |
` | | BYE F19 |<---------------|
` | BYE F20 |<---------------| |
` |<---------------| | |
` | 200 F21 | | |
` |--------------->| 200 F22 | |
` | |--------------->| 200 F23 |
` | | |--------------->|
` | | | |
`
` In this scenario, Alice completes a call to Bob using two proxies
` Proxy 1 and Proxy 2. The initial INVITE (F1) contains a pre-loaded
` Route header with the address of Proxy 1 (Proxy 1 is configured as a
` default outbound proxy for Alice). The request does not contain the
` Authorization credentials Proxy 1 requires, so a 407 Proxy
` Authorization response is sent containing the challenge information.
` A new INVITE (F4) is then sent containing the correct credentials and
` the call proceeds. The call terminates when Bob disconnects by
` initiating a BYE message.
`
`Johnston, et al. Best Current Practice [Page 15]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 15
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` Proxy 1 inserts a Record-Route header into the INVITE message to
` ensure that it is present in all subsequent message exchanges. Proxy
` 2 also inserts itself into the Record-Route header. The ACK (F15)
` and BYE (F18) both have a Route header.
`
` Message Details
`
` F1 INVITE Alice -> Proxy 1
`
` INVITE sip:bob@biloxi.example.com SIP/2.0
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
` Max-Forwards: 70
` Route: <sip:ss1.atlanta.example.com;lr>
` From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` To: Bob <sip:bob@biloxi.example.com>
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 INVITE
` Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
` Content-Type: application/sdp
` Content-Length: 151
`
` v=0
` o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
` s=-
` c=IN IP4 192.0.2.101
` t=0 0
` m=audio 49172 RTP/AVP 0
` a=rtpmap:0 PCMU/8000
`
` /* Proxy 1 challenges Alice for authentication */
`
` F2 407 Proxy Authorization Required Proxy 1 -> Alice
`
` SIP/2.0 407 Proxy Authorization Required
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
` ;received=192.0.2.101
` From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
` To: Bob <sip:bob@biloxi.example.com>;tag=3flal12sf
` Call-ID: 3848276298220188511@atlanta.example.com
` CSeq: 1 INVITE
` Proxy-Authenticate: Digest realm="atlanta.example.com", qop="auth",
` nonce="f84f1cec41e6cbe5aea9c8e88d359",
` opaque="", stale=FALSE, algorithm=MD5
` Content-Length: 0
`
`Johnston, et al. Best Current Practice [Page 16]
`
`AT&T Exhibit 1037
`AT&T v. VoIP, IPR 2017-01382
`Page 16
`
`

`

`
`RFC 3665 SIP Basic Call Flow Examples December 2003
`
` F3 ACK Alice -> Proxy 1
`
` ACK sip:bob@biloxi.example.com SIP/2.0
` Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
` Max-Forwards: 70
` From: Alice <sip:alice@atl

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket