A.3 Flows demonstrating the creation of a conference

24.1473GPPConferencing using the IP Multimedia (IM) Core Network (CN) subsystemRelease 16Stage 3TS

A.3.1 Introduction

Clause A.3 covers the flows that show how a user can create conferences at a MRFC/AS.

A.3.2 User automatically creating a conference with a conference factory URI

A.3.2.1 MRFC/AS is located in user’s home network

Figure A.3.2.1-1: User automatically creating a conference with a conference factory URI – MRFC/AS is located in user’s home network

Figure A.3.2.1-1 shows an user creating a conference by using a conference-factory URI. The conference is created at a MRFC/AS of the users home network.

The details of the flows are as follows:

1. INVITE request (UE to P-CSCF) – see example in table A.3.2.1-1

A UE wants to create a conference. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as http).

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices offered.

For this example, it is assumed that UE#1 is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF.

The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. However, it does not use the "Require” header for these capabilities.

The UE does not have available the resources that are necessary to transport the media.

For this example it is assumed, that signalling encryption was negotiated between UE and P‑CSCF in the security mode set-up procedure during the last successful authentication. This option will only be shown in this example.

Table A.3.2.1-1: INVITE request (UE to P-CSCF)

INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree

Proxy-Require: sec-agree

Supported: precondition, 100rel, gruu, 199

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

Contact: <sip:user1_public1@home1.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY

Accept: application/sdp, application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=video 3400 RTP/AVP 98 99

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99:MPVMP4V-ES

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

Request-URI: contains the conference factory URI.

2. 100 (Trying) response (P-CSCF to UE) – see example in table A.3.2.1-2

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) provisional response.

Table A.3.2.1-2: 100 (Trying) response (P-CSCF to UE)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

3. INVITE request (P-CSCF to S-CSCF) – see example in table A.3.2.1-3

The P-CSCF forwards the INVITE request to the S-CSCF.

Table A.3.2.1-3: INVITE request (P-CSCF to S-CSCF)

INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

Route: <sip:orig@scscf1.home1.net;lr>

Record-Route: <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

4. 100 (Trying) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-4

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response.

Table A.3.2.1-4: 100 (Trying) response (S-CSCF to P-CSCF)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

5. Evaluation of initial filter criteria

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.

6. INVITE request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-6

The S-CSCF forwards the INVITE request to the MRFC/AS that is indicated in the host part of the Request URI. The S-CSCF does not re-write the Request URI.

Table A.3.2.1-6: INVITE request (S-CSCF to MRFC/AS)

INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

7. 100 (Trying) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-7 (related to table A.3.2.1-6)

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) provisional response.

Table A.3.2.1-7: 100 (Trying) response (MRFC/AS to S-CSCF)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

8. Allocate conference URI

The MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.

9. H.248 interaction to create connection

The MRFC initiates a H.248 interaction to create an IMS connection point for UE#1 in MRFP and to determine media capabilities of the MRFP.

10. 183 (Session Progress) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-13 (related to table A.3.2.1-6)

The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request.

The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session Progress) provisional response (to 6).

Table A.3.2.1-10: 183 (Session Progress) response (MRFC/AS to S-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "Conference Server" <sip:mrfc1.home1.net>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home1.net

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy: none

From:

To: <sip:conference-factory1@mrfc1.home1.net>; tag=314159

Call-ID:

CSeq:

Require: precondition, 100rel

Contact: <sip:lmaa234269@mrfc1.home1.net>;isfocus

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH

RSeq: 9021

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=video 10001 RTP/AVP 98 99

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=inactive

a=conf:qos remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=inactive

a=conf:qos remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

Contact: Contains the IP address or FQDN of the MRFC/AS and a temporary identifier of the conference being created in the user part. The URI for the allocated conference is not indicated yet. The "isfocus" feature parameter is included, as this temporary contact is still a conference URI.

P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with a unique value and populates the term-ioi parameter with the identifier of its own network.

P-Charging-Function-Address: The MRFC/AS stores the P-Charging-Function-Addresses header field to be passed to the S-CSCF.

11. 183 (Session Progress) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-11

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF.

Table A.3.2.1-11: 183 (Session Progress) response (S-CSCF to P-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

P-Asserted-Identity:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

12. Authorize QoS Resources

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after the 200 (OK) response of INVITE request (39) based on operator local policy.

13 183 (Session Progress) response (P-CSCF to UE) – see example in table A.3.2.1-13

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint.

Table A.3.2.1-13: 183 (Session Progress) response (P-CSCF to UE)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

14. Resource reservation

The originating UE sets up the bearer in accordance with the media description received SDP.

15. PRACK request (UE to P-CSCF) – see example in table A.3.2.1-15

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial offer/answer exchange.

Table A.3.2.1-15: PRACK request (UE to P-CSCF)

PRACK sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr> From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 128 PRACK

Require: precondition, sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

RAck: 9021 127 INVITE

Content-Length: 0

16. PRACK request (P-CSCF to S-CSCF) – see example in table A.3.2.1-16

The P-CSCF forwards the PRACK request to the S-CSCF.

Table A.3.2.1-16: PRACK request (P-CSCF to S-CSCF)

PRACK sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

P-Access-Network-Info:

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Require: precondition

RAck:

Content-Length:

17. PRACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-17

The S-CSCF forwards the PRACK request to the MRFC/AS.

Table A.3.2.1-17: PRACK request (S-CSCF to MRFC/AS)

PRACK sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Call-ID:

Cseq:

Require:

RAck:

Content-Length:

18. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-18 (related to table A.3.2.1-17)

The MRFC/AS acknowledges the PRACK request (17) with a 200 (OK) response.

Table A.3.2.1-18: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

19. H.248 interaction to modify connection

MRFC initiates a H.248 interaction to modify the connection established in step #9 and instructs MRFP to reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between the UE#1 and the MRFC.

20. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-20

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.3.2.1-20: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length:

21. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.1-21

The P-CSCF forwards the 200 (OK) response to the UE.

Table A.3.2.1-21: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length:

22. UPDATE request (UE to P-CSCF) – see example in table A.3.2.1-22

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.

Table A.3.2.1-22: UPDATE request (UE to P-CSCF)

UPDATE sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 129 UPDATE

Require: sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933617 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=video 0 RTP/AVP 98

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telphone-event

23. UPDATE request (P-CSCF to S-CSCF) – see example in table A.3.2.1-23

The P-CSCF forwards the UPDATE request to the S-CSCF.

Table A.3.2.1-23: UPDATE request (P-CSCF to S-CSCF)

UPDATE sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; ggsn=[5555::4b4:3c3:2d2:1e1]; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

m=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

24. UPDATE request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-24

The S-CSCF forwards the UPDATE request to the MRFC/AS.

Table A.3.2.1-24: UPDATE request (S-CSCF to MRFC/AS)

UPDATE sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

m=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

25. 200 (OK) response (MRFC/ASto S-CSCF) – see example in table A.3.2.1-25 (related to table A.3.2.1-24)

The MRFC/AS acknowledges the UPDATE request (24) with a 200 (OK) response.

Table A.3.2.1-25: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933625 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=video 0 RTP/AVP 98

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

The SDP indicates that the resource reservation was successful both in the local and the remote segment.

26. H.248 interaction to modify connection

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in MRFP.

27. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-27

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.3.2.1-27: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

28. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.1-28

The P-CSCF forwards the 200 (OK) response to the UE.

Table A.3.2.1-28: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

29. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.2.1-29 (related to table A.3.2.1-6)

After the success modification of the session (26), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (6) to the S-CSCF.

Table A.3.2.1-29: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

From:

To:

Call-ID:

CSeq: 127 INVITE

Contact: <sip:conference1@mrfc1.home1.net>;isfocus

Allow-Events: conference, pending-additions

Content-Length:0

Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages.

30. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.1-30

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF.

Table A.3.2.1-30: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

From:

To:

Call-ID:

CSeq:

Contact:

Allow-Events:

Content-Length:

31. Approval of QoS commit

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12).

32. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.1-32

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the media flow(s) for this session.

Table A.3.2.1-32: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

From:

To:

Call-ID:

CSeq:

Contact:

Allow-Events:

Content-Length:

33. ACK request (UE to P-CSCF) – see example in table A.3.2.1-33

The UE starts the media flow for this session, and responds to the 200( OK) response (32) with an ACK request sent to the P-CSCF.

Table A.3.2.1-33: ACK request (UE to P-CSCF)

ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

34. ACK request (P-CSCF to S-CSCF) – see example in table A.3.2.1-34

The P-CSCF forwards the ACK request to the S-CSCF.

Table A.3.2.1-34: ACK request (P-CSCF to S-CSCF)

ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Length:

35. ACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.1-35

The S-CSCF forwards the ACK request to the MRFC/AS.

Table A.3.2.1-35: ACK request (S-CSCF to MRFC/AS)

ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Length:

A.3.2.2 MRFC/AS is not located in user’s home network

Figure A.3.2.2-1 shows an user creating a conference by using a conference-factory URI. The conference is created at a MRFC/AS located in a different network than user’s S-CSCF.

Figure A.3.2.2-1: User automatically creating a conference with a conference factory URI –
MRFC/AS is not located in user’s home network

The details of the flows are as follows:

1. INVITE request (UE to P-CSCF) – see example in table A.3.2.2-1

A UE wants to create a conference to a MRFC/AS in other network. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as http)

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), there may be multiple codec choices offered.

For this example, it is assumed that the UE is willing to establish a multimedia session comprising a video stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF.

The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. However, it does not use the "Require" header for these capabilities.

The UE does not have available the resources that are necessary to transport the media.

For this example it is assumed, that signalling encryption was negotiated between UE and P‑CSCF in the security mode set-up procedure during the last successful authentication. This option will only be shown in this example.

Table A.3.2.2-1: INVITE request (UE to P-CSCF)

INVITE sip:conference-factory@home2.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory@home2.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree

Proxy-Require: sec-agree

Supported: precondition, 100rel, gruu, 199

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

Contact: <sip: user1_public1@home1.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY

Accept:application/sdp, application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=video 3400 RTP/AVP 98 99

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99:MPVMP4V-ES

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

Request-URI: contains the conference factory URI.

2. 100 (Trying) response (P-CSCF to UE) – see example in table A.3.2.2-2

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response.

Table A.3.2.2-2: 100 (Trying) response (P-CSCF to UE)

SIP/2.0 100 (Trying) response

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

3. INVITE request (P-CSCF to S-CSCF) – see example in table A.3.2.2-3

The P-CSCF forwards the INVITE request to the S-CSCF.

Table A.3.2.2-3: INVITE request (P-CSCF to S-CSCF)

INVITE sip:conference-factory@home2.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

Route: <sip:orig@scscf1.home1.net;lr>

Record-Route: <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

4. 100 (Trying) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-4

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response.

Table A.3.2.2-4: 100 (Trying) response (S-CSCF to P-CSCF)

SIP/2.0 100 (Trying) response

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

5. Evaluation of initial filter criteria

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.

6. INVITE request (S-CSCF to I-CSCF) – see example in table A.3.2.2-6

S-CSCF determines the network where the INVITE request should be forwarded. The S-CSCF resolves the I‑CSCF as the next hop for this request.

Table A.3.2.2-6: INVITE request (S-CSCF to I-CSCF)

INVITE sip:conference-factory@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

7. 100 (Trying) response (I-CSCF to S-CSCF) – see example in table A.3.2.2-7

The I-CSCF responds to the INVITE request (6) with a 100 (Trying) response provisional response.

Table A.3.2.2-7: 100 (Trying) response (I-CSCF to S-CSCF)

SIP/2.0 100 (Trying) response

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

8. Public service identity (PSI) location query

The I-CSCF resolves the conference-factory URI. In this example the I-CSCF queries HSS to resolve the MRFC/AS PSI to be contacted. The HSS responds with the address of the MRFC/AS.

For detailed message flows see 3GPP TS 29.228 [12] .

Table A.3.2.2-8a provides the parameters in the SIP INVITE request, which are sent to the HSS.

Table A.3.2.2-8a Cx: User location query procedure (I-CSCF to HSS)

Message source and destination

Cx: Information element name

Information source in SIP INVITE

Description

I-CSCF to HSS

Public Service Identity (PSI)

Request-URI:

This information element indicates the public user identity

Table A.3.2.2-8b provides the parameters sent from the HSS that need to be mapped to SIP INVITE and sent to MRFC/AS.

Table A.3.2.2-8b Cx: User location query procedure (HSS to I-CSCF)

Message source and destination

Cx: Information element name

Mapping to SIP header in SIP INVITE

Description

HSS to I-CSCF

MRFC/AS address

IP packet destination address

This information element indicates the MRFC/AS address which serves the PSI.

9. INVITE request (I-CSCF to MRFC/AS) – see example in table A.3.2.2-9

I-CSCF forwards the INVITE request to the MRFC/AS. The I-CSCF does not add itself to the Record-Route header since it does not need to stay on the signalling path for subsequent requests.

Table A.3.2.2-9: INVITE request (I-CSCF to MRFC/AS)

INVITE sip:conference-factory@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 67

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net

Privacy:

From:

To:

Call-ID:

Cseq:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

10. 100 (Trying) response (MRFC/AS to I-CSCF) – see example in table A.3.2.2-10 (related to table A.3.2.2-9)

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) response provisional response.

Table A.3.2.2-10: 100 (Trying) response (MRFC/AS to I-CSCF)

SIP/2.0 100 (Trying) response

Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

11. Allocate conference URI

MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.

12. H.248 interaction to create connection

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP and to determine media capabilities of MRFP.

13. 183 (Session Progress) response (MRFC/AS to I-CSCF) – see example in table A.3.2.2-13 (related to table A.3.2.2-9)

The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request.

The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session Progress) provisional response (to 8).

Table A.3.2.2-13: 183 (Session Progress) response (MRFC/AS to I-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "Conference Server" <sip:mrfc1.home2.net>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home2.net

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy: none

From:

To: <sip:conference-factory1@home2.net>; tag=314159

Call-ID:

CSeq:

Require: precondition, 100rel

Contact: <sip:conference1@mrfc1.home2.net>;isfocus

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH

RSeq: 9021

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=video 10001 RTP/AVP 98 99

b=AS:75

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=inactive

a=conf:qos remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=inactive

a=conf:qos remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.

P-Charging-Vector: The MRFC/AS inserts the originating IOI parameter received and populates the terminating IOI parameter with its own network.

P-Charging-Function-Addresses: The MRFC/AS inserts the P-Charging-Function-Addresses header field to be passed to the I-CSCF.

14. 183 (Session Progress) response (I-CSCF to S-CSCF) – see example in table A.3.2.2-14

The I-CSCF forwards the 183 (Session Progress) response to the P-CSCF.

Table A.3.2.2-14: 183 (Session Progress) response (I-CSCF to S-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

P-Asserted-Identity:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home2.net

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

15. 183 (Session Progress) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-15

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF.

Table A.3.2.2-15: 183 (Session Progress) response (S-CSCF to P-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

P-Asserted-Identity:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

16. Authorize QoS Resources

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after 200 (OK) response of INVITE request (34) based on operator local policy.

17. 183 (Session Progress) response (P-CSCF to UE) – see example in table A.3.2.2-17

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint.

Table A.3.2.2-17: 183 (Session Progress) response (P-CSCF to UE)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

RSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

18. Resource reservation

The originating UE sets up the bearer in accordance with the media description received SDP.

19. PRACK request (UE to P-CSCF) – see example in table A.3.2.2-19

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial offer/answer exchange.

Table A.3.2.2-19: PRACK request (UE to P-CSCF)

PRACK sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 128 PRACK

Require: precondition, sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

RAck: 9021 127 INVITE

Content-Length: 0

20. PRACK request (P-CSCF to S-CSCF) – see example in table A.3.2.2-20

The P-CSCF forwards the PRACK request to the S-CSCF.

Table A.3.2.2-20: PRACK request (P-CSCF to S-CSCF)

PRACK sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

P-Access-Network-Info:

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Require: precondition

RAck:

Content-Length:

21. PRACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.2-21

The S-CSCF resolves the Request-URI and forwards the PRACK request directly to the MRFC/AS.

Table A.3.2.2-21: PRACK request (S-CSCF to MRFC/AS)

PRACK sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Require:

RAck:

Content-Length:

22. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.2.2-22 (related to table A.3.2.2-21)

The MRFC/AS acknowledges the PRACK request (20) with a 200 (OK) response.

Table A.3.2.2-22: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

23. H.248 interaction to modify connection

MRFC initiates a H.248 interaction to modify the connection established in step #11 and instructs MRFP to reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between the UE#1 and the MRFC.

24. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-24

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.3.2.2-24: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length:

25. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.2-25

The P-CSCF forwards the 200 (OK) response to the UE.

Table A.3.2.2-25: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length:

26. UPDATE request (UE to P-CSCF) – see example in table A.3.2.2-26

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.

Table A.3.2.2-26: UPDATE request (UE to P-CSCF)

UPDATE sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 129 UPDATE

Require: sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933617 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=video 0 RTP/AVP 98

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telphone-event

27. UPDATE request (P-CSCF to S-CSCF) – see example in table A.3.2.2-27

The P-CSCF forwards the UPDATE request to the S-CSCF.

Table A.3.2.2-27: UPDATE request (P-CSCF to S-CSCF)

UPDATE sip:conferece1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; ggsn=[5555::4b4:3c3:2d2:1e1]; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

m=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

28. UPDATE request (S-CSCF to MRFC/AS) – see example in table A.3.2.2-28

The S-CSCF forwards the UPDATE request to the MRFC/AS.

Table A.3.2.2-28: UPDATE request (S-CSCF to MRFC/AS)

UPDATE sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

m=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

29. 200 (OK) response (MRFC/ASto S-CSCF) – see example in table A.3.2.2-29 (related to table A.3.2.2-28)

The MRFC/AS acknowledges the UPDATE request (27) with a 200 (OK) response.

Table A.3.2.2-29: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933625 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=video 0 RTP/AVP 98

b=AS:75

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

The SDP indicates that the resource reservation was successful both in the local and the remote segment.

30. H.248 interaction to modify connection

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in MRFP.

31. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-31

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.3.2.2-31: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 (OK)

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

32. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.2-32

The P-CSCF forwards the 200 (OK) response to the UE.

Table A.3.2.2-32: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

m=

b=

a=

a=

a=

a=

a=

a=

a=

33. 200 (OK) response (MRFC/AS to I-CSCF) – see example in table A.3.2.2-33 (related to table A.3.2.2-9)

After the success modification of the session (29), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (8) to the I-CSCF.

Table A.3.2.2-33: 200 (OK) response (MRFC/AS to I-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf1.home2.net;branch=z9hG4bK32f432.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

From:

To:

Call-ID:

CSeq: 127 INVITE

Contact: <sip:conference1@mrfc1.home2.net>;isfocus

Allow-Events: conference, pending-additions

Content-Length:0

Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages.

34. 200 (OK) response (I-CSCF to S-CSCF) – see example in table A.3.2.2-34

The I-CSCF forwards the 200(OK) response to the S-CSCF

Table A.3.2.2-34: 200 (OK) response (I-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

From:

To:

Call-ID:

CSeq:

Contact:

Allow-Events:

Content-Length:0

35. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.2.2-35

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF.

Table A.3.2.2-35: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

From:

To:

Call-ID:

CSeq:

Contact:

Allow-Events:

Content-Length:

36. Approval of QoS commit

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12).

37. 200 (OK) response (P-CSCF to UE) – see example in table A.3.2.2-37

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the media flow(s) for this session.

Table A.3.2.2-37: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

From:

To:

Call-ID:

CSeq:

Contact:

Allow-Events:

Content-Length:

38. ACK request (UE to P-CSCF) – see example in table A.3.2.2-38

The UE starts the media flow for this session, and responds to the 200 (OK) response (32) with an ACK request sent to the P-CSCF.

Table A.3.2.2-38: ACK request (UE to P-CSCF)

ACK sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@home2.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

39. ACK request (P-CSCF to S-CSCF) – see example in table A.3.2.2-39

The P-CSCF forwards the ACK request to the S-CSCF.

Table A.3.2.2-39: ACK request (P-CSCF to S-CSCF)

ACK sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Length:

40. ACK request (S-CSCF to MRFC/AS) – see example in table A.3.2.2-40

The S-CSCF forwards the ACK request to the MRFC/AS.

Table A.3.2.2-40: ACK request (S-CSCF to MRFC/AS)

ACK sip:conference1@mrfc1.home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Length:

A.3.3 User automatically creating a conference with a conference URI

The call flows for a user automatically creating a conference with a conference URI look identical to the call flows for conference creation with a conference-factory URI (see subclause A.3.2), besides the URIs carried in the Request URI and Contact header fields.

A.3.4 User creating a conference by manually dialling

The call flows for a user creating a conference by manually dialling into the IMS look identical to the call flows for conference creation with a conference-factory URI (see subclause A.3.2), besides the URIs carried in the Request URI and Contact header fields.

A.3.5 User creating a conference from two existing connections (Three-way session), users in different networks

Subclause 5.3.1.3.3 of the present document shows that the creation of a Three-way session is a local issue at the UE which results in a combination of other procedures (conference creation, conference participant invitation to conference, session release).

A.3.6 User automatically creating a conference with a conference factory URI and inviting some users to the newly-created conference

This flow shows how a user can create a conference using a conferece factory URI and simultaneously invite some users to the newly created conference, all using a single INVITE request.

Figure A.3.6-1: User automatically creating a conference with a conference factory URI – MRFC/AS is located in user’s home network

Figure A.3.6-1 shows an user creating a conference by using a conference-factory URI and simultaneouslt inviting some users to that conference. The conference is created at a MRFC/AS of the users home network.

The details of the flows are as follows:

1. INVITE request (UE to P-CSCF) – see example in table A.3.6-1

A UE wants to create a conference. For this purpose the UE is aware of a conference-factory URI that was obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as http).

The UE wants also to invite some users to this conference in an expedite manner, avoiding the cumbersome manual invitation to each of these users. Thus it builds a URI list including the SIP URIs of the users that are to be invited and includes it in the message body of the INVITE request for conference creation.

That the invited users have previously given consent to the inviting user to invite them.

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for each possible media flow. Multiple media flows can be offered, and for each media flow (m= line in SDP), there can be multiple codec choices offered.

For this example, it is assumed that the UE is willing to establish a multimedia session comprising an audio stream only. The audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF.

The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. However, it does not use the "Require” header for these capabilities.

The UE does not have available the resources that are necessary to transport the media.

For this example it is assumed, that signalling encryption was negotiated between UE and P‑CSCF in the security mode set-up procedure during the last successful authentication. This option will only be shown in this example.

Table A.3.6-1: INVITE request (UE to P-CSCF)

INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

P-Preferred-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Privacy: none

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 INVITE

Require: sec-agree, recipient-list-invite

Proxy-Require: sec-agree

Supported: precondition, 100rel, gruu, 199

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

Contact: <sip:user1_public1@home1.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp>

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY

Accept:application/sdp, application/3gpp-ims+xml

Content-Type: multipart/mixed;boundary="boundary1"

Content-Length: (…)

–boundary1

Content-Type: application/sdp

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=inactive

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

–boundary1

Content-Type: application/resource-lists+xml

Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?>

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"

xmlns:cp="urn:ietf:params:xml:ns:copycontrol">

<list>

<entry uri="sip:user2_public1@home1.net" cp:copyControl="to" />

<entry uri="sip:user3_public1@home1.net" cp:copyControl="to"

cp:anonymize="true"/>

<entry uri="sip:user1_public1@foreign.com" cp:copyControl="to"

cp:anonymize="true"/>

</list>

</resource-lists>

–boundary1–

Request-URI: contains the conference factory URI.

Content-Type: contains the specification of the MIME content with the string used as part separator

2. 100 (Trying) response (P-CSCF to UE) – see example in table A.3.6-2

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) provisional response.

Table A.3.6-2: 100 (Trying) response (P-CSCF to UE)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

3. INVITE request (P-CSCF to S-CSCF) – see example in table A.3.6-3

The P-CSCF forwards the INVITE request to the S-CSCF.

Table A.3.6-3: INVITE request (P-CSCF to S-CSCF)

INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

Route: <sip:orig@scscf1.home1.net;lr>

Record-Route: <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

Privacy:

From:

To:

Call-ID:

Cseq:

Require: recipient-list-invite

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

–boundary1

Content-Type:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

–boundary1

Content-Type:

Content-Disposition:

<?xml …?>

<resource-lists>

</resource-lists>

–boundary1

4. 100 (Trying) response (S-CSCF to P-CSCF) – see example in table A.3.6-4

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response.

Table A.3.6-4: 100 (Trying) response (S-CSCF to P-CSCF)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

5. Evaluation of initial filter criteria

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria.

6. INVITE request (S-CSCF to MRFC/AS) – see example in table A.3.6-6

The S-CSCF forwards the INVITE request to the MRFC/AS that is indicated in the host part of the Request URI. The S-CSCF does not re-write the Request URI.

Table A.3.6-6: INVITE request (S-CSCF to MRFC/AS)

INVITE sip:conference-factory1@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "John Doe" <sip:user1_public1@home1.net>, <tel:+358-50-4821437>

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=typ3home1.net;orig-ioi=homei.net

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

From:

To:

Call-ID:

Cseq:

Require:

Supported:

Contact:

Allow:

Accept:

Content-Type:

Content-Length: (…)

–boundary1

Content-Type:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

a=

–boundary1

Content-Type:

Content-Disposition:

<?xml …?>

<resource-lists>

</resource-lists>

–boundary1

7. 100 (Trying) response (MRFC/AS to S-CSCF) – see example in table A.3.6-7 (related to table A.3.6-6)

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) provisional response.

Table A.3.6-7: 100 (Trying) response (MRFC/AS to S-CSCF)

SIP/2.0 100 Trying

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

8. Allocate conference URI

The MRFC/AS allocates a conference URI, based on local information and information gained from the conference-factory URI, as well as information gained from other elements of the SIP signalling.

9. H.248 interaction to create connection

The MRFC initiates a H.248 interaction to create an IMS connection point for UE#1 in MRFP and to determine media capabilities of the MRFP.

10. Invite users to conference

Once the conference URI is allocated the MRFC/AS checks that the users identified by the SIP URIs in the body of the INVITE request from UE#1 have consented to be invited by UE#1. Provided they have previously consented, the users identified by the SIP URIs in the body of the INVITE request from UE#1 are invited to join the conference. To do this the MRFC/AS follows the procedure shown in A.4.3.1.3 setting the Request-URI to the users: sip:user2_public1@home1.net, sip:user3_public1@home1.net and sip:user1_public1@foreign.net.

Notice that the three invitations would be sent simultaneously if the MRFC/AS does support it (see section 5.3.2.5.3). Notice also that it is not necessary that the MRFC/AS waits for the completion of the invitation procedures before continuing with step 11, i.e. the three invitations and the procedure being described in the present flow can run in parallel.

11. 183 (Session Progress) response (MRFC/AS to S-CSCF) – see example in table A.3.6-13 (related to table A.3.6-6)

The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It determines the intersection with those appearing in the SDP in the INVITE request.

The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session Progress) provisional response (to 6).

Table A.3.6-10: 183 (Session Progress) response (MRFC/AS to S-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

P-Asserted-Identity: "Conference Server" <sip:mrfc1.home1.net>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; orig-ioi=type3home1.net; term-ioi=home1.net; term-ioi=type3as1.net

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy: none

From:

To: <sip:conference-factory1@mrfc1.home1.net>; tag=314159

Call-ID:

CSeq:

Require: precondition, 100rel

Contact: <sip:lmaa234269@mrfc1.home1.net>;isfocus

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH

RSeq: 9021

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933623 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=inactive

a=conf:qos remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

Contact: Contains the IP address or FQDN of the MRFC/AS and a temporary identifier of the conference being created in the user part. The URI for the allocated conference is not indicated yet. The "isfocus" feature parameter is included, as this temporary contact is still a conference URI.

P-Charging-Vector: The MRFC/AS inserts this header and populates the icid parameters with a unique value and populates the term-ioi parameter with the identifier of its own network.

P-Charging-Function-Address: The MRFC/AS stores the P-Charging-Function-Addresses header field to be passed to the S-CSCF.

11. 183 (Session Progress) response (S-CSCF to P-CSCF) – see example in table A.3.6-11

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF.

Table A.3.6-11: 183 (Session Progress) response (S-CSCF to P-CSCF)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

P-Asserted-Identity:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

P-Charging-Function-Addresses: ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a55:b44:c33:d22]; ecf=[5555::1ff:2ee:3dd:4cc]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

12. Authorize QoS Resources

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either happens at this stage or after the 200 (OK) response of INVITE request (39) based on operator local policy.

13 183 (Session Progress) response (P-CSCF to UE) – see example in table A.3.6-13

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint.

Table A.3.6-13: 183 (Session Progress) response (P-CSCF to UE)

SIP/2.0 183 Session Progress

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

P-Asserted-Identity:

Privacy:

From:

To:

Call-ID:

CSeq:

Require:

Contact:

Allow:

RSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

a=

b=

a=

a=

a=

a=

a=

a=

a=

a=

a=

14. Resource reservation

The originating UE sets up the bearer in accordance with the media description received SDP.

15. PRACK request (UE to P-CSCF) – see example in table A.3.6-15

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial offer/answer exchange.

Table A.3.6-15: PRACK request (UE to P-CSCF)

PRACK sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr> From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 128 PRACK

Require: precondition, sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

RAck: 9021 127 INVITE

Content-Length: 0

16. PRACK request (P-CSCF to S-CSCF) – see example in table A.3.6-16

The P-CSCF forwards the PRACK request to the S-CSCF.

Table A.3.6-16: PRACK request (P-CSCF to S-CSCF)

PRACK sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

P-Access-Network-Info:

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Require: precondition

RAck:

Content-Length:

17. PRACK request (S-CSCF to MRFC/AS) – see example in table A.3.6-17

The S-CSCF forwards the PRACK request to the MRFC/AS.

Table A.3.6-17: PRACK request (S-CSCF to MRFC/AS)

PRACK sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Call-ID:

Cseq:

Require:

RAck:

Content-Length:

18. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.6-18 (related to table A.3.6-17)

The MRFC/AS acknowledges the PRACK request (17) with a 200 (OK) response.

Table A.3.6-18: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length: 0

19. H.248 interaction to modify connection

MRFC initiates a H.248 interaction to modify the connection established in step #9 and instructs MRFP to reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between the UE#1 and the MRFC.

20. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.6-20

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.3.6-20: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length:

21. 200 (OK) response (P-CSCF to UE) – see example in table A.3.6-21

The P-CSCF forwards the 200 (OK) response to the UE.

Table A.3.6-21: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Length:

22. UPDATE request (UE to P-CSCF) – see example in table A.3.6-22

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the signalling path established by the INVITE request.

Table A.3.6-22: UPDATE request (UE to P-CSCF)

UPDATE sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 129 UPDATE

Require: sec-agree

Proxy-Require: sec-agree

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933617 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::aaa:bbb:ccc:ddd

t=0 0

m=audio 3456 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telphone-event

23. UPDATE request (P-CSCF to S-CSCF) – see example in table A.3.6-23

The P-CSCF forwards the UPDATE request to the S-CSCF.

Table A.3.6-23: UPDATE request (P-CSCF to S-CSCF)

UPDATE sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; ggsn=[5555::4b4:3c3:2d2:1e1]; pdp-sig=no; gcid=723084371; auth-token=43876559; flow-id=3

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

24. UPDATE request (S-CSCF to MRFC/AS) – see example in table A.3.6-24

The S-CSCF forwards the UPDATE request to the MRFC/AS.

Table A.3.6-24: UPDATE request (S-CSCF to MRFC/AS)

UPDATE sip:lmaa234269@mrfc1.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

P-Access-Network-Info:

From:

To:

Call-ID:

Cseq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

25. 200 (OK) response (MRFC/ASto S-CSCF) – see example in table A.3.6-25 (related to table A.3.6-24)

The MRFC/AS acknowledges the UPDATE request (24) with a 200 (OK) response.

Table A.3.6-25: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933623 2987933625 IN IP6 5555::aaa:bbb:ccc:ddd

s=-

c=IN IP6 5555::eee:fff:aaa:bbb

t=0 0

m=audio 6544 RTP/AVP 97 96

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; maxframes=2

a=rtpmap:96 telephone-event

The SDP indicates that the resource reservation was successful both in the local and the remote segment.

26. H.248 interaction to modify connection

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in MRFP.

27. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.6-27

The S-CSCF forwards the 200 (OK) response to the P-CSCF.

Table A.3.6-27: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

28. 200 (OK) response (P-CSCF to UE) – see example in table A.3.6-28

The P-CSCF forwards the 200 (OK) response to the UE.

Table A.3.6-28: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length:

v=

o=

s=

c=

t=

m=

b=

a=

a=

a=

a=

a=

a=

a=

29. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.3.6-29 (related to table A.3.6-6)

After the success modification of the session (26), the MRFC/AS sends a 200 (OK) response final response to the INVITE request (6) to the S-CSCF.

Table A.3.6-29: 200 (OK) response (MRFC/AS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net;lr>

From:

To:

Call-ID:

CSeq: 127 INVITE

Contact: <sip:conference1@mrfc1.home1.net>;isfocus

Allow-Events: conference, pending-additions

Content-Length:0

Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" feature parameter.

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages

30. 200 (OK) response (S-CSCF to P-CSCF) – see example in table A.3.6-30

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF.

Table A.3.6-30: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route:

From:

To:

Call-ID:

CSeq:

Contact:

Allow-Events:

Content-Length:

31. Approval of QoS commit

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12).

32. 200 (OK) response (P-CSCF to UE) – see example in table A.3.6-32

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the media flow(s) for this session.

Table A.3.6-32: 200 (OK) response (P-CSCF to UE)

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Record-Route: <sip:scscf1.home1.net;lr>, <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>

From:

To:

Call-ID:

CSeq:

Contact:

Allow-Events:

Content-Length:

33. ACK request (UE to P-CSCF) – see example in table A.3.6-33

The UE starts the media flow for this session, and responds to the 200( OK) response (32) with an ACK request sent to the P-CSCF.

Table A.3.6-33: ACK request (UE to P-CSCF)

ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>From: <sip:user1_public1@home1.net>; tag=171828

To: <sip:conference-factory1@mrfc1.home1.net>;tag=314159

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 127 ACK

Content-Length: 0

34. ACK request (P-CSCF to S-CSCF) – see example in table A.3.6-34

The P-CSCF forwards the ACK request to the S-CSCF.

Table A.3.6-34: ACK request (P-CSCF to S-CSCF)

ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 69

Route: <sip:scscf1.home1.net;lr>

From:

To:

Call-ID:

Cseq:

Content-Length:

35. ACK request (S-CSCF to MRFC/AS) – see example in table A.3.6-35

The S-CSCF forwards the ACK request to the MRFC/AS.

Table A.3.6-35: ACK request (S-CSCF to MRFC/AS)

ACK sip:conference1@mrfc1.home1.net:2342 SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Length: