1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1 2CONTENTS
31 42 5 6 73 8 9 104 11 12 13 14 155 166 17 18 19 20 21 22 23 24 25 26 27 28 29 30

IMS/MMD Call Flow Examples

Introduction Glossary and Definitions

1 2

2.1 Acronyms.......................................................................................................................................2 2.2 Definitions.....................................................................................................................................2 References 3

3.1 Normative References....................................................................................................................3 3.2 Informative References..................................................................................................................3 Methodology 4

4.1 Functional Entities covered by call flows......................................................................................4 4.2 Identities.........................................................................................................................................4 4.2.1 User and Network Identities...........................................................................................4 4.3 Notation for call flows...................................................................................................................5 Registration Procedures Signaling flows for session establishment 5 6

6.1 General assumptions......................................................................................................................6 6.2 Scenarios........................................................................................................................................6 6.2.1 Scenario 1.......................................................................................................................7 6.2.1.1 Assumptions..................................................................................................7 6.2.1.2 Call Flow.......................................................................................................7 6.2.2 Scenario 2.....................................................................................................................12 6.2.2.1 Assumptions................................................................................................12 6.2.2.2 Call Flow.....................................................................................................12 6.2.3 Scenario 3.....................................................................................................................13 6.2.3.1 Assumptions................................................................................................13 6.2.3.2 Call flow......................................................................................................13 6.2.4 Scenario 4.....................................................................................................................20 6.2.4.1 Assumptions................................................................................................20 6.2.4.2 Call flow......................................................................................................20 (Informative): VoIP example with QoS reservation, activation, and updating at RAN 28 28 30 31 32

31Appendix A 32A.1 33A.2 34A.3 35A.4

QoS Configuration for VoIP in advance Resource activation on originating side Resource activation on terminating side Updating of resource reservation

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1A.4.1 2A.4.1 3

Resource updating on originating side Resource updating on terminating side

32 34

ii

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1LIST

OF FIGURES
7 12 14 21 29 30 31 33 34

2Figure 1 Originating UE resource ready, terminating UE resource ready 3Figure 2 Originating UE resource ready, terminating UE resource not ready 4Figure 3 Originating UE not ready, Terminating UE ready 5Figure 4 Originating UE not ready, Terminating UE not ready 6Figure 5 QoS configuration for VoIP 7Figure 6 QoS Activation on Originating UE 8Figure 7 QoS Activation on Terminating UE 9Figure 8 Resource Updating on Originating UE 10Figure 9 Resource Updating on Terminating UE 11

iii

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1Revision 2 Revision
v1.0
3 4

History
Changes
Initial Publication

Date
December, 2007

iv

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

11
2 3 4 5 6 7 8 9

Introduction
The document provides examples of signaling flows for the IP multimedia call control based on SIP and SDP. The signaling flows specified in this document are only for informational purposes. If there is ambiguity between this specification and [1], the text specified in [1] shall be followed. The call flows describe the behavior of the mobile stations under various conditions for setting up real time services like VoIP and PSVT. In this document, several key words are used to signify the requirements. The key words shall, shall not, should, should not and may are to be interpreted as described in [6] and the TIA Engineering Style Manual.

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

12 2
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Glossary and Definitions

2.1 Acronyms
AAA AN AT EMPA HRPD HSS IMS IP IP-CAN MMD MPA PDSN PFO PPP PSVT QoS RAN RSVP SBBC SDP SIP TFT UDP UE VoIP Authentication, Authorization, and Accounting Access Network Access Terminal Enhanced Multi-Flow Packet Application High Rate Packet Data Home Subscriber Server IP Multimedia Subsystem Internet Protocol IP-Connectivity Access Network Multi Media Domain Multi-Flow Packet Application Packet Data Serving Node PPP Free Operation Point to Point Protocol Packet Switched Video Telephony Quality of Service Radio Access Network Resource ReSerVation Protocol Service Based Bearer Control Session Description Protocol Session Initiation Protocol Traffic Flow Template User Datagram Protocol User Equipment Voice Over IP

28
29 30 31 32 33

2.2

Definitions
Caller Called party Alert Ring Back The person placing a call The recipient or destination of a call The audible notification given to the Called party of an incoming call. The audible notification given to a Caller to indicate that the Called party has been located and is being alerted

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

13
2 3

References
The following documents contain provisions, which, through reference in this text, constitute provisions of this document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP2 document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

4
5

6 7
8 9

10
11 12 13 14 15 16 17 18 19 20 21 22 23 24

3.1

Normative References
[1] [2] [3] [4] [5] [6] [7] 3GPP2 X.S0013-004-A v1.0: IP Multimedia Call Control Protocol Based on SIP and SDP Stage 3. 3GPP2 X.S0013-002-A v1.0: IP Multimedia (IM) Subsystem Stage 2. IETF RFC 2429, RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+). IETF RFC 3558, RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV). IETF RFC 3262, Reliability of provisional Responses in the Session Initiation Protocol (SIP) IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, March 1997. 3GPP2 X.S0013-005-A v1.0: All-IP Core Network Multimedia Domain IP Multimedia Subsystem Cx Interface Signaling flows and Message Contents Annex A.

25
26 27 28 29

3.2
[8]

Informative References
3GPP2 X.S0013-012-0 v1.0: All-IP Core Network Multimedia Domain; Service Based Bearer Control Stage 2.

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

14 2
3 4

Methodology
4.1 Functional Entities covered by call flows
User Equipment (UE) Proxy-CSCF (P-CSCF) Interrogating-CSCF (I-CSCF) Serving-CSCF (S-CSCF)

The flows show the signaling exchanges between the following functional entities:

5 6 7 8

9 10 11 12

The call flows mainly show the interactions between the UE-1 and UE-2 for call origination and termination. The procedures and the message exchanged between these elements are as described in [1].

13 14 4.2.1
15 16 17 18 19

4.2

Identities
User and Network Identities
The public identity of UE-1 is sip:UE-1@domain1.net. The public identity of UE-2 is sip:UE2@domain2.net The following are network entities associated with UE-1: Home Domain of UE-1: domain1.net P-CSCF serving UE-1: p-cscf1.domain1.net I-CSCF serving UE-1: i-cscf1.domain1.net S-CSCF serving UE-1: s-cscf1.domain1.net

20 21 22 23

24 25

The following are the network entities associated with UE-2: Home Domain of UE-2: domain2.net P-CSCF serving UE-2: p-cscf2.domain2.net I-CSCF serving UE-2: i-cscf2.domain2.net S-CSCF serving UE-2: s-cscf2.domain2.net

26 27 28 29
30 31 32 33 34 35 36

In the example session establishment flows, both UE-1 and UE-2 are assumed to be in the home network. So, the P-CSCF1 and P-CSCF2 are in UE-1s and UE-2s respective home networks. However, according to [2], the P-CSCF can be either in the home or visited network. The session establishment call flows described in this document are not affected whether the P-CSCF is in the visited or home network. For brevity, I-CSCF and S-CSCF are shown together in the session establishment call flows.

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

4.3

Notation for call flows

2Offer/Answer exchange process is also shown in the call flows. For brevity, the following notation is used to 3represent offer and answer: 4 O and A in the call flows represent Offer and Answer. 5 On represents the nth SDP offer. For example, if there are two offer/answer exchanges during the call 6 setup process, then the first offer will be noted as O1 and the second as O2. 7 An represents the nth SDP Answer. Answer An corresponds to Offer On. 8 9 10 11

125
13 14 15 16 17

Registration Procedures
The registration procedures for UE-1 and UE-2 are as specified in [1] and [7]. UE-1 registers with SCSCF1 through P-CSCF1 and UE-2 registers with S-CSCF2 through P-CSCF2.

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

26

Signaling flows for session establishment

3In all of the call flows provided in this document, registration procedures are assumed to have already been 4completed. 5

6 8

6.1

General assumptions

7All the call flows shown in this document assume the following: The originating UE and the terminating UE both support precondition and reliable provisional responses 9 100 (rel). 10 The originating UE will only include Supported: precondition in the SIP INVITE it sends out to its peer. 11 o If the originating UE wishes to both send and receive media with its peer, and the resources are 12 reserved for the stream, the originating UE marks the stream as sendrecv using the a=sendrecv 13 attribute. (Note: for sendonly streams, the originating UE marks the stream as a=sendonly and 14 for recvonly streams, the originating UE marks the stream as a=recvonly). 15 o If the originating UE wishes to communicate with its peer, and the resources are not reserved for 16 the stream, the originating UE marks the particular stream as inactive using the a=inactive 17 attribute. 18 If the Supported header in the incoming INVITE includes precondition and the terminating UE decides 19 to use precondition, the terminating UE includes Require: precondition in all reliable responses that carry 20 SDP (i.e., offer or answer). 21 The terminating UE sends 180 (Ringing) response reliably. Note that sending the 180 (Ringing) response 22 reliably does not increase the call setup time experienced by the caller. 23 If the 180 (Ringing) response contains an answer (or offer), the called party is alerted only after receiving a 24 PRACK request for the 180 (Ringing) response. This enhances the caller/called party user experience. For 25 example, if the called party picks up the phone before the 180 (Ringing) response reaches the caller, the 26 caller will only be able to hear the called party but will not be able to respond, 27 Both UEs have the required resources ready before the terminating UE can alert the called party of an 28 incoming call. 29 For brevity, 100 (Trying) messages are not shown in the figures. 30 The SBBC interactions [8] are not shown in the call flows. 31

32 34

6.2

Scenarios

33The following scenarios are considered for the session establishment process: Scenario 1: Originating UE has resources ready before sending INVITE, terminating UE has resources 35 ready before sending the first provisional response; 36 Scenario 2: Originating UE has resources ready before sending INVITE, terminating UE does not have 37 resources ready before sending the first provisional response; 38 Scenario 3: Originating UE does not have resources ready before sending INVITE, terminating UE has 39 resources ready before sending the first provisional response; 40 Scenario 4: Originating UE does not have resources ready before sending INVITE, terminating UE does 41 not have resources ready before sending the first provisional response. 42 43The call flows for the above four scenarios are depicted in the subsequent subsections.

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1 6.2.1

Scenario 1

2This section covers the scenario where the originating UEs resources are ready before sending INVITE, and the 3terminating UEs resources are ready before sending the first provisional response. 4 6.2.1.1 5 6 6.2.1.2 7 8 9 10 11 12

Assumptions

Call Flow The following section applies to the case where UE-1 has its resource ready before sending the INVITE request to UE-2. The terminating UE, UE-2, also has its resource ready before answering the INVITE request with the first provisional response. Note: This flow assumes UE-2 has sufficient resources available prior to receiving the INVITE.

13
14

Figure 1 Originating UE resource ready, terminating UE resource ready

15 161. INVITE (UE-1 to P-CSCF1) 17UE-1 determines the set of codecs or media streams that it wishes to support for the session. It builds an SDP offer 18containing characteristics of each codec, and assigns local port numbers for each possible media flow. Multiple 19media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices 20offered. 21 22For this example, it is assumed that UE-1 is willing to establish a multimedia session comprising a video stream and 23an audio stream. The video stream supports one H.263 codec as specified in [3]. The audio stream supports both 24EVRC and SMV codecs as specified in [4]. 25 26In addition, UE-1 indicates that precondition is supported for this session. In the SDP offer, it indicates that resource 27is already available at the local end point.

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

Table 6.2.1.2-1 INVITE (UE-1 to P-CSCF1)

INVITE sip:UE-2@domain2.net SIP/2.0 From: <sip:UE-1@domain1.net>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@domain2.net> Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 CSeq: 1 INVITE Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348 Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>, <sip:scscf1.domain1.net;lr> P-Preferred-Identity: "User-1" <sip:UE-1@domain1.net> P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411 Privacy: none Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=98765432; spi-s=76543210; port-c=13579; port-s=23456 Contact: <sip:UE-1@10.20.1.100:1357;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Supported: 100rel, precondition Content-Type: application/sdp Content-Length: xxx v=0 o=- 3323527065117000 3323527065117000 IN IP4 10.20.1.100 s=c=IN IP4 10.20.1.100 t=0 0 m=audio 49500 RTP/AVP 97 99 b=AS:25.4 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 a=rtpmap:99 SMV/8000 m=video 49600 RTP/AVP 34 b=AS:75 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

2 32. INVITE (P-CSCF1 to I/S-CSCF1) 4The P-CSCF1 adds itself to the Record-Route header and Via header. As the request is forwarded to an interface that 5is not compressed, the P-CSCF1 SIP URI does not contain the "comp=sigcomp" parameter. The P-CSCF1 removes 6the Security-Verify header and associated "sec-agree" option-tags prior to forwarding the request. As the Require 7and Proxy-Require headers are empty, P-CSCF1 removes those headers completely. 8 9The INVITE request is forwarded to the I/S-CSCF1. 10 113. INVITE (I/S-CSCF1 to I/S-CSCF2) 12S-CSCF1 performs an analysis of the destination address, and determines the network operator to whom the 13destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration 14hidden, S-CSCF1 forwards the INVITE request directly to I-CSCF2 in the destination network. 15 16The I-CSCF2 sends a query to the HSS to find out the S-CSCF2 of the called user. The HSS responds with the

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1address of the current S-CSCF2 for the terminating subscriber. I-CSCF2 forwards the INVITE request to the S2CSCF2 that will handle the session termination. S-CSCF2 validates the service profile of this subscriber and 3evaluates the initial filter criteria. 4 54-5. INVITE (I/S-CSCF2 to UE-2) 6S-CSCF2 forwards the INVITE request to UE-2 via P-CSCF2. 7 86. 180 Ringing (UE-2 to P-CSCF2) 9UE-2 has accepted both video and audio streams, and EVRC is the chosen codec for the audio stream. Since 10resources are already available for UE-2, it sends a 180 (Ringing) response reliably with the SDP answer indicating 11that resources are reserved at both endpoints. 12 137-10. 180 Ringing (P-CSCF2 to UE-1) 14P-CSCF2 forwards the 180 (Ringing) response to UE-1 via I/S-CSCF2, I/S-CSCF1, and P-CSCF1. Table 6.2.1.2-2 15shows the 180 (Ringing) response in detail. 16 17

Table 6.2.1.2-2 180 Ringing (P-CSCF1 to UE-1)

SIP/2.0 180 Ringing From: <sip:UE-1@domain1.net>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@domain2.net>;tag=169f7f8-0-13c4-9f6-33835972-9f6 Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 CSeq: 1 INVITE Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348 Record-Route:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>,<sip:scscf1.domain1.net;lr>, <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Contact: <sip:UE-2@10.30.1.24:8805;comp=sigcomp> P-Asserted-Identity: "User 2" <sip:UE-2@domain2.net>, <tel:+1-858-335-7341> Privacy: none Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Require: 100rel, precondition RSeq: 1000 Content-Type: application/sdp Content-Length: xxx v=0 o=- 33235270718000 33235270718000 IN IP4 10.30.1.24 s=c=IN IP4 10.30.1.24 t=0 0 m=audio 49700 RTP/AVP 97 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 m=video 49702 RTP/AVP 34 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

18 19 2011. PRACK (UE-1 to P-CSCF1) 21UE-1 acknowledges the 180 (Ringing) response from UE-2 with a PRACK request as specified in [5]. (Table 226.2.1.2-3) 23

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1If UE-1 determines to make any change in media flows, it includes a new SDP offer in the PRACK request sent to 2UE-2. Otherwise, no SDP offer is included in the PRACK request. 3 4

Table 6.2.1.2-3 PRACK (UE-1 to P-CSCF1)

PRACK sip:UE-2@10.30.1.24:8805;comp=sigcomp SIP/2.0 From: <sip:UE-1@domain1.net>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@domain2.net>; tag=169f7f8-0-13c4-9f6-33835972-9f6 Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 P-Access-Network-Info: 3GPP2-1X-HRPD;ci-3gpp2=1234123412341234123412341234123411 CSeq: 2 PRACK Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348 Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>,<sip:scscf2.d omain2.net;lr>, <sip:pcscf2.domain2.net;lr> RAck: 1000 1 INVITE Content-Length: 0

5 612. PRACK (P-CSCF1 to I/S-CSCF1) 7The P-CSCF forwards the PRACK request to S-CSCF. As the Proxy-Require header is empty, the P-CSCF removes 8this header completely. 9 1013-14. PRACK (I/S-CSCF1 to P-CSCF2) 11The I/S-CSCF1 forwards the PRACK request to P-CSCF2 via I/S-CSCF2. 12 1315. PRACK (P-CSCF2 to UE-2) 14UE-2 starts alerting the user after it receives the PRACK request for the 180 (Ringing) response. UE-2 may also 15alert the user before receiving the PRACK request, but there may be media clipping if the user answers the call 16before the 180 (Ringing) response reaches UE-1. 17 1816. 200 OK (UE-2 to P-CSCF2) 19The 200 OK response is generated by UE-2 to acknowledge the reception of the PRACK request. 20 2117-20. 200 OK (P-CSCF2 to UE-1) 22The P-CSCF2 forwards the 200 OK response to UE-1 via I/S-CSCF2, I/S-CSCF1, and P-CSCF1. Table 6.2.1.2-4 23shows the 200 OK message going from P-CSCF1 to UE-1. 24 25

Table 6.2.1.2-4 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK From: <sip:UE-1@domain1.net>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@domain2.net>;tag=169f7f8-0-13c4-9f6-33835972-9f6 Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 CSeq: 2 PRACK Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348 Content-Length: 0

26 2721. 200 OK (UE-2 to P-CSCF2) 28When the user at UE-2 answers the call, UE-2 generates a 200 OK response towards UE-1 to answer the INVITE 29request. 30 3122-25. 200 OK (P-CSCF2 to UE-1) 32The P-CSCF2 forwards the 200 OK response to UE-1 via I/S-CSCF2, I/SCSCF1, and P-CSCF1. Table 6.2.1.2-5 33shows the 200 OK message going from P-CSCF1 to UE-1.

10

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

Table 6.2.1.2-5 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK From: <sip:UE-1@domain1.net>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@domain2.net>;tag=169f7f8-0-13c4-9f6-33835972-9f6 Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 CSeq: 1 INVITE Record-Route:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>,<sip:scscf1.domain1.net;lr>, <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Via: SIP/2.0/UDP 10.20.1.100:1357;comp=sigcomp;branch=z9hG4bK-78f-1d86b6-24d29348 Contact: <sip:UE-2@10.30.1.24:8805;comp=sigcomp> Content-Length: 0

2 326. ACK (UE-1 to P-CSCF1) 4UE responds to the 200 OK with an ACK request sent to P-CSCF1. (Table 6.2.1.2-6). 5 6
ACK sip:UE-2@10.30.1.24:8805;comp=sigcomp SIP/2.0 From: <sip:UE-1@domain1.net>;tag=169f498-0-13c4-78e-2044f20e-78e To: <sip:UE-2@domain2.net>;tag=169f7f8-0-13c4-9f6-33835972-9f6 Call-ID: 16a1b80-0-13c4-78e-6a540802-78e@10.20.1.100 CSeq: 1 ACK Via: SIP/2.0/UDP 10.20.1.100:5060;comp=sigcomp;branch=z9hG4bK-792-1d9290-49ff0c31 Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>, <sip:scscf2.domain2.net;lr>, <sip:pcscf2.domain2.net;lr> Content-Length: 0

Table 6.2.1.2-6 ACK (UE-1 to P-CSCF1)

827-30. ACK (P-CSCF1 to UE-2) 9The P-CSCF1 forwards the ACK response to UE-2 via I/S-CSCF1, I/S-CSCF2, and P-CSCF2.

11

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

2 6.2.2

Scenario 2

3This section covers the scenario where the originating UEs resources are ready before sending INVITE, and the 4terminating UEs resources are not ready before sending the first provisional response 5 6 6.2.2.1 7 8 6.2.2.2

Assumptions

Call Flow

9This scenario assumes that the terminating UE, UE-2, does not have the resource ready before sending the first 10provisional response. UE-2 may send a 183 (Session Progress) response unreliably. At the same time, UE-2 also 11starts the resource reservation process. Once the resource is ready at UE-2 side, the UE-2 sends 180 (Ringing) 12response reliably to UE-1, including an SDP answer to indicate that the resource is ready. The SDP offer/answer 13exchanges are the same as those in Scenario 1. 14

15
16

Figure 2 Originating UE resource ready, terminating UE resource not ready

12

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

2 6.2.3

Scenario 3

3This section covers the scenario where the originating UEs resources are not ready before sending INVITE, and 4terminating UEs resources are ready before sending the first provisional response. 5 6.2.3.1

Assumptions

6The call flow in this section assumes that the originating UE, UE-1, has resources ready before sending the PRACK 7request to the first provisional response. In case UE-1s resources are not ready before sending the PRACK request 8for the first provisional response (183), then UE-1 needs to send an UPDATE request to UE-2 to indicate that 9resources are ready, after the resource reservation is completed. 10 11 6.2.3.2

Call flow

12The following section applies to the case where UE-1 has no resource reserved before sending the initial INVITE 13request to UE-2. 14 15

13

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1
2 3 41-5. INVITE (UE-1 to P-CSCF1) 5UE-1 determines the set of codecs or media streams that it wishes to support for the session. It builds a SDP 6containing characteristics of each codec, and assigns local port numbers for each possible media flow. Multiple 7media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices 8offered. 9 10For this example, it is assumed that UE-1 desires to establish a multimedia session comprising a video stream and an 11audio stream. The video stream supports one H.263 codec. The audio stream supports both EVRC and SMV codec. 12 13UE-1 does not indicate that precondition is required for this session, but indicates that it is supported. (This approach 14optimizes compatibility and performance when interworking with 3 rd party (non-MMD) terminals). In the SDP body, 15UE-1 indicates the current resource status and that the desired resource status is optional. UE-1 also sets every media 16stream to inactive mode by using the a=inactive SDP attribute in the SDP offer. Detecting the QoS precondition 17content in the SDP, UE-2 indicates resource reservation, but the session can continue regardless of whether or not 18this reservation is possible. 19 20UE-1 does not indicate that reliable provisional responses are required, but indicates that they are supported. This 21gives UE-2 the ability to reliably send only those responses that are most appropriate.

Figure 3 Originating UE not ready, Terminating UE ready

14

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1 2

Table 6.2.3.2-7 INVITE (UE-1 to P-CSCF1)

INVITE sip:UE-2@domain2.net SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag= a48s To: <sip:UE-2@domain2.net> Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>, <sip:scscf1.domain1.net;lr> P-Preferred-Identity: "User-1" <sip:UE-1@domain1.net> P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411 Privacy: none Contact: <sip:UE-1@100.200.1.1:1357;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Require: sec-agree Proxy-Require: sec-agree Supported: 100rel, precondition Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=9876543; spi-s=3456789; port-c=8642; port-s=7531 Content-Type: application/sdp Content-Length: xxx v=0 o=- 2987935614 2987935614 IN IP4 100.200.1.1 s=c=IN IP4 100.200.1.1 t=0 0 m=audio 10500 RTP/AVP 97 99 b=AS:25.4 a=inactive a=curr:qos local none a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 a=rtpmap:99 SMV/8000 m=video 10600 RTP/AVP 34 b=AS:75 a=inactive a=curr:qos local none a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

3 46-10. 183 (P-CSCF1 to UE-1) 5UE-2 accepts both video and audio streams, and chooses EVRC as the codec for the audio stream. An SDP answer is 6included to assist UE-1 in completing resource reservation as early as possible. The SDP answer includes 7precondition status. 8

15

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

Table 6.2.3.2-8 183 Session Progress (P-CSCF1 to UE-1)

SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch= z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE Record-Route:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>, <sip:scscf1.domain1.net;lr>,<sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Contact: <sip:UE-2@100.300.1.2:2345;comp=sigcomp> P-Asserted-Identity: "User 2" <sip:UE-2@domain2.net>, <tel:+1-972-321-9876> Privacy: none Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Require: 100rel, precondition RSeq: 1000 Content-Type: application/sdp Content-Length: xxx v=0 o=- 35270718123 35270718123 IN IP4 100.300.1.2 s=c=IN IP4 100.300.1.2 t=0 0 m=audio 10700 RTP/AVP 97 b=AS:25.4 a=inactive a=curr:qos local sendrecv a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=conf:qos remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 m=video 10702 RTP/AVP 34 b=AS:75 a=inactive a=curr:qos local sendrecv a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=conf:qos remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

2 311-15. PRACK (UE-1 to P-CSCF1) 4UE-1 acknowledges the 183 (Session Progress) response from UE-2 with a PRACK request. Resource reservation at 5UE-1 is assumed to have been completed at some point prior to sending the PRACK request. The local resource 6status is included in the SDP offer. 7 8

16

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

Table 6.2.3.2-3 PRACK (UE-1 to P-CSCF1)

PRACK sip:UE-2@100.300.1.2:2345;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411 CSeq: 2 PRACK Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>, <sip:scscf2.domain2.net;lr>, <sip:pcscf2.domain2.net;lr> Require: precondition RAck: 1000 1 INVITE Content-Type: application/sdp Content-Length: xxx v=0 o=- 2987935614 2987935615 IN IP4 100.200.1.1 s=c=IN IP4 100.200.1.1 t=0 0 m=audio 10500 RTP/AVP 97 b=AS:25.4 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 m=video 10600 RTP/AVP 34 b=AS:75 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

2 3 416-20. 200 OK (P-CSCF1 to UE-1) 5The 200 OK response is generated by UE-2 to acknowledge the reception of the PRACK request. UE-2 has 6completed resource reservation for both video and audio streams. The response will include an SDP answer to 7reflect successful resource reservation.

17

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

Table 6.2.3.2-4 - 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 2 PRACK Require: precondition Content-Length: xxx v=0 o=- 35270718123 35270718124 IN IP4 100.300.1.2 s=c=IN IP4 100.300.1.2 t=0 0 m=audio 10700 RTP/AVP 97 b=AS:25.4 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 m=video 10702 RTP/AVP 34 b=AS:75 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

2 321-25. 180 Ringing (P-CSCF1 to UE-1) 4UE-2 generates a 180 (Ringing) response to UE-1 and sends it reliably. UE-2 also alerts the called user of the 5incoming call. 6 7

Table 6.2.3.2-5 - 180 Ringing (P-CSCF1 to UE-1)

SIP/2.0 180 Ringing Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch= z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE Record-Route:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>, <sip:scscf1.domain1.net;lr>,<sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Contact: <sip:UE-2@100.300.1.2:2345;comp=sigcomp> P-Asserted-Identity: "User 2" <sip:UE-2@domain2.net>, <tel:+1-972-321-9876> Privacy: none Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Require: 100rel RSeq: 1001 Content-Length: 0

8 926-30. PRACK (UE-1 to P-CSCF1) 10UE-1 acknowledges the 180 (Ringing) response from UE-2 with a PRACK request. 11

18

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

Table 6.2.3.2-6 - PRACK (UE-1 to P-CSCF1)

PRACK sip:UE-2@100.300.1.2:2345;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411 CSeq: 3 PRACK Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>, <sip:scscf2.domain2.net;lr>, <sip:pcscf2.domain2.net;lr> RAck: 1001 1 INVITE Content-Length: 0

2 3 431-35. 200 OK (P-CSCF1 to UE-1) 5The 200 OK response is generated by UE-2 to acknowledge the reception of the PRACK request. 6

Table 6.2.3.2-7 - 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 3 PRACK Content-Length: 0

7 836-40. 200 OK (P-CSCF1 to UE-1) 9When the user at UE-2 answers the call, UE-2 generates a 200 OK response towards UE-1 to answer the INVITE 10request. 11

Table 6.2.3.2-8 - 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE RecordRoute:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>,<sip:scscf1.domain1.net; lr>, <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Contact: <sip:UE-2@100.300.1.2:2345;comp=sigcomp> Content-Length: 0

12 1341-45. ACK (UE-1 to P-CSCF1) 14UE-1 sends an ACK request in response to the 200 OK response from UE-2. 15

Table 6.2.3.2-9 - ACK (UE-1 to P-CSCF1)

ACK sip:UE-2@100.300.1.2:2345;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 ACK Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>, <sip:scscf2.domain2.net;lr>, <sip:pcscf2.domain2.net;lr> Content-Length: 0

19

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

2 6.2.4
3 4 5 6

Scenario 4

This section covers the scenario where the originating UEs resources are not ready before sending INVITE, and the terminating UEs resources are not ready before sending the first provisional response. Assumptions This scenario assumes that the originating UE, UE-1, completes resource reservation before, or shortly after, the arrival of the 183 (Session Progress) response from UE-2, and that the terminating UE completes local resource reservation prior to sending 180 (Ringing) message. In case the originating UE, UE-1, has not completed its resource reservation before sending the PRACK request to the first provisional response (183), the UE-1 needs to send an UPDATE request to indicate resource ready once it completes the resource reservation. Otherwise , if the terminating UE, UE-2, cannot finish resource reservation before the offer/answer wherein the UE-1 indicates resources are ready, UE-2 can send a 180 (Ringing) response as soon as its resources are reserved without going through further offer/answer exchanges. Note: The UE-1/UE-2 may start reservation anytime after it sends/receives the initial INVITE. Call flow

7 6.2.4.1 8 9 10 11 12 13 14 15 16 17 18 19 20 6.2.4.2 21

20

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1
2

Figure 4 Originating UE not ready, Terminating UE not ready

3 41-5. INVITE (UE-1 to P-CSCF1) 5UE-1 determines the set of codecs or media streams that it wishes to support for the session. It builds a SDP 6containing characteristics of each codec, and assigns local port numbers for each possible media flow. Multiple 7media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices 8offered. 9 10For this example, it is assumed that UE-1 desires to establish a multimedia session comprising a video stream and an 11audio stream. The video stream supports one H.263 codec. The audio stream supports both EVRC and SMV codecs. 12 13UE-1 does not indicate that precondition is required for this session, but that it is supported. (This approach 14optimizes compatibility and performance when interworking with 3 rd party (non-MMD) terminals). In the SDP body, 15UE-1 indicates the current resource status and that the desired resource status is optional. UE-1 also sets every media 16stream to inactive mode by using the a=inactive SDP attribute in the SDP offer. Detecting the QoS precondition 17content in the SDP, UE-2 indicates resource reservation, but the session can continue regardless of whether or not 18this reservation is possible. 19 20UE-1 does not indicate that reliable provisional responses are required, but indicates that they are supported. This 21gives UE-2 the ability to reliably send only those responses that are most appropriate. 22 23UE-1 may perform local resource reservation at any time it feels it has enough information to begin this process.

21

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1This is assumed to be after sending the INVITE request, but could be sooner. 2

Table 6.2.4.2-1 - INVITE (UE-1 to P-CSCF1)

INVITE sip:UE-2@domain2.net SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag= a48s To: <sip:UE-2@domain2.net> Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>, <sip:scscf1.domain1.net;lr> P-Preferred-Identity: "User-1" <sip:UE-1@domain1.net> P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411 Privacy: none Contact: <sip:UE-1@100.200.1.1:1357;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Require: sec-agree Proxy-Require: sec-agree Supported: 100rel, precondition Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=9876543; spi-s=3456789; port-c=8642; port-s=7531 Content-Type: application/sdp Content-Length: xxx v=0 o=- 2987935614 2987935614 IN IP4 100.200.1.1 s=c=IN IP4 100.200.1.1 t=0 0 m=audio 10500 RTP/AVP 97 99 b=AS:25.4 a=inactive a=curr:qos local none a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 a=rtpmap:99 SMV/8000 m=video 10600 RTP/AVP 34 b=AS:75 a=inactive a=curr:qos local none a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

3 4 56-10. 183 Progress (P-CSCF1 to UE-1) 6UE-2 accepts both video and audio streams, and chooses EVRC as the codec for the audio stream. An SDP answer is 7included to assist UE-1 in completing resource reservation as early as possible. The SDP answer includes 8precondition status.

22

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

Table 6.2.4.2-2 - 183 Session Progress (P-CSCF1 to UE-1)

SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch= z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE Record-Route:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>, <sip:scscf1.domain1.net;lr>,<sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Contact: <sip:UE-2@100.300.1.2:2345;comp=sigcomp> P-Asserted-Identity: "User 2" <sip:UE-2@domain2.net>, <tel:+1-972-321-9876> Privacy: none Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Require: 100rel, precondition RSeq: 1000 Content-Type: application/sdp Content-Length: xxx v=0 o=- 35270718123 35270718123 IN IP4 100.300.1.2 s=c=IN IP4 100.300.1.2 t=0 0 m=audio 10700 RTP/AVP 97 b=AS:25.4 a=inactive a=curr:qos local none a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=conf:qos remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 m=video 10702 RTP/AVP 34 b=AS:75 a=inactive a=curr:qos local none a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=conf:qos remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

2 3 411-15. PRACK (UE-1 to P-CSCF1) 5UE-1 acknowledges the 183 (Session Progress) response from UE-2 with a PRACK request. Resource reservation at 6UE-1 is assumed to have completed at some point prior to sending the PRACK request. The local resource status is 7included in the SDP offer. 8 9

23

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

Table 6.2.4.2-3 - PRACK (UE-1 to P-CSCF1)

PRACK sip:UE-2@100.300.1.2:2345;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411 CSeq: 2 PRACK Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>, <sip:scscf2.domain2.net;lr>, <sip:pcscf2.domain2.net;lr> Require: precondition RAck: 1000 1 INVITE Content-Type: application/sdp Content-Length: xxx v=0 o=- 2987935614 2987935615 IN IP4 100.200.1.1 s=c=IN IP4 100.200.1.1 t=0 0 m=audio 10500 RTP/AVP 97 b=AS:25.4 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 m=video 10600 RTP/AVP 34 b=AS:75 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

2 3 416-20. 200 OK (P-CSCF1 to UE-1) 5The 200 OK response is generated by UE-2 to acknowledge the reception of the PRACK request. UE-2 has 6completed resource reservation for both video and audio streams. The response will include an SDP answer to 7reflect successful resource reservation.

24

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

Table 6.2.4.2-4 - 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 2 PRACK Require: precondition Content-Length: xxx v=0 o=- 35270718123 35270718124 IN IP4 100.300.1.2 s=c=IN IP4 100.300.1.2 t=0 0 m=audio 10500 RTP/AVP 97 b=AS:25.4 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:97 EVRC/8000 a=ptime:20 m=video 10600 RTP/AVP 34 b=AS:75 a=sendrecv a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos optional local sendrecv a=des:qos optional remote sendrecv a=rtpmap:34 H263/90000 a=cif:1

2 3 421-25. 180 Ringing (P-CSCF1 to UE-1) 5UE-2 generates a 180 (Ringing) response to UE-1 and sends it reliably. 6 7

Table 6.2.4.2-5 - 180 Ringing (P-CSCF1 to UE-1)

SIP/2.0 180 Ringing Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch= z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE Record-Route:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>, <sip:scscf1.domain1.net;lr>,<sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Contact: <sip:UE-2@100.300.1.2:2345;comp=sigcomp> P-Asserted-Identity: "User 2" <sip:UE-2@domain2.net>, <tel:+1-972-321-9876> Privacy: none Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Require: 100rel RSeq: 1001 Content-Length: 0

8 9 1026-30. PRACK (UE-1 to P-CSCF1) 11UE-1 acknowledges the 180 (Ringing) response from UE-2 with a PRACK request. 12

25

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

Table 6.2.4.2-6 - PRACK (UE-1 to P-CSCF1)

PRACK sip:UE-2@100.300.1.2:2345;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net P-Access-Network-Info: 3GPP2-1X-HRPD; ci-3gpp2=1234123412341234123412341234123411 CSeq: 3 PRACK Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>, <sip:scscf2.domain2.net;lr>, <sip:pcscf2.domain2.net;lr> RAck: 1001 1 INVITE Content-Length: 0

2 3 431-35. 200 OK (P-CSCF1 to UE-1) 5The 200 OK response is generated by UE-2 to acknowledge the reception of the PRACK request. 6

Table 6.2.4.2-7 - 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 3 PRACK Content-Length: 0

7 8 936-40. 200 OK (P-CSCF1 to UE-1) 10When the user at UE-2 answers the call, UE-2 generates a 200 OK response towards UE-1 to answer the INVITE 11request. 12

Table 6.2.4.2-8 - 200 OK (P-CSCF1 to UE-1)

SIP/2.0 200 OK Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 INVITE Record-Route:<sip:pcscf2.domain2.net;lr>,<sip:scscf2.domain2.net;lr>,<sip:scscf1.domain1.net;lr>, <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp> Contact: <sip:UE-2@100.300.1.2:2345;comp=sigcomp> Content-Length: 0

13 14 1541-45. ACK (UE-1 to P-CSCF1) 16UE-1 sends an ACK request in response to the 200 OK response from UE-2. 17

Table 6.2.4.2-9 - ACK (UE-1 to P-CSCF1)

26

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

ACK sip:UE-2@100.300.1.2:2345;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP 100.200.1.1:1357;comp=sigcomp;branch=z9hG4bK4d29348 From: <sip:UE-1@domain1.net>;tag=a48s To: <sip:UE-2@domain2.net>;tag=a9f6 Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@domain1.net CSeq: 1 ACK Max-Forwards: 70 Route: <sip:pcscf1.domain1.net:7531;lr;comp=sigcomp>,<sip:scscf1.domain1.net;lr>, <sip:scscf2.domain2.net;lr>, <sip:pcscf2.domain2.net;lr> Content-Length: 0

2 3

27

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1Appendix A 2reservation,

(Informative): VoIP example activation, and updating at RAN

with

QoS

3In this section, VoIP application is used as an example to show how the QoS reservation, activation, and updating 4process at RAN and IP-CAN works together with the call flows described in this document. The call flow described 5in Scenario 1 is used. The following call flows are examples where an HRPD Rev-A (or later) access network is 6used. 7

8A.1

QoS Configuration for VoIP in advance

9In order to reduce the call setup delay, VoIP application on the AT sets up two independent QoS flows in advance 10(e.g. right after the AT powers up): 11 1) SIP flow for SIP signaling messages; 12 2) RTP flow for VoIP RTP traffic. 13The steps for configuration of the QoS are the same for these two flows, except for the actual activation part of the 14SIP flow. The SIP flow reservation always remains in the on state while the VoIP RTP flow needs to be explicitly 15turned on when actual VoIP call is being set up.

28

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1
2

Figure 5 QoS configuration for VoIP

3Step 1: The UE powers up for the first time. 4Step 2: UE performs session negotiation. The AN provides the list of QoS User Profiles that the AN can handle as 5part of the parameter negotiation for MPA/EMPA. This step also includes the terminal authentication. UE gets the 6RANSupportedQoSProfiles as part of the session negotiation if AN plans to send one to the UE. 7Step 3: VoIP Application is started. 8Step 4: The PPP/PFO negotiation with the PDSN is initiated. The user is authenticated with the AAA and the users 9allowed QoS User Profiles is updated in the AN and PDSN. 10Step 5: The UE starts SIP flow setup. 11Step 6: The UE negotiates with the AN to configure the radio protocols requires to carry the SIP flow and once the 12PDSN is also successfully configured requests the AN to turn the reservation on. 13Step 7: AN performs A11 signaling to establish the required A10 connections. 14Step 8: The TFT filters and the channel treatment information are configured at the PDSN using RSVP messaging. 15Step 9: The SIP flow is activated.

29

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1Step 10: AN informs the PDSN that the QoS flow is activated. 2Step 11: The UE starts RTP flow setup. This may happen in parallel to step 5~10. 3Step 12: The UE negotiates with the AN to configure the radio protocols required to carry the RTP flow. 4Step 13: AN performs A11 signaling to establish the required A10 connections. 5Step 14: The TFT filters and the channel treatment information are configured at the PDSN. The RTP flow is now 6successfully configured and reservation is left in the off state. 7Step 15: Once step 10 and step 14 are completed, The UE performs SIP registration. 8 9

10A.2

Resource activation on originating side

11The call flow in this section show how the pre-reserved resources are turned on before the UE-1 makes a VoIP call.

12
13

Figure 6 QoS Activation on Originating UE

14Step 1. After the mobile user initiates the VoIP call, UE-1 performs connection setup for both SIP and RTP flows as 15described in Section A.1 if the flows are not set up in advance. 16Step 2. UE-1 sends ReservationOnRequest to turn on the QoS for the RTP flow. 17Step 3. AN-1 sends ReservationAccept to UE-1 indicating that the QoS for the RTP flow is changed to on state. 18Step 4~5. AN-1 informs the PDSN that the QoS flow for RTP is now activated. 19The rest of the call flow follows the procedures described in Scenario 1 where the resources at UE-1 are ready. 20

30

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

2A.3

Resource activation on terminating side

3This section shows how the terminating side, UE-2, quickly turns on its pre-configured QoS flow for RTP after it 4receives the INVITE and before it sends 180 (Ringing) to indicate resource ready. 5

6
7

Figure 7 QoS Activation on Terminating UE

8Step 1. UE-1 activates its QoS upon VoIP call initiation. 9Step 2. UE-1 sends INVITE to UE-2 and the INVITE request is eventually forwarded to AN-2. 10Step 3. AN-2 optionally performs connection setup (e.g., traffic channel setup etc) with UE-2. 11Step 4. AN-2 sends the INVITE to UE-2. 12Step 5. UE-2 sends ReservationOnRequest to turn on the QoS for the RTP flow. 13Step 6. AN-2 sends ReservationAccept to UE-2 indicating that the QoS for the RTP flow is changed to on state. 14Step 7~8. AN-2 informs the PDSN that the QoS flow for RTP is now activated. 15The rest of the call flow follows the procedures described in Scenario 1 where the resources at UE-2 are ready 16before the first provisional response is sent. 17 18

31

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1A.4

Updating of resource reservation

2In some cases, the UE may need to adjust the pre-configured QoS based on the actual codec negotiated. In this 3section, VoIP application with multiple codecs in the initial offer is used as an example to show how QoS resources 4can be updated without affecting the call setup delay. 5 6For example, in the initial INVITE sent from UE-1 to UE-2, two different codecs may be offered, one is supported 7by RS1 with FlowProfileID 256 (e.g. EVRC), while the other may be supported by RS2 with FlowProfileID 257 8(e.g. AMR). Typically, the VoIP calls will be RS1 with RS2 calls occurring occasionally. In order to expedite the call 9setup delay using the approach described in Sections A.1 through A.3, FlowProfileID 256 is always granted initially 10to the UE for the pre-configured RTP QoS flow. The reservation is turned to the open state with FlowProfileID 256 11when the UE initiates VoIP calls. If both ends actually agrees on RS2 Vocoder, the QoS flow may be switched to 12FlowProfileID=257. 13 14

15A.4.1

Resource updating on originating side

16Call flow in this section shows how UE-1 can update its QoS to support RS2 even though QoS flow for RS1 is pre17configured.

32

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1
2

Figure 8 Resource Updating on Originating UE

3Step 1. UE-1 performs connection setup if no flows have been pre-configured. 4Step 2~4. UE-1 sends INVITE to UE-2 and also turns on the QoS flow for RTP stream with FlowProfileID 256. 5Step 5~6. UE-2 completes resource reservation and returns 180 (Ringing) with the answer included. 6Step 7. UE-1 learns that RS2 codec is chosen for the session instead of the RS1 codec. It changes reservation label if 7different labels are used for the two reservations. 8Step 8~9. UE-1 requests the AN-1 to update the QoS flow profile to 257.

33

1X.S0013-009-0 v1.0

IMS/MMD Call Flow Examples

1Step 10~11. AN-1 indicates to UE-1 that the flow profile has been updated to 257. 2Step 12~13. AN-1 informs the PDSN that the updated flow has been activated. 3Step 14. UE-1 and AN-1 updates RLP/RTCMAC parameters to match the updated flow if necessary. 4The rest of the SIP messages are exchanged following the same procedure described in Scenario 1. 5

6A.4.1

Resource updating on terminating side

7Call flow in this section shows how UE-2 can update its QoS to support RS2 even though QoS flow for RS1 is pre8configured.

9
10

Figure 9 Resource Updating on Terminating UE

11Step 1~2. UE-1 completes resource reservation and sends INVITE to UE-2 with QoS ready indication in the offer. 12The INVITE arrives at AN-2 first. 13Step 3. AN-2 performs connection setup if no flows have been pre-configured. 14Step 4. AN-2 forwards the INVITE to UE-2. 15Step 5~6. UE-2 determines that RS2 codec will be used instead of the RS1 codec. It requests AN-2 to update the 16QoS flow for RTP to profile 257 and at the same time requests AN-2 to turn on the reservation. 17Step 7~8. AN-2 indicates to UE-2 that the flow profile has been updated to 257 and the flow is turned on.

34

1IMS/MMD Call Flow Examples

X.S0013-009-0 v1.0

1Step 9. UE-2 and AN-2 updates RLP/RTCMAC parameters to match the updated flow if necessary. 2Step 10~11. AN-2 informs the PDSN that the updated flow has been activated. 3The rest of the SIP messages are exchanged following the same procedure described in Scenario 1.

35