A.6 Flows demonstrating a user leaving a conference

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

A.6.1 Introduction

Void

A.6.2 User leaving the conference

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

Figure A.6.2.1-1 shows an user leaving a conference. The example shows the flow for the user, who created the conference with a conference-factory URI. For this example it is assume that the user is subscribed to the conference state event package at the MRFC/AS.

Figure A.6.2.1-1: User leaving a conference

The details of the flows are as follows.

1. BYE (UE to P-CSCF) – see example in table A.6.2.1-1

A UE wants to leave a conference. For this purpose the UE sends a BYE message to the P-CSCF with the Conference-URI as the Request-URI.

Table A.6.2.1-1: BYE (UE to P-CSCF)

BYE sip:conference1@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-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

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

Cseq: 153 BYE

Content-Length: 0

Request-URI: contains the value of the Conference-URI as learned during conference creation.

2. Remove resource reservation

The P-CSCF removes the authorization for resources that had previously been issued for this endpoint for this session. This step will also result in a release indication to the GPRS subsystem to confirm that the IP bearers associated with the session have been deleted.

3. BYE (P-CSCF to S-CSCF) – see example in table A.6.2.1-3

The P-CSCF removes the Security-Verify header, and the "sec-agree" option tag from the Require and Proxy-Require headers. As the Require and Proxy-Require headers are empty, it removes these headers completely.

Table A.6.2.1-3: BYE (P-CSCF to S-CSCF)

BYE sip:conference1@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>

P-Access-Network-Info:

From:

To:

Call-ID:

Cseq:

Content-Length: 0

4. BYE (S-CSCF to MRFC/AS) – see example in table A.6.2.1-4

The S-CSCF forwards the BYE to the MRFC/AS.

Table A.6.2.1-4: BYE (S-CSCF to MFRC/AS)

BYE sip:conference1@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

P-Access-Network-Info:

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Length:

5. H.248 interaction to release resources

The MRFC/AS interacts with the MRFP to release the resources reserved for UE#1 in this conference.

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

After successfully releasing the resources from the MRFP, the MRFC/AS sends a 200 (OK) response request to the S-CSCF.

Table A.6.2.1-6: 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:

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

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

Table A.6.2.1-7: 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:

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

P-CSCF forwards the message to the UE.

Table A.6.2.1-8: 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:

9. NOTIFY request (MRFC/AS to S-CSCF) – see example in table A.6.2.1-9

The MRFC/AS generates a NOTIFY request to indicate that UE#1 has left the conference and automatically unsubscribe UE#1 from its subscription to the conference event package.

Table A.6.2.1-9: NOTIFY request (MRFC/AS to S-CSCF)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

Max-Forwards: 70

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

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

From: <sip:conference1@mrfc1.home1.net>;tag=151170

To: <sip:user1_public1@home1.net>;tag=31415

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 42 NOTIFY

Subscription-State: terminated

Event: conference

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

Content-Type: application/conference-info+xml

Content-Length: (…)

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

<conference-info xmlns="urn:ietf:params:xml:ns:conference-info">

entity="conference1@mrfc1.home1.net"

state="full"

version="1"

<display- text>John Doe</display-text>

<status>disconnected</status>

<disconnection-method>departed</disconnection-method>

</endpoint>

</user>

<display- text>Simon Moon</display-text>

<status>connected</status>

<joining-method>dialed-in</joining-method>

<type>audio</type>

<src-id>534282</src-id>

<status>inactive</status>

</media>

</endpoint>

</user>

</conference-info>

P-Charging-Vector: The MRFC/AS populates the icid parameter with a globally unique value and populates the identifier of its own network to the originating Inter Operator Identifier (IOI) parameter of this header.

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

Subscription-State: Value of "terminated" indicates that the UE has been unsubscribed from the conference event package.

The message body in the NOTIFY request that carries the conference state information of the conference participants is formed as indicated in RFC 4575 [11].

10. Other conference participants are notified

MRFC/AS similarly notifies other conference participants that have subscribed to the conference event package that UE#1 has left the conference.

11. NOTIFY request (S-CSCF to P-CSCF) – see example in table A.6.2.1-11

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

Table A.6.2.1-11: NOTIFY request (S-CSCF to P-CSCF)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

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

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]

Max-Forwards: 69

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

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Type:

Content-Length:

(…)

12. NOTIFY request (P-CSCF to UE) – see example in table A.6.2.1-12

The P-CSCF forwards the NOTIFY request to the UE.

Table A.6.2.1-12: NOTIFY request (P-CSCF to UE)

NOTIFY sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net:7531;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UPD scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

Max-Forwards: 68

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Type:

Content-Length:

(…)

13. 200 (OK) response (UE to P-CSCF) – see example in table A.6.2.1-13 (related to table A.6.2.1-12)

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF.

Table A.6.2.1-13: 200 (OK) response (UE to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net:7531;comp=sigcomp;branch=z9hG4bK240f34.1, SIP/2.0/UPD scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

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

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

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

Table A.6.2.1-14: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UPD scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

Record-Route:

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

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Length:

15. 200 (OK) response (S-CSCF to MRFC/AS) – see example in table A.6.2.1-15

The S-CSCF forwards the 200 (OK) response to the MRFC/AS.

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

Record-Route:

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

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Length:

A.6.3 User requesting to remove another user from conference

The call flows for a user requesting the removal of another user from a conference are basically identical to the call flows for a user requesting IMS to join another user (see subclause A.4.4). The call flows only differ in the Refer-To header of the REFER request, namely in the “method" parameter which is set to “BYE" instead of “INVITE" and the tasks performed by the MRFC/AS before sending the NOTIFY requests.

A.6.4 MRFC/AS drops a user from a conference

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

Figure A.6.4.1-1 shows an MRFC/AS dropping a user from a conference.

Figure A.6.4.1-1: MRFC/AS dropping a user from a conference

The details of the flows are as follows.

1. BYE (MRFC/AS to S-CSCF) – see example in table A.6.4.1-1

MRFC/AS decides to drop a user from a conference. The decision may be based on a change in the conference policy, because the conference lifetime is exceeded, or some other reason.

The MRFC/AS issues a BYE request to the S-CSCF.

Table A.6.4.1-1: BYE (MRFC/AS to S-CSCF)

BYE sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 ;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

Max-Forwards: 70

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

From: <sip:conference1@mrfc1.home1.net>; tag=314159

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

Call-ID: cb03a0s09a2sdfglkj490333

Cseq: 73 BYE

Content-Length: 0

Request-URI: contains the Contact address of the dropped user.

2. BYE (S-CSCF to P-CSCF) – see example in table A.6.4.1-2

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

Table A.6.4.1-2: BYE (S-CSCF to P-CSCF)

BYE sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

Max-Forwards: 69

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

From:

To:

Call-ID:

Cseq:

Content-Length:

3. Remove resource reservation

4. BYE (P-CSCF to UE) – see example in table A.6.4.1-4

The P-CSCF forwards the BYE to the UE.

Table A.6.4.1-4: BYE (P-CSCF to UE)

BYE sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp SIP/2.0

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

Max-Forwards: 68

From:

To:

Call-ID:

Cseq:

Content-Length:

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

After successfully releasing the resources from the MRFP, the MRFC/AS sends a 200 (OK) response to the S-CSCF.

Table A.6.4.1-5: 200 (OK) response (UE to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

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

From:

To:

Call-ID:

Cseq:

Content-Length: 0

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

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

Table A.6.4.1-6: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

P-Access-Network-Info:

From:

To:

Call-ID:

Cseq:

Content-Length:

7. 200 (OK) response (S-CSCF to MRFC/AS) – see example in table A.6.4.1-7

S-CSCF forwards the 200 (OK) response to the MRFC/AS.

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP mrfc1.home1.net;branch=z9hG4bK348923.1

P-Access-Network-Info:

From:

To:

Call-ID:

Cseq:

Content-Length:

8. H.248 interaction to release resources

MRFC/AS interacts with the MRFP to release the resources reserved for UE#1 in this conference.

9. Conference event package messages

The MRFC/AS also terminates the user’s subscription to the conference state event package. The message flow is identical to messages 6.5.2.1-9 to 6.5.2.1-15 in subclause 6.5.2.1. for an user leaving a conference.