A.5 PS notifying watcher of updates to 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.5.1 Introduction

This subclause covers the signalling flows that show how the PS notifies watchers of updates to presence information.

A.5.2 Watcher and presentity in the different networks, UE in the home network

A.5.2.1 Successful notification

Figure A.5.2.1-1: Notification to watcher in the visited network

Figure A.5.2.1-1 shows how a watcher is notified of updates to a presentity’s presence information. The signalling flow is applicable to the case where the watcher and presentity are in the same or in different IM CN subsystems.

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

The PS determines which authorized watchers are entitled to receive the updates of the presence information for this presentity. For each appropriate watcher, the PS sends a NOTIFY request that contains the updated state of presence information. The NOTIFY request may either contain the complete set of presence information, or only the information that has changed since the last notification. In this example, the watcher indicated preference for partial notification in the SUBSCRIBE request, so the NOTIFY request is formulated according to RFC 5263 [24] and RFC 5262 [38] by including only the information that has changed since the last notification. (Note that the first NOTIFY request has contained the full state of the presence information.)

Table A.5.2.1-1: NOTIFY request (PS to S-CSCF)

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

Via: SIP/2.0/UDP ps.home2.net;branch=z9hG4bK240f34.1

Max-Forwards: 70

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

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

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

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 43 NOTIFY

Subscription-State: active;expires=5000

Event: presence

Contact: <sip:ps.home2.net>

Content-Type: application/pidf-diff+xml

Content-Length: (…)

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

<pidf-diff xmlns="urn:ietf:params:xml:ns:pidf-diff"version="1"

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

<![CDATA[

</status>

<rp:class>voice</rp:class>

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

<note xml:lang="en">This is a new tuple inserted as the 2^nd tuple.</note>

</tuple>

]] >

</add>

<replace sel="presence/tuple[@id="a8098a.672364762364"]/status/basic/text()">closed

</replace>

http://example.com/~user2/iconXYZ.gif</replace>

</pidf-diff>

P-Charging-Vector: The PS 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.

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

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

Table A.5.2.1-2: 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 scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP ps.home2.net;branch=z9hG4bK240f34.1

Max-Forwards: 69

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

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]

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

Record-Route: <sip:scscf2.home2.net;lr>

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Type:

Content-Length:

(…)

P-Charging-Vector: The S-CSCF stores the originating Inter Operator Identifier (IOI) parameter.

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

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

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

Table A.5.2.1-3: 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.home1.net;branch=240f34.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP ps.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 68

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Type:

Content-Length:

(…)

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

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

Table A.5.2.1-4: 200 (OK) response (UE to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.home1.net;branch=240f34.1, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP ps.home2.net;branch=z9hG4bK348923.1

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

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

Table A.5.2.1-5: 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 ps.home2.net;branch=z9hG4bK240f34.1

P-Access-Network-Info:

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

From:

To:

Call-ID:

CSeq:

Content-Length:

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

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

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

SIP/2.0 200 OK

Via: SIP/2.0/UDP ps.home2.net;branch=z9hG4bK240f34.1

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

From:

To:

Call-ID:

CSeq:

Content-Length:

P-Charging-Vector: The S-CSCF inserts 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.

A.5.3 Notification to resource list in a different network and notification to watcher in the visited network

A.5.3.1 Successful notification

Figure A.5.3.1-1: Notification to resource list in a different network and
notification to watcher in the visited network

Figure A.5.3.1-1 shows the PS providing presence event notification about a presentity to a RLS in a different network. This notification triggers the RLS to provide presence event notification to the watcher. The details of the signalling flows are as follows:

1. NOTIFY request (PS to S-CSCF) – see example in table A.5.3.1-1

The PS determines which authorized watchers are entitled to receive presence information. For each appropriate watcher, the PS sends a NOTIFY request that contains the updated state of presence information. In this example the notification is only sent to the RLS.

The NOTIFY request may either contain the complete set of presence information, or only those presence information that have changed since the last notification. In this example, the complete set of presence information is sent.

Table A.5.3.1-1: NOTIFY request (PS to S-CSCF)

NOTIFY sip:rls.home1.net SIP/2.0

Via: SIP/2.0/UDP ps.home2.net;branch=z9hG4bK240f34.1

Max-Forwards: 70

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=623551024"; orig-ioi=home12.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]

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

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

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

Call-ID: gahjt393yhakfh83hfasl98a

CSeq: 43 NOTIFY

Subscription-State: active;expires=5000

Event: presence

Contact: <sip:ps.home2.net>

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:privacy><text/></rpid:privacy>

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

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

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

<dm:person id="438">

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

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

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

<rpid:activities><rpid:meeting/></rpid:activities>

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

</dm:person>

</presence>

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

The message body in the NOTIFY request that carries the presence information of the presentity 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. NOTIFY request (S-CSCF to RLS) – see example in table A.5.3.1-2

The S-CSCF#1 forwards the NOTIFY request to the RLS.

Table A.5.3.1-2: NOTIFY request (S-CSCF to RLS)

NOTIFY sip:rls.home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bKehuehjgt, SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP ps.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 69

P-Charging-Vector:

P-Charging-Function-Addresses:

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Type:

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 stores the P-Charging-Function-Addresses header field and passes this header to the RLS.

3. 200 (OK) response (RLS to S-CSCF) – see example in table A.5.3.1-3

The RLS generates a 200 (OK) response to the NOTIFY request.

Table A.5.3.1-3: 200 (OK) response (RLS to S-CSCF)

SIP/2.0 200 OK

Via:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

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

The S-CSCF#1 forwards the 200 (OK) response to the PS.

Table A.5.3.1-4: 200 (OK) response (S-CSCF to PS)

SIP/2.0 200 OK

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

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

From:

To:

Call-ID:

CSeq:

Content-Length:

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

5. NOTIFY request (RLS to S-CSCF#1) – see example in table A.5.3.1-5

The RLS may decide to wait for other notifications and combine them in a single notification towards the UE or it sends the notification to the UE without any waiting. In this example, the RLS does not wait for other notifications.

Table A.5.3.1-5: NOTIFY request (RLS to S-CSCF)

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

Via: SIP/2.0/UDP rls.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 70

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=723551024"; 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]

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

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

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

Call-ID: gahjt393yhakfh83hfasl98a

CSeq: 90 NOTIFY

Subscription-State: active;expires=4500

Require: eventlist

Event: presence

Contact: <sip:rls.home1.net>

Content-Type: multipart/related;type="application/rlmi+xml";

start="<njhhsdhj@rls.home1.net>";boundary="70UBfW7L78hjgfgUPe5z"

Content-Length: (…)

–70UBfW7L78hjgfgUPe5z

Content-Transfer-Encoding: binary

Content-ID: <njhhsdhj@rls.home1.net>

Content-Type: application/rlmi+xml;charset="UTF-8"

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

<list xmlns="urn:ietf:params:xml:ns:rmli"

uri="sip:user1_list1@home1.net"

version="2"

fullState="false"

<name>Kovacs Janos</name>

</resource>

</list>

–70UBfW7L78hjgfgUPe5z

Content-Transfer-Encoding: binary

Content-ID: <uhjgfd@rls.home1.net>

Content-Type: application/pidf+xml;charset="UTF-8"

<?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>

<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:activities><rpid:meeting/></rpid:activities>

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

</dm:person>

</presence>

–70UBfW7L78hjgfgUPe5z

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

6. NOTIFY request (S-CSCF to P-CSCF) – see example in table A.5.3. 1-6

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

Table A.5.3.1-6: 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 rls.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 69

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

P-Charging-Function-Addresses:

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

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Require:

Event:

Contact:

Content-Type:

Content-Length:

(…)

P-Charging-Vector: The S-CSCF stores the originating Inter Operator Identifier (IOI) parameter.

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

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

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

Table A.5.3.1-7: 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=240f34.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP rls.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 68

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Require:

Event:

Contact:

Content-Type:

Content-Length:

(…)

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

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

Table A.5.3.1-8: 200 (OK) response (UE to P-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP pcscf1.visited1.net;branch=240f34.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1, SIP/2.0/UDP rls.home1.net;branch=z9hG4bK240f34.1

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

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

Table A.5.3.1-9: 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 rls.home1.net;branch=z9hG4bK240f34.1

P-Access-Network-Info:

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

From:

To:

Call-ID:

CSeq:

Content-Length:

10. 200 (OK) response (S-CSCF to RLS) – see example in table A.5.3.1-10

The S-CSCF forwards the response to the RLS in the home network of the presentity.

Table A.5.3.1-10: 200 (OK) response (S-CSCF to RLS)

SIP/2.0 200 OK

Via: SIP/2.0/UDP rls.home1.net;branch=z9hG4bK240f34.1

P-Access-Network-Info:

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=723551024"; 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:

Call-ID:

CSeq:

Content-Length:

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