A.4 Signalling flows demonstrating how presentities update presence information

24.1413GPPPresence service using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS

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

A.4.1 Introduction

This subclause covers the signalling flows that show how presentities update presence information in the PS.

A.4.2 Initial publication or modification of presence information by UE

A.4.2.1 Successful publication

Figure A.4.2.1-1: UE publishing presence information

The UE may publish the partial presence information or the full presence information about a presentity to the PS.

In this example, it is assumed that the UE publishes the full presence information.

Figure A.4.2.1-1 shows a UE publishing or modifying already existing presence information about a presentity. The details of the signalling flows as follows:

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

A PUA in a UE wishes to publish presence information. To initiate the publication, the UE generates a PUBLISH request according to RFC 3903 [23] containing the presence information that it wishes to publish.

Table A.4.2.1-1: PUBLISH request (UE to P-CSCF)

PUBLISH sip:user1_public1@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: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:user1_public1@home1.net>

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 61 PUBLISH

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

Event: presence

Expires: 7200

Content-Type: application/pidf+xml

Content-Length: (…)

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

<presence xmlns="urn:ietf:params:xml:ns:pidf"

xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"

xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"

xmlns:pcp="urn:ietf:params:xml:ns:pidf:caps"

xmlns:c="urn:ietf:params:xml:ns:pidf:cipid"

entity="pres:user2_public1@home2.net">

</status>

<rpid:class>sip</rpid:class>

<rpid:privacy><text/></rpid:privacy>

<rpid:status-icon>http://example.com/~user2/icon.gif</rpid:status-icon>

<pcp:servcaps>

<pcp:video>false</pcp:video>

<pcp:audio>true</pcp:audio>

</pcp:servcaps>

<contact priority="0.8">sip:user2_public1@home2.net</contact>

<note xml:lang="en">Don’t Disturb Please!</note>

<note xml:lang="fr">Ne derangez pas, s’il vous plait</note>

</tuple>

</status>

<rpid:class>assistant</rpid:class>

<rpid:relationship><rpid:assistant/></rpid:relationship>

<note xml:lang="en">She’s my secretary</note>

</tuple>

<dm:person>

<rpid:class>presentity</rpid:class>

<c:homepage>http://example.com/~user2</c:homepage>

<c:card>http://example.com/~user2/card.vcd</c:card>

<rpid:place-type until="2003-08-27T17:30:00Z"><rpid:office/></rpid:place-type>

</dm:person>

</presence>

Request-URI: Public user identity whose presence information the PUA intends to publish.

Event: This field is populated with the value "presence" to specify the use of the presence package.

To: Same as the Request-URI.

Content-Type: Set to the value "application/pidf+xml".

The message body in the PUBLISH request that carries the presence update state is formed as indicated in RFC 3863 [21], RFC 4480 [26], RFC 5196 [25], RFC 4482 [32], RFC 5263 [24] and RFC 4479 [44].

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

P-CSCF looks up the serving network information for the public user identity that was stored during the registration procedure. The PUBLISH request is forwarded to the S-CSCF. A Route header is inserted into PUBLISH request. The information for the Route header is taken from the service route determined during registration.

Table A.4.2.1-2: PUBLISH request (P-CSCF to S-CSCF)

PUBLISH sip:user1_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.home1.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>

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Content-Type:

Content-Length:

(…)

3. Evaluation of initial filter criteria

S-CSCF validates the service profile of the publisher and evaluates the initial filter criteria. For user1_public1@home1.net S-CSCF#1 has originating initial Filter Criteria with Service Point Trigger of Method = PUBLISH AND Event = "presence" AND Request-URI = "sip:user1_public1@home1.net" that informs the S‑CSCF to route the PUBLISH request to the PS ps.home1.net.

4. PUBLISH (S-CSCF to PS) – see example in table A.4.2.1-4

The S-CSCF#1 forwards the PUBLISH request to the PS.

Table A.4.2.1-4: PUBLISH request (S-CSCF to PS)

PUBLISH sip:user1_public1@home1.net SIP/2.0

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

P-Asserted-Identity:

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:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Content-Type:

Content-Length:

(…)

P-Charging-Vector: The S-CSCF 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 S-CSCF populates the P-Charging-Function-Addresses header field to be passed to the PS.

5. Authorization of publisher

The PS performs the necessary authorization checks on the originator to ensure it is allowed to publish the presentity’s presence information. In this example all privacy conditions are met, so the PS sends a 200 (OK) response to the S-CSCF.

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

The PS sends the response to S-CSCF.

Table A.4.2.1-6: 200 (OK) response (PS to S-CSCF)

SIP/2.0 200 OK

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

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:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]

From:

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

Call-ID:

CSeq:

Expires: 7200

SIP-ETag: 123xy

Content-Length: 0

P-Charging-Vector: The PS stores the originating Inter Operator Identifier (IOI) parameter and populates the identifier of its own network to the terminating Inter Operator Identifier (IOI) parameter of this header.

P-Charging-Function-Addresses: The PS stores the P-Charging-Function-Addresses header field and passes this header to the S-CSCF.

SIP-ETag: This field is populated with a locally unique entity-tag to associate further publications of this event state.

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

S-CSCF forwards the response to P-CSCF.

Table A.4.2.1-7: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

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

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

P-Charging-Function-Addresses:

From:

To:

Call-ID:

CSeq:

Expires:

SIP-ETag:

Content-Length:

P-Charging-Vector: The S-CSCF stores the terminating Inter Operator Identifier (IOI) parameter and removes the orig-ioi and the term-ioi parameters.

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and passes this header to the P-CSCF.

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

P-CSCF forwards the response to the PUA in the UE.

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

Expires:

SIP-ETag:

Content-Length:

A.4.3 Refreshing of presence information by UE

A.4.3.1 Successful refresh

Figure A.4.3.1-1: UE updating presence information

Figure A.4.3.1-1 shows an UE refreshing the presence information about a presentity. The details of the signalling flows are as follows:

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

A PUA in a UE wishes to refresh already existing presence information. To initiate the publication, the UE generates a PUBLISH request according to RFC 3903 [23].

Table A.4.3.1-1: PUBLISH request (UE to P-CSCF)

PUBLISH sip:user1_public1@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: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:user1_public1@home1.net>

Call-ID: b89rjhnedlrfjflslj40a111

CSeq: 61 PUBLISH

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

Event: presence

SIP-If-Match: 123xy

Expires: 7200

Content-Length: 0

Request-URI: Public user identity whose presence information the PUA intends to publish.

Event: This field is populated with the value "presence" to specify the use of the presence package.

To: Same as the Request-URI.

SIP-If-Match: This field is populated with the entity-tag earlier provided by the PS in the SIP-ETag header field of the previous 200(OK) response and is used as a versioning precondition to the PUBLISH refresh.

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

Table A.4.3.1-2: PUBLISH request (P-CSCF to S-CSCF)

PUBLISH sip:user1_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP pcscf1.home1.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>

From:

To:

Call-ID:

CSeq:

Event:

SIP-If-Match:

Expires:

Content-Length:

P-Charging-Vector: The P-CSCF populates the icid parameter with a globally unique value.

3. Evaluation of initial filter criteria

S-CSCF#1 validates the service profile of this publisher and evaluates the initial filter criteria. For user1_public1@home1.net the S-CSCF has originating initial Filter Criteria with Service Point Trigger of Method = PUBLISH AND Event = "presence" AND Request-URI = "sip:user1_public1@home1.net" that informs the S-CSCF to route the PUBLISH request to the PS ps.home1.net.

4. PUBLISH (S-CSCF to PS) – see example in table A.4.3.1-4

The S-CSCF forwards the PUBLISH request to the PS.

Table A.4.3.1-4: PUBLISH (S-CSCF to PS)

PUBLISH sip:user1_public1@home1.net SIP/2.0

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

P-Asserted-Identity:

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:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]

Privacy:

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

From:

To:

Call-ID:

CSeq:

Event:

SIP-If-Match:

Expires:

Content-Length:

P-Charging-Vector: The S-CSCF stores the originating Inter Operator Identifier (IOI) parameter and populates the identifier of its own network to the originating Inter Operator Identifier (IOI) parameter of this header.

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

5. Authorization of publisher

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

The PS sends the response to S-CSCF.

Table A.4.3.1-6: 200 (OK) response (PS to S-CSCF)

SIP/2.0 200 OK

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

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023555517"; 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:4ee]; ecf=[5555::6aa:7bb:8cc:9dd]

From:

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

Call-ID:

CSeq:

Expires: 7200

SIP-ETag: 345abc

Content-Length: 0

P-Charging-Function-Addresses: The PS stores the P-Charging-Function-Addresses header field and passes this header to the S-CSCF.

SIP-ETag: This field is populated with a new locally unique entity-tag.

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

S-CSCF#1 forwards the response to P-CSCF.

Table A.4.3.1-7: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

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

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

P-Charging-Function-Addresses:

From:

To:

Call-ID:

CSeq:

Expires:

SIP-ETag:

Content-Length:

P-Charging-Vector: The S-CSCF stores the terminating Inter Operator Identifier (IOI) parameter and removes the orig-ioi and the term-ioi parameters.

P-Charging-Function-Addresses: The S-CSCF stores the P-Charging-Function-Addresses header field and passes this header to the P-CSCF.

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

P-CSCF#1 forwards the response to the PUA in the UE.

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

Expires:

SIP-ETag:

Content-Length: