A.4 Signalling flows demonstrating how presentities update presence information
24.1413GPPPresence service using the IP Multimedia (IM) Core Network (CN) subsystemRelease 17Stage 3TS
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">
<tuple id="a8098a.672364762364">
<status>
<basic>open</basic>
</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>
<timestamp>2003-08-27T11:49:29Z</timestamp>
</tuple>
<tuple id="jklhgf9788934774.78">
<status>
<basic>open</basic>
</status>
<rpid:class>assistant</rpid:class>
<rpid:relationship><rpid:assistant/></rpid:relationship>
<contact priority="1.0">tel:+1-212-555-2222</contact>
<note xml:lang="en">She’s my secretary</note>
<timestamp>2003-08-27T11:49:29Z</timestamp>
</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
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.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
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.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-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 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: