A.5 Flows demonstrating a user subscribing to the conference event package

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

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

A.5.1 Introduction

Void

A.5.2 User subscribing to the conference event package

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

Figure A.5.2.1-1: User subscribing to conference event package –
MRFC/AS is not located in user’s home network

Figure A.5.2.1-1 shows an user subscribing to the conference state event for a specific conference that is provided at a MRFC/AS located in another network. The conference URI, which is used for subscription to the conference event package, does include a FQDN in the host part in this example.

The details of the flows are as follows:

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

A UE wants to get informed about the state of a certain conference, the involved users and their related media states. The conference is identified by a conference URI. In order to initiate a subscription to the MRFC/AS, the UE generates a SUBSCRIBE request containing the ‘conference’ event, together with the length of time this periodic subscription should last.

Table A.5.2.1-1: SUBSCRIBE request (UE to P-CSCF)

SUBSCRIBE sip:conference1@mrfc2.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:orig@scscf1.home1.net;lr>

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

Privacy: none

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

To: <sip:conference1@mrfc2.home2.net>

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 61 SUBSCRIBE

Require: sec-agree

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

Event: conference

Expires: 7200

Accept: application/conference-info+xml

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>

Content-Length: 0

Request-URI: contains the conference URI.

2. SUBSCRIBE request (P-CSCF to S-CSCF) – see example in table A.5.2.1-2

The SUBSCRIBE request is forwarded to the S-CSCF.

Table A.5.2.1-2: SUBSCRIBE request (P-CSCF to S-CSCF)

SUBSCRIBE sip:conference1@mrfc2.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

P-Access-Network-Info:

Max-Forwards: 69

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

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

Privacy:

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

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

From:

To:

Call-ID:

CSeq:

Event:

Expires: Accept:

Contact:

Content-Length:

3. Evaluation of initial filter criteria

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

4. SUBSCRIBE request (S-CSCF to MRFC/AS) – see example in table A.5.2.1-4

S-CSCF forwards the SUBSCRIBE request to the MRFC/AS based on the Request URI of the SUBSCRIBE request. The S-CSCF does not re-write the Request URI.

Table A.5.2.1-4: SUBSCRIBE request (S-CSCF to MRFC/AS)

SUBSCRIBE sip:conference1@mrfc2.home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.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

P-Asserted-Identity:

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

Privacy:

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

From:

To:

Call-ID:

CSeq:

Event:

Expires: Accept:

Contact:

Content-Length:

5. 200 (OK) response (MRFC/AS to S-CSCF) – see example in table A.5.2.1-5 (related to table A.5.2.1-4)

The MRFC/AS performs the necessary authorization checks on the originator to ensure that he/she is allowed to subscribe to this specific conference. In this example the conditions have been met, so the MRFC/AS acknowledges the SUBSCRIBE request (6) with a 200 (OK) response.

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.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-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home2.net

From:

To: <sip:conference1@mrfc2.home2.net>;tag=151170

Call-ID:

CSeq:

Event:

Expires:

Contact: <sip:conference1@mrfc2.home2.net>

Content-Length:

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

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

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

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Contact:

Content-Length:

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

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

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Contact:

Content-Length:

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

The MRFC/AS generates a NOTIFY request that includes information about all participants that the subscribing user is allowed to see. The information about one participant includes:

– the SIP URI identifying the user;

– the dialog state associated for that users attachment to the conference; and

– the users status in terms of media in the conference.

Table A.5.2.1-8: 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 mrfc2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 70

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

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

From: <sip:conference1@mrfc2.home2.net>;tag=151170

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 42 NOTIFY

Subscription-State: active ;expires=7200

Event: conference;recurse

Contact: <sip:conference1@mrfc2.home2.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@mrfc2.home1.net"

state="full"

version="0"

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

<status>connected</status>

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

<type>audio</type>

<src-id>534232</src-id>

<status>sendrecv</status>

</media>

</endpoint>

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

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

<type>audio</type>

<src-id>534232</src-id>

<status>sendrecv</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 terminating Inter Operator Identifier (IOI) parameter of this header.

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].

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

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

Table A.5.2.1-9: 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 mrfc2.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 69

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

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]

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:

(…)

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

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

Table A.5.2.1-10: 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;branch=z9hG4bK240f34.1, SIP/2.0/UPD scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc2.home2.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:

(…)

11. 200 (OK) response (UE to P-CSCF) – see example in table A.5.2.1-11 (related to table A.5.2.1-10)

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

Table A.5.2.1-11: 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/UPD scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP mrfc2.home2.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

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

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

Table A.5.2.1-12: 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 mrfc2.home2.net;branch=z9hG4bK348923.1

Record-Route:

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

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Length:

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

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

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP mrfc2.home2.net;branch=z9hG4bK348923.1

Record-Route:

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

From:

To:

Call-ID:

CSeq:

Content-Length: