A.3 Signalling flows demonstrating how watchers subscribe to presence event notification

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.3.1 Introduction

The subclause covers the signalling flows that show how watchers can request presence information about a presentity.

For the routing of the Public Service Identity (PSI) towards the AS, there are two scenarios:

Subclause A.3.3.2 shows the case where the I-CSCF forwards the SUBSCRIBE request directly to the RLS when the RLS is located within the same network. There is another scenario where the I-CSCF forwards the SUBSCRIBE request towards the RLS, being involved with the S-CSCF located in the same network, but this scenario is not described in the present document.

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

A.3.2.1 Successful subscription

Figure A.3.2.1-1: Watcher subscribing for presence information

Figure A.3.2.1-1 shows a watcher subscribing to presence event notification about a presentity. The presentity is in a different IM CN subsystem. The details of the signalling flows are as follows:

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

A watcher agent in a UE wishes to watch a presentity, or certain presence information of the presentity. To initiate a subscription, the UE generates a SUBSCRIBE request containing the "presence" event that it wishes to be notified of, together with an indication of the length of time this periodic subscription should last and the support for partial notification.

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

SUBSCRIBE sip:user2_public1@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:user2_public1@home2.net>

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 61 SUBSCRIBE

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

Accept: application/pidf+xml;q=0.3, application/pidf-diff+xml;q=1

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

Content-Length: 0

Request-URI: Public user identity whose events the subscriber subscribes to.

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

Accept: This field is populated with the value ‘application/pidf+xml’ and ‘application/pidf-diff+xml’, latter one with higher preference.

To: Same as the Request-URI.

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

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

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

SUBSCRIBE sip:user2_public1@home2.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>

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

3. Evaluation of initial filter criteria

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. In this example, no AS is assumed to be involved.

4. SUBSCRIBE request (S-CSCF to I-CSCF) – see example in table A.3.2.1-4

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. Since the originating operator does not desire to keep their internal configuration hidden, S-CSCF#1 forwards the SUBSCRIBE request directly to the I-CSCF in the destination network.

Table A.3.2.1-4: SUBSCRIBE (S-CSCF to I-CSCF)

SUBSCRIBE sip:user2_public1@home2.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

Max-Forwards: 68

P-Asserted-Identity: <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

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

Privacy:

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

5. Cx: User Location Query procedure

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the address of the current S-CSCF for the terminating subscriber.

For detailed message flows see 3GPP TS 29.228 [10].

Table A.3.2.1-5a provides the parameters in the SIP SUBSCRIBE request (flow 4), which are sent to the HSS.

Table A.3.2.1-5a: Cx: User location query procedure (I-CSCF to HSS)

Message source and destination	Cx: Information element name	Information source in SIP SUBSCRIBE	Description
I-CSCF to HSS	User Public Identity	Request-URI	This information element indicates the public user identity

Table A.3.2.1-5b provides the parameters sent from the HSS that need to be mapped to the SIP SUBSCRIBE request (flow 6) and sent to the S-CSCF.

Table A.3.2.1-5b: Cx: User location query procedure (HSS to I-CSCF)

Message source and destination	Cx: Information element name	Mapping to SIP header in SIP SUBSCRIBE	Description
HSS to I-CSCF	S-CSCF name	Route header field	This information indicates the serving CSCF’s name of that user

6. SUBSCRIBE request (I-CSCF to S-CSCF) – see example in table A.3.2.1-6

The I-CSCF forwards the SUBSCRIBE request to the S-CSCF (S-CSCF#2) that will handle the termination.

Table A.3.2.1-6: SUBSCRIBE request (I-CSCF to S-CSCF)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, 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

Max-Forwards: 67

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

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

Record-Route:

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling path for the subsequent requests.

7. Evaluation of initial filter criteria

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. For sip:user2_public1@home2.net S-CSCF#2 has termination initial filter criteria with Service Point Trigger of Method = SUBSCRIBE and Event = "presence" that informs the S-CSCF to route the SUBSCRIBE request to the AS ps.home2.net. The S-CSCF#2 has preconfigured information not to create a Record-Route entry for this request.

8. SUBSCRIBE request (S-CSCF to PS) – see example in table A.3.2.1-8

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

Table A.3.2.1-8: SUBSCRIBE request (S-CSCF to PS)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, 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

Max-Forwards: 66

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.home2.net;lr>, <sip:scscf2.home2.net;lr>

Record-Route:

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

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

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

9. Authorization of watcher

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

In the case where the privacy/authorization checks failes, then a necessary 2xx or 4xx response will be sent to the S-CSCF. The selection of the correct response code depends on the presentity’s subscription authorization policy document.

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

The PS sends the response to S-CSCF#2.

Table A.3.2.1-10: 200 (OK) response (PS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP

icscf2_s.home2.net;branch=z9hG4bK871y12.1, 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=home2.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]

Record-Route:

From:

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

Call-ID:

CSeq:

Expires:

Contact: <sip:ps.home2.net>

Content-Length:

P-Charging-Vector: The PS stores the originating Inter Operator Identifier (IOI) parameter received 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.

11. 200 (OK) response (S-CSCF to I-CSCF) – see example in table A.3.2.1-11

S-CSCF#2 forwards the response to I-CSCF#2.

Table A.3.2.1-11: 200 (OK) response (S-CSCF to I-CSCF)

SIP/2.0 200 OK

P-Charging-Vector:

P-Charging-Function-Addresses:

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

P-Charging-Vector: The S-CSCF stores the originating Inter Operator Identifier (IOI) parameter received and populates the identifier of its own network to the terminating 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 I-CSCF.

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

I-CSCF#2 forwards the response to S-CSCF#1.

Table A.3.2.1-12: 200 (OK) response (I-CSCF 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:

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

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

Table A.3.2.1-13: 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"

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

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

Table A.3.2.1-14: 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: <sip:orig@scscf1.home1.net;lr>, <sip:pcscf1.home1.net:7531;lr;comp=sigcomp>

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

As soon as the PS sends a 200 (OK) response to accept the subscription, it sends a NOTIFY request with the current state of the presentity’s presence information that the watcher has subscribed and been authorized to. The NOTIFY request is sent to S-CSCF#1. Based on the Accept header field of the SUBSCRIBE request, the PS decides to use partial notification to provide changes of presence information.

Table A.3.2.1-15: 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=z9hG4bK348923.1

Max-Forwards: 70

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024"; orig-ioi=home2.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.home1.net;lr>

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

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 42 NOTIFY

Subscription-State: active ;expires=7200

Event: presence

Contact: <sip:ps.home2.net>

Content-Type: application/pidf-diff +xml

Content-Length: (…)

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

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

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

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"

version="1">

</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 id="s438">

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

</diff:pidf-full>

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

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

Content-Type: Set to the preferred value of the Accept header received in the SUBSCRIBE request.

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

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

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

Table A.3.2.1-16: 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=z9hG4bK351g45.1, SIP/2.0/UDP ps.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 69

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

P-Charging-Function-Addresses:

Privacy:

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

Route: sip:<pcscf1.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 of this header and removes the parameter from this header.

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

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

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

Table A.3.2.1-17: 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=z9hG4bK240f34.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>

Privacy:

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Type:

Content-Length:

(…)

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

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

Table A.3.2.1-18: 200 (OK) response (UE to P-CSCF)

SIP/2.0 200 OK

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

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

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

Table A.3.2.1-19: 200 (OK) response (P-CSCF to S-CSCF)

SIP/2.0 200 OK

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

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Length:

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

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

Table A.3.2.1-20: 200 (OK) response (S-CSCF to PS)

SIP/2.0 200 OK

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

From:

To:

Call-ID:

CSeq:

Content-Length:

A.3.3 Watcher subscribing to resource list, UE in visited network

A.3.3.1 Watcher subscribing to his own resource list, UE in visited network – Successful subscription

Figure A.3.3.1-1: Watcher subscribing to resource list

Figure A.3.3.1-1 shows a watcher subscribing to resource list event notification. The details of the signalling flows are as follows:

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

A watcher agent in a UE wishes to watch a number of presentities, or certain presence information of these presentities. The list of presentities are identified by a SIP URI. In order to initiate a subscription to the RLS, the UE generates a SUBSCRIBE request indicating support for "eventlist", together with an indication of the length of time this periodic subscription should last.

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

SUBSCRIBE sip:user1_list1@home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

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_list1@home1.net>

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 123 SUBSCRIBE

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

Supported: eventlist

Expires: 7200

Accept: application/pidf+xml, application/rlmi+xml, multipart/related

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

Content-Length: 0

Request-URI: SIP URI of the resource list representing the collection of public user identities whose events the subscriber subscribes to.

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

Accept: This field is populated with the value "application/pidf+xml", "application/rlmi+xml" and "multipart/related" indicating that the UE supports both body types for the eventlist extension additionally to PIDF.

Supported: This field is populated with the value "eventlist" to specify the support for the eventlist extension.

To: Same as the Request-URI.

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

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

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

SUBSCRIBE sip:user1_list1@home1.net SIP/2.0

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

P-Access-Network-Info:

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

Max-Forwards: 69

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

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

Privacy:

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

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

From:

To:

Call-ID:

CSeq:

Event:

Supported:

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. Assuming that sip:user1_list1@home1.net is a statically created PSI, sip:user1_list1@home1.net is included in the service profile as part of an originating initial Filter Criteria with Service Trigger Point of Method = SUBSCRIBE AND Supported = "eventlist" AND Request-URI = sip:user1_list1@home1.net that informs the S-CSCF to route the SUBSCRIBE request to the AS sip:rls.home1.net.

If there is no initial filter criteria for this PSI (sip:user1_list1@home1.net), the assumption is that the PSI is a sub domain-based PSI. The procedure defined in RFC 3263 [18] with DNS NAPTR and SRV queries may then be used to get the IP address of the AS home1.net.

4. SUBSCRIBE request (S-CSCF to RLS) – see example in table A.3.3.1-4

The S-CSCF forwards the SUBSCRIBE request to the RLS.

Table A.3.3.1-4: SUBSCRIBE request (S-CSCF to RLS)

SUBSCRIBE sip:user1_list1@home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

Max-Forwards: 68

P-Access-Network-Info:

P-Asserted-Identity: <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

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

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

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

From:

To:

Call-ID:

CSeq:

Event:

Supported:

Expires:

Accept:

Contact:

Content-Length:

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

5. Authorization of watcher

The RLS performs the necessary authorization checks on the originator to ensure that he/she is authorized to use the resource list. In this example this condition has been met, so the PS sends a 200 (OK) response to the S-CSCF. If the previous condition failed, then a 403 (Forbidden) response would be sent to the S-CSCF.

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

The RLS sends the response to the S-CSCF.

Table A.3.3.1-6: 200 (OK) response (RLS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

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

Record-Route:

From:

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

Call-ID:

CSeq:

Require: eventlist

Expires:

Contact:

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.

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

The S-CSCF forwards the response to the P-CSCF.

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

SIP/2.0 200 OK

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

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

Record-Route:

From:

To:

Call-ID:

CSeq:

Require:

Expires:

Contact:

Content-Length:

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

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

The P-CSCF forwards the response to the watcher agent in the UE.

Table A.3.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=z9hG4bKehuefdam

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

From:

To:

Call-ID:

CSeq:

Require:

Expires:

Contact:

Content-Length:

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

The RLS generates a NOTIFY request including the RLMI document as a result of the SUBSCRIBE request.

Table A.3.3.1-9 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=323551024"; 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: b89rjhnedlrfjflslj40a222

CSeq: 89 NOTIFY

Subscription-State: active;expires=7200

Require: eventlist

Event: presence

Contact: <sip:rls.home1.net>

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

Content-Length:

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

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

uri="sip:user1_list1@home1.net" version="1" fullState="true">

<name>Kovacs Janos</name>

</resource>

<name>Szabo Bela</name>

</resource>

</list>

P-Charging-Vector: The RLS inserts this header and populates the icid parameters with a globally unique value and adds 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.

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

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

Table A.3.3.1-10: 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=323551024"

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

(…)

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

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

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

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

Table A.3.3.1-11: 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-Length:

(…)

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

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

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

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

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

Table A.3.3.1-13: 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=323551024"

From:

To:

Call-ID:

CSeq:

Content-Length:

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

The S-CSCF#2 forwards the response to the RLS in the home network of the UE.

Table A.3.3.1-14: 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=323551024"; orig-ioi=home1.net; term-ioi=home1.net

From:

To:

Call-ID:

CSeq:

Content-Length:

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

15. Subscriptions and notifications on presence event package

After the RLS generated a NOTIFY request to inform the UE about the subscription state, the RLS generates the necessary SUBSCRIBE requests to the presentities present in the resource list as described in subclause A.3.4.1. As soon as it receives NOTIFY request(s) about a state change in one or more presentities, it generates a NOTIFY request.

16. NOTIFY request (RLS to S-CSCF) – see example in table A.3.3.1-16

The RLS copies the body of the incoming NOTIFY request(s) into the body of the outgoing NOTIFY request using MIME type multipart/related. Further notification sent by the RLS may contain either the full or the partial set of presence information (only the presence information that has changed since the last notification) as described in RFC 4662 [22].

In this example it is assumed that the RLS has received two NOTIFY requests from presentities sip:user2_public1@home2.net and sip:user3_public1@home3.net before generating the NOTIFY request in table A.3.3.1-16 to the UE.

Table A.3.3.1-16 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=423551024"; 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: b89rjhnedlrfjflslj40a222

CSeq: 90 NOTIFY

Subscription-State: active;expires=5000

Require: eventlist

Event: presence

Contact: <sip:rls.home1.net>

Content-Type: multipart/related;type="application/rlmi+xml"; start="<nXYxAE@rls.home1.net>";boundary="50UBfW7LSCVLtggUPe5z"

Content-Length: (…)

–50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <nXYxAE@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="1" fullState="true">

<name>Kovacs Janos</name>

</resource>

<name>Szabo Bela</name>

</resource>

</list>

–50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <ZvSvkz@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>

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

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

</dm:person>

</presence>

–50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <ZvSvkz@pres.example.com>

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"

entity="pres:user3_public1@home3.net">

<basic>closed</basic>

</status>

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

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

<pcp:servcaps>

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

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

</pcp:servcaps>

<contact priority="0.8">sip:user3_public1@home3.net</contact>

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

<note xml:lang="hu">Senki se merjen zavarni!</note>

</tuple>

</status>

<rpid:class>supervisor</rpid:class>

<rpid:relationship><rpid:supervisor/></rpid:relationship>

<note xml:lang="en">He’s my supervisor</note>

</tuple>

<dm:person>

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

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

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

<rpid:activities><rpid:vacation/></rpid:activities>

<rpid:place-type until="2003-09-10T17:30:00Z"><rpid:ship/></rpid:place-type>

</dm:person>

</presence>

–50UBfW7LSCVLtggUPe5z–

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

Content-Type: Set to the value of the Accept: header received in the SUBSCRIBE request.

The message body in the NOTIFY request that carries the presence information of the presentity is formed as indicated in RFC 4662 [22], RFC 4479 [44], RFC 4480 [26], RFC 4482 [32] and RFC 5196 [25].

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

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

Table A.3.3.1-17: 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=423551024"

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 RLS stores the originating Inter Operator Identifier (IOI) parameter received.

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

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

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

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

Content-Type:

Content-Length:

(…)

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

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

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

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

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

Table A.3.3.1-20: 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=423551024"

From:

To:

Call-ID:

CSeq:

Content-Length:

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

The S-CSCF#2 forwards the response to the RLS in the home network of the UE.

Table A.3.3.1-21: 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=423551024"; orig-ioi=home1.net; term-ioi=home1.net

From:

To:

Call-ID:

CSeq:

Content-Length:

A.3.3.2 Watcher subscribing to a resource list, UE in visited network – successful subscription

Figure A.3.3.2-1 Watcher subscribing to resource list

Figure A.3.3.2-1 shows a watcher subscribing to resource list event notification. The details of the signalling flows are as follows:

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

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

SUBSCRIBE sip:user2_list1@home2.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

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:user2_list1@home1.net>

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 123 SUBSCRIBE

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

Supported: eventlist

Expires: 7200

Accept: application/pidf+xml, application/rlmi+xml, multipart/related

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

Content-Length: 0

Request-URI: SIP URI of the resource list representing the collection of public user identities whose events the subscriber subscribes to.

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

Accept: This field is populated with the value "application/pidf+xml", "application/rlmi+xml" and "multipart/related" indicating that the UE supports the eventlist extension additionally to PIDF.

Supported: This field is populated with the value "eventlist" to specify the support for the eventlist extension.

To: Same as the Request-URI.

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

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

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

SUBSCRIBE sip:user2_list1@home2.net SIP/2.0

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

P-Access-Network-Info:

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

Max-Forwards: 69

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

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

Privacy:

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

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

From:

To:

Call-ID:

CSeq:

Event:

Supported:

Expires:

Accept:

Contact:

Content-Length:

3. Evaluation of initial filter criteria

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. In this example, no AS is assumed to be involved.

4. SUBSCRIBE request (S-CSCF to I-CSCF) – see example in table A.3.3.2-4

S-CSCF#1 performs an analysis of the destination address. As the destination address points to a resource that is in a different network as the S-CSCF, the S-CSCF sends the request to the I-CSCF of home2.net.

Table A.3.3.2-4: SUBSCRIBE request (S-CSCF to I-CSCF)

SUBSCRIBE sip:user2_list1@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

Max-Forwards: 68

P-Asserted-Identity: <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

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:

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

From:

To:

Call-ID:

CSeq:

Event:

Supported:

Expires:

Accept:

Contact:

Content-Length:

5. PSI location query

The I-CSCF sends a query to the HSS to find the RLS where sip:user2_list1@home2.net is hosted. The HSS responds with the address of the RLS.

For detailed message flows see 3GPP TS 29.228 [10].

Table A.3.3.2-5a provides the parameters in the SIP SUBSCRIBE request (flow 4), which are sent to the HSS.

Table A.3.3.2-5a Cx: User location query procedure (I-CSCF to HSS)

Message source & destination	Cx: Information element name	Information source in SIP SUBSCRIBE	Description
I-CSCF to HSS	User Public Identity	Request-URI:	This information element indicates the PSI of the RLS

Table A.3.3.2-5b provides the parameters sent from the HSS that need to be mapped to SIP SUBSCRIBE (flow 6) and sent to S-CSCF.

Table A.3.3.2-5b Cx: User location query procedure (HSS to I-CSCF)

Message source & destination	Cx: Information element name	Mapping to SIP header in SIP SUBSCRIBE	Description
HSS to I-CSCF	S-CSCF name	Route header field	This information indicates the address of the RLS

6. SUBSCRIBE request (I-CSCF to RLS) – see example in table A.3.3.2-6

The I-CSCF forwards the SUBSCRIBE request to the RLS.

Table A.3.3.2-6: SUBSCRIBE request (I-CSCF to S-CSCF)

SUBSCRIBE sip:user2_list1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

Max-Forwards: 67

P-Asserted-Identity:

P-Charging-Vector:

Privacy:

Record-Route:

Route: <sip:rls.home2.net;lr>

From:

To:

Call-ID:

CSeq:

Event:

Supported:

Expires:

Accept:

Contact:

Content-Length:

7. Authorization of watcher

8. 200 (OK) response (RLS to I-CSCF) – see example in table A.3.3.2-8

The RLS sends the response to the S-CSCF.

Table A.3.3.2-8: 200 (OK) response (RLS to I-CSCF)

SIP/2.0 200 OK

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=home1.net; term-ioi=home2.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]

Record-Route:

From:

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

Call-ID:

CSeq:

Require: eventlist

Expires:

Contact: <sip:rls.home2.net>

Content-Length: 0

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

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

The I-CSCF forwards the response to the S-CSCF.

Table A.3.3.2-9: 200 (OK) response (I-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

P-Charging-Vector:

Record-Route:

From:

To:

Call-ID:

CSeq:

Require:

Expires:

Contact:

Content-Length: 0

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

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

The S-CSCF forwards the response to the P-CSCF.

Table A.3.3.2-10: 200 (OK) response (S-CSCF to P-CSCF)

SIP/2.0 200 OK

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

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

Record-Route:

From:

To:

Call-ID:

CSeq:

Require:

Expires:

Contact:

Content-Length:

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

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

The P-CSCF forwards the response to the watcher agent in the UE.

Table A.3.3.2-11: 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=z9hG4bKehuefdam

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

From:

To:

Call-ID:

CSeq:

Require:

Expires:

Contact:

Content-Length:

12. NOTIFY request (RLS to S-CSCF) – see example in table A.3.3.2-12

The RLS generates a NOTIFY request including the RLMI document as a result of the SUBSCRIBE request.

Table A.3.3.2-12: 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.home2.net;branch=z9hG4bK240f34.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:user2_list1@home1.net>;tag=151170

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 89 NOTIFY

Subscription-State: active;expires=5000

Require: eventlist

Event: presence

Contact: <sip:rls.home1.net>

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

Content-Length: (…)

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

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

uri="sip:user1_list1@home1.net" version="1" fullState="true">

<name>Kovacs Janos</name>

</resource>

<name>Szabo Bela</name>

</resource>

</list>

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.

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

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

Table A.3.3.2-13: 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.home2.net;branch=z9hG4bK240f34.1

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

Max-Forwards: 69

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

Route: <sip:pcscf1.visited1.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 RLS populates the P-Charging-Function-Addresses header field to be passed to the I-CSCF.

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

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

Table A.3.3.2-14: 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.home2.net;branch=z9hG4bK240f34.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:

Require:

Event: Contact:

Content-Type:

Content-Length:

(…)

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

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

Table A.3.3.2-15: 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.home2.net;branch=z9hG4bK240f34.1

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

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

Table A.3.3.2-16: 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.home2.net;branch=z9hG4bK240f34.1

P-Access-Network-Info:

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

From:

To:

Call-ID:

CSeq:

Content-Length:

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

The S-CSCF#1 forwards the response to the RLS in the home network of the UE.

Table A.3.3.2-17: 200 (OK) response (S-CSCF to RLS)

SIP/2.0 200 OK

Via: SP/2.0/UDP rls.home2.net;branch=z9hG4bK240f34.1

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

From:

To:

Call-ID:

CSeq:

Content-Length:

18. Subscriptions and notifications on presence event package

After the RLS generated a 200 (OK) response to the SUBSCRIBE request from the UE, it generates the necessary SUBSCRIBE requests to the presentities present in the resource list as described in subclause A.3.4.1. As soon as it receives NOTIFY request(s) about a state change in one or more presentities, it generates a NOTIFY request.

19. NOTIFY request (RLS to S-CSCF) – see example in table A.3.3.2-19

The RLS copies the body of the incoming NOTIFY request(s) into the body of the outgoing NOTIFY request using MIME type multipart/related. Further notification sent by the RLS contain may contain either the full or the partial set of presence information (only the presence information that has changed since the last notification) as described in RFC 4662 [22].

In this example it is assumed that the RLS receives two NOTIFY requests from presentities sip:user2_public1@home2.net and sip:user3_public1@home3.net before generating the NOTIFY request in subclause A.3.3.2-23 to the UE.

Table A.3.3.2-19: 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.home2.net;branch=z9hG4bK240f34.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:user2_list1@home1.net>;tag=151170

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 89 NOTIFY

Subscription-State: active;expires=5000

Require: eventlist

Event: presence

Contact: <sip:rls.home2.net>

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

start="<nXYxAE@rls.home2.net>";boundary="50UBfW7LSCVLtggUPe5z"

Content-Length: (…)

–50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <nXYxAE@rls.home2.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="1" fullState="true">

<name>Kovacs Janos</name>

</resource>

<name>Szabo Bela</name>

</resource>

</list>

–50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <ZvSvkz@rls.home2.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:pidfcaps"

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>

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

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

</dm:person>

</presence>

–50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <ZvSvkz@pres.example.com>

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"

entity="pres:user3_public1@home3.net">

<basic>closed</basic>

</status>

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

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

<pcp:servcaps>

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

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

</pcp:servcaps>

<contact priority="0.8">sip:user3_public1@home3.net</contact>

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

<note xml:lang="hu">Senki se merjen zavarni!</note>

</tuple>

</status>

<rpid:class>supervisor</rpid:class>

<rpid:relationship><rpid:supervisor/></rpid:relationship>

<note xml:lang="en">He’s my supervisor</note>

</tuple>

<dm:person>

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

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

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

<rpid:activities><rpid:vacation/></rpid:activities>

<rpid:place-type until="2003-09-10T17:30:00Z"><rpid:ship/></rpid:place-type>

</dm:person>

</presence>

–50UBfW7LSCVLtggUPe5z–

Content-Type: Set to the value of the Accept: header received in the SUBSCRIBE request.

The message body in the NOTIFY request that carries the presence information of the presentity is formed as indicated in RFC 4662 [22], RFC 4479 [44], RFC 4480 [26], RFC 4482 [32] and RFC 5196 [25].

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

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

Table A.3.3.2-20: 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.home2.net;branch=z9hG4bK240f34.1

Max-Forwards: 69

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:4ee]; 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:

Require:

Event:

Contact:

Content-Type:

Content-Length:

(…)

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

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

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

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

Table A.3.3.2-21: 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.1SIP/2.0/UDP rls.home2.net;branch=z9hG4bK240f34.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:

Require:

Event:

Contact:

Content-Type:

Content-Length:

(…)

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

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

Table A.3.3.2-22: 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.1SIP/2.0/UDP rls.home2.net;branch=z9hG4bK240f34.1

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

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

Table A.3.3.2-23: 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.home2.net;branch=z9hG4bK240f34.1

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024", orig-ioi=hom1.net, term-ioi=visited1.net

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Length:

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

The S-CSCF#2 forwards the response to the RLS in the home network of the UE.

Table A.3.3.2-24: 200 (OK) response (S-CSCF to RLS)

SIP/2.0 200 OK

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

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

From:

To:

Call-ID:

CSeq:

Content-Length:

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

A.3.4 RLS subscribing to presentities in different network

A.3.4.1 Successful subscription

Figure A.3.4.1-1 RLS subscribing to presentities in different network

Figure A.3.4.1-1 shows the RLS subscribing to presence event notification about a presentity. The presentity is in a different IM CN subsystem. The details of the signalling flows are as follows:

1. SUBSCRIBE request (RLS to S-CSCF) – see example in table A.3.4.1-1

The RLS resolves the watcher’s resource address (the address is received according to subclause A.3.3) and subscribes to presence event notification at all the presentities that are represented by the resource list SIP URI. The home network of these presentities can be different or in the same network, as the RLS. In this example only a single subscription is shown where the home network of the presentity is another network. Subscriptions to other presentities follow a similar procedure. To initiate a subscription, the RLS generates a SUBSCRIBE request containing the "presence" event that it wishes to be notified of, together with an indication of the length of time this periodic subscription should last. The RLS sends the SUBSCRIBE request to the S-CSCF of "sip:user1_public1@home1.net" (S-CSCF#1). The address of S-CSCF#1 is either remembered from previous transactions (when "sip:user1_public1@home1.net" has subscribed for the resource list) or queried by the RLS using the Sh interface.

Table A.3.4.1-1 SUBSCRIBE request (RLS to S-CSCF)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

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

Max-Forwards: 70

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

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

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

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

To: <sip:user2_public1@home2.net>

Call-ID: q987a9a87g087abgf7qyg7ag

CSeq: 123 SUBSCRIBE

Event: presence

Expires: 7200

Accept: application/pidf+xml

Contact: <sip:rls.home1.net>

Content-Length: 0

Request-URI: Public user identity whose events the RLS subscribes to.

P-Charging-Vector: The RLS populates the icid parameter with a new globally unique value and populates the originating Inter Operator Identifier (IOI) parameter with the identifier of its own network of RLS.

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

To: Same as the Request-URI.

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

Accept: This field is populated with the value "application/pidf+xml".

2. Evaluation of initial filter criteria

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criteria. In this example, no AS is assumed to be involved.

3. SUBSCRIBE request (S-CSCF to I-CSCF) – see example in table A.3.4.1-3

S-CSCF#1 performs an analysis of the destination address, and determines the network operator to whom the destination subscriber belongs. S-CSCF#1 forwards the request to the I-CSCF.

Table A.3.4.1-3 SUBSCRIBE request (S-CSCF to I-CSCF)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bKehuehjgt, SIP/2.0/UDP rls.home1.net;branch=z9hG4bKehuefdam

Max-Forwards: 69

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

P-Asserted-Identity:

P-Charging-Vector:

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

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

4. Cx: User Location Query procedure

The I-CSCF sends a query to the HSS to find out the S-CSCF of the presentity. The HSS responds with the address of the current S-CSCF for the presentity.

For detailed message flows see 3GPP TS 29.228 [10].

Table A.3.4.1-4a provides the parameters in the SIP SUBSCRIBE request (flow 3), which are sent to the HSS.

Table A.3.4.1-4a: Cx: User location query procedure (I-CSCF to HSS)

Message source and destination	Cx: Information element name	Information source in SIP SUBSCRIBE	Description
I-CSCF to HSS	User Public Identity	Request-URI	This information element indicates the public user identity

Table A.3.4.1-4b provides the parameters sent from the HSS that need to be mapped to SIP SUBSCRIBE request (flow 5) and sent to the S-CSCF.

Table A.3.4.1-4b: Cx: User location query procedure (HSS to I-CSCF)

Message source and destination	Cx: Information element name	Mapping to SIP header in SIP SUBSCRIBE	Description
HSS to I-CSCF	S-CSCF name	Route header field	This information indicates the serving CSCF’s name of that user

5. SUBSCRIBE request (I-CSCF to S-CSCF) – see example in table A.3.4.1-5

The I-CSCF forwards the SUBSCRIBE request to the S-CSCF#2 that will handle the termination.

Table A.3.4.1-5: SUBSCRIBE request (I-CSCF to S-CSCF)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bKj5hgrt2o, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bKehuehjgt, SIP/2.0/UDP rls.home1.net;branch=z9hG4bKehuefdam

Max-Forwards: 68

P-Asserted-Identity:

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

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

Record-Route:

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

6. Evaluation of initial filter criteria

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criteria. For sip:user2_public1@home2.net the S-CSCF has Termination initial Filter Criteria with Service Point Trigger of Method = SUBSCRIBE AND Event = "presence" that informs the S-CSCF to route the SUBSCRIBE request to the AS ps.home2.net. The S-CSCF#2 has preconfigured information not to create a Record-Route entry for this request.

7. SUBSCRIBE request (S-CSCF to PS) – see example in table A.3.4.1-7

The S-CSCF#2 forwards the SUBSCRIBE request to the PS.

Table A.3.4.1-7 SUBSCRIBE request (S-CSCF to PS)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bKj5hgrt2o, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bKehuehjgt, SIP/2.0/UDP rls.home1.net;branch=z9hG4bKehuefdam

Max-Forwards: 67

P-Asserted-Identity:

P-Charging-Vector:

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:ps.home2.net;lr>, <sip:scscf2.home2.net;lr>

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

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

8. Authorization of watcher

In the case where the privacy/authorization checks fails, then a necessary 2xx or 4xx response will be sent to the S-CSCF. The selection of the correct response code depends on the presentity’s subscription authorization policy document.

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

The PS sends the response to S-CSCF#2.

Table A.3.4.1-9: 200 (OK) response (PS to S-CSCF)

SIP/2.0 200 OK

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

Record-Route:

From:

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

Call-ID:

CSeq:

Expires:

Contact: <sip:ps.home2.net;lr>

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.

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

S-CSCF#2 forwards the response to the I-CSCF.

Table A.3.4.1-10: 200 (OK) response (S-CSCF to I-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bKj5hgrt2o, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bKehuehjgt, SIP/2.0/UDP rls.home1.net;branch=z9hG4bKehuefdam

P-Charging-Vector:

P-Charging-Function-Addresses:

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

P-Charging-Vector: The S-CSCF stores the terminating Inter Operator Identifier (IOI) parameter received and populates the identifier of its own network to the terminating 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 I-CSCF.

11. 200 (OK) response (I-CSCF to S-CSCF) – see example in table A.3.4.1-11

The I-CSCF forwards the response to S-CSCF#1.

Table A.3.4.1-11: 200 (OK) response (I-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bKehuehjgt, SIP/2.0/UDP rls.home1.net;branch=z9hG4bKehuefdam

P-Charging-Vector:

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

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

Table A.3.4.1-12: 200 (OK) response (S-CSCF to RLS)

SIP/2.0 200 OK

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

P-Charging-Vector:

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]

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

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

Table A.3.4.1-13: NOTIFY request (PS to S-CSCF)

NOTIFY sip:rls.home1.net SIP/2.0

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

Max-Forwards: 70

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

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

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

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

Call-ID: q987a9a87g087abgf7qyg7ag

CSeq: 42 NOTIFY

Subscription-State:active;expires=7200

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

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

</dm:person>

</presence>

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.

Content-Type: Set to the value of the Accept header received in the SUBSCRIBE request or "application/pidf+xml".

The message body in the NOTIFY request that carries the presentity’s presence state is formed as indicated in RFC 3863 [21], RFC 4479 [44], RFC 4480 [26], RFC 4482 [32] and RFC 5196 [25].

14. NOTIFY request (S-CSCF to RLS) – see example in table A.3.4.1-14

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

Table A.3.4.1-14: 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 ps.home2.net;branch=z9hG4bK348923.1

Max-Forwards: 69

P-Charging-Vector:

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]

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

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

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

Table A.3.4.1-15: 200 (OK) response (RLS to S-CSCF)

SIP/2.0 200 OK

Via:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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

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

Table A.3.4.1-16: 200 (OK) response (S-CSCF to PS)

SIP/2.0 200 OK

P-Charging-Vector:

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

From:

To:

Call-ID:

CSeq:

Content-Length: 0

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.

A.3.5 Network based watcher subscribing on behalf of IMS watcher to IMS presentities

Figure A.3.5-1: Network based watcher subscribing on behalf of IMS watcher
for presence information of IMS presentities

Figure A.3.5-1 shows a trusted network based watcher subscribing on behalf of an IMS watcher to presence event notification about an IMS based presentity. The presentity is in a different IM CN subsystem than the network based watcher and the signalling flow assumes that the IMS watcher on whose behalf the network based watcher subscribes is registered to the IMS network. The details of the signalling flows are as follows:

1. Sh: User Location Query procedure

The network based watcher sends a query to the HSS to find out the S-CSCF of the user on whose behalf the subscription is initiated. The HSS responds with the address of the current S-CSCF for the originating subscriber.

2. SUBSCRIBE request (Network based watcher to S-CSCF) – see example in table A.3.5-2

The SUBSCRIBE request is constructed and forwarded to S-CSCF. The S-CSCF is inserted into the Route header of the SUBSCRIBE request.

Table A.3.5-2: SUBSCRIBE request (network watcher to S-CSCF)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

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

P-Access-Network-Info:

Max-Forwards: 69

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

Privacy: none

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

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

To: <sip:user2_public1@home2.net>

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 61 SUBSCRIBE

Event:PRESENCE

Expires: 7200

Accept: application/pidf+xml;q=0.3, application/pidf-diff+xml;q=1

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

Content-Length: 0

Request-URI: Public user identity of the user to whose events the subscriber subscribes to.

P-Asserted-Identity: The network based watcher inserts the public user identity of the watcher on whose behalf the subscription is made into the P-Asserted-Identity header field.

Route: The Route header is populated with the address of the S-CSCF obtained from the response to the user location query performed by the network based watcher on the Sh interface.

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

Contact: The contact information of the network based watcher.

3. Evaluation of initial filter criteria

S-CSCF#1 validates the service profile of the subscriber identified in the P-Asserted-Identity header field and evaluates the initial filter criteria. In this example, no AS is assumed to be involved.

4. SUBSCRIBE request (S-CSCF to I-CSCF) – see example in table A.3.5-4

Table A.3.5-4: SUBSCRIBE (S-CSCF to I-CSCF)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP network.home1.net;branch=z9hG4bK240f34.1,

Max-Forwards: 68

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

Privacy:

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

5. Cx: User Location Query procedure

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the address of the current S-CSCF for the terminating subscriber.

For detailed message flows see 3GPP TS 29.228 [10].

Table A.3.5-5a provides the parameters in the SIP SUBSCRIBE request (flow 4), which are sent to the HSS.

Table A.3.5-5a: Cx: User registration location procedure (I-CSCF to HSS)

Message source and destination	Cx: Information element name	Information source in SIP SUBSCRIBE	Description
I-CSCF to HSS	User Public Identity	Request-URI	This information element indicates the public user identity

Table A.3.5-5b provides the parameters sent from the HSS that need to be mapped to the SIP SUBSCRIBE request (flow 6) and sent to the S-CSCF.

Table A.3.5-5b: Cx: User location query procedure (HSS to I-CSCF)

Message source and destination	Cx: Information element name	Mapping to SIP header in SIP SUBSCRIBE	Description
HSS to I-CSCF	S-CSCF name	Route header field	This information indicates the serving CSCF’s name of that user

6. SUBSCRIBE request (I-CSCF to S-CSCF) – see example in table A.3.5-6

The I-CSCF forwards the SUBSCRIBE request to the S-CSCF (S-CSCF#2) that will handle the termination.

Table A.3.5-6: SUBSCRIBE request (I-CSCF to S-CSCF)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP network.home1.net;branch=z9hG4bK240f34.1

Max-Forwards: 67

P-Asserted-Identity:

Privacy:

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

Record-Route:

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling path for the subsequent requests.

7. Evaluation of initial filter criteria

8. SUBSCRIBE request (S-CSCF to PS) – see example in table A.3.5-8

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

Table A.3.5-8: SUBSCRIBE request (S-CSCF to PS)

SUBSCRIBE sip:user2_public1@home2.net SIP/2.0

Max-Forwards: 66

P-Asserted-Identity:

Privacy:

Route: <sip:ps.home2.net;lr>, <sip:scscf2.home2.net;lr>

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

From:

To:

Call-ID:

CSeq:

Event:

Expires:

Accept:

Contact:

Content-Length:

9. Authorization of watcher

The PS performs the necessary authorization checks on the watcher whose behalf the subscription is being made to ensure it is allowed to watch the presentity. In this example all privacy conditions are met, so the PS sends a 200 (OK) response to the S-CSCF.

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

The PS sends the response to S-CSCF#2.

Table A.3.5-10: 200 (OK) response (PS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2.0/UDP

icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP network.home1.net;branch=z9hG4bK240f34.1

Record-Route:

From:

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

Call-ID:

CSeq:

Expires:

Contact: <sip:ps.home2.net>

Content-Length:

11. 200 (OK) response (S-CSCF to I-CSCF) – see example in table A.3.5-11

S-CSCF#2 forwards the response to I-CSCF#2.

Table A.3.5-11: 200 (OK) response (S-CSCF to I-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP icscf2_s.home2.net;branch=z9hG4bK871y12.1, SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP network.home1.net;branch=z9hG4bK240f34.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

I-CSCF#2 forwards the response to S-CSCF#1.

Table A.3.5-12: 200 (OK) response (I-CSCF to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK351g45.1, SIP/2.0/UDP network.home1.net;branch=z9hG4bK240f34.1

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

13. 200 (OK) response (S-CSCF to network watcher) – see example in table A.3.5-13

S-CSCF#1 forwards the response to request originator.

Table A.3.5-13: 200 (OK) response (S-CSCF to network watcher)

SIP/2.0 200 OK

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

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

Table A.3.5-14: NOTIFY request (PS to S-CSCF)

NOTIFY sip: network.home1.net;branch=z9hG4bK240f34.1 SIP/2.0

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

Max-Forwards: 70

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

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

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 42 NOTIFY

Subscription-State: active; expires=7200

Event: presence

Contact: <sip:ps.home2.net>

Content-Type: application/pidf-diff +xml

Content-Length: (…)

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

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

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

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

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"version="1">

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

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

</status>

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

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

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

</dm:person>

</diff:pidf-full>

From: The tag of this field matches that of the To field in the received 200 (OK) response for the SUBSCRIBE request.

Content-Type: Set to the preferred value of the Accept header received in the SUBSCRIBE request.

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 4482 [32], RFC 5196 [25], RFC 4479 [44] and RFC 5263 [24].

15. NOTIFY request (S-CSCF to network watcher) – see example in table A.3.5-15

The S-CSCF#1 forwards the NOTIFY request to the network watcher

Table A.3.5-15: NOTIFY request (S-CSCF to network watcher)

NOTIFY sip: network.home1.net;branch=z9hG4bK240f34.1SIP/2.0

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

Max-Forwards: 69

Privacy:

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Type:

Content-Length:

(…)

16. 200 (OK) response (network watcher to S-CSCF) – see example in table A.3.5-16

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

Table A.3.5-16: 200 (OK) response (network watcher to S-CSCF)

SIP/2.0 200 OK

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

P-Access-Network-Info:

From:

To:

Call-ID:

CSeq:

Content-Length:

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

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

Table A.3.5-17: 200 (OK) response (S-CSCF to PS)

SIP/2.0 200 OK

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

From:

To:

Call-ID:

CSeq:

Content-Length:

A.3.6 Watcher subscribing to state changes in XML document, UE in visited network

A.3.6.1 Watcher subscribing to changes made via XCAP in his resource list, UE in visited network – Successful subscription

Figure A.3.6.1-1: Watcher subscribing to changes made via XCAP in his resource list

Figure A.3.6.1-1 shows a watcher subscribing to notifications of state changes made via XCAP in his resource list. The details of the flows as follows:

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

A watcher agent in a UE wishes to get notification when his resource list gets modified via XCAP. In order to initiate a subscription to XCAP document changes in RLS, the UE generates a SUBSCRIBE request indicating support for "xcap-diff", together with an indication of the length of time this periodic subscription should last.

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

SUBSCRIBE sip:user1_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

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: 123 SUBSCRIBE

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: xcap-diff;diff-processing=aggregate

Expires: 7200

Accept: application/xcap-diff+xml

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

Content-Type: application/resource-lists+xml

Content-Length: (…)

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

<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">

<list>

</list>

</resource-lists>

Request-URI: The users own SIP URI to get notifications of changes on all lists owned by the user.

Event: This field is populated with the value "xcap-diff" to specify the use of the xcap-diff package to get notified of changes to XCAP documents.

Accept: This field is populated with the value "application/xcap-diff+xml" indicating that the UE supports the MIME type.

To: Same as the Request-URI.

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

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

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

SUBSCRIBE sip:user1_public1@home1.net SIP/2.0

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

P-Access-Network-Info:

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

Max-Forwards: 69

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

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

Privacy:

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

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

From:

To:

Call-ID:

CSeq:

Event:

Supported:

Expires:

Accept:

Contact:

Content-Type:

Content-Length:

(…)

3. Evaluation of initial filter criteria

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. For sip:user1_public1@home1.net the S-CSCF has originating initial Filter Criteria with Service Point Trigger of Method = SUBSCRIBE AND Event = "xcap-diff" that informs the S-CSCF to route the SUBSCRIBE request to the AS sip:rls.home1.net.

4. SUBSCRIBE request (S-CSCF to RLS) – see example in table A.3.6.1-4

The S-CSCF forwards the SUBSCRIBE request to the RLS.

Table A.3.6.1-4 SUBSCRIBE request (S-CSCF to RLS)

SUBSCRIBE sip:user1_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

Max-Forwards: 68

P-Access-Network-Info:

P-Asserted-Identity: <sip:user1_public1@home1.net>, <tel:+1-212-555-1111>

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

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

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

From:

To:

Call-ID:

CSeq:

Event:

Supported:

Expires:

Accept:

Contact:

Content-Type:

Content-Length:

(…)

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

5. Authorization

The RLS performs the necessary authorization checks on the originator to ensure that he/she is authorized to subscribe to XML document changes. In this example this condition has been met, so the RLS sends a 200 (OK) response to the S-CSCF.

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

The RLS sends the response to the S-CSCF.

Table A.3.6.1-6: 200 (OK) response (RLS to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK120f34.1, SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKehuefdam

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

Record-Route:

From:

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

Call-ID:

CSeq:

Expires:

Contact:

Content-Length: 0

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

The S-CSCF forwards the response to the P-CSCF.

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

SIP/2.0 200 OK

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

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

Record-Route:

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

The P-CSCF forwards the response to the watcher agent in the UE.

Table A.3.6.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=z9hG4bKehuefdam

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

From:

To:

Call-ID:

CSeq:

Expires:

Contact:

Content-Length:

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

The RLS generates a NOTIFY request including the xcap-diff document as a result of the SUBSCRIBE request. As this is the initial NOTIFY it contains only the new-etag, previous-etag and document-selector elements.

Table A.3.6.1-9 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=323551024"; 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_@home1.net>;tag=151170

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 89 NOTIFY

Subscription-State: active;expires=7200

Event: xcap-diff

Contact: <sip:rls.home1.net>

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

Content-Length:

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

<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"

xcap-root="http://xcap.home1.net/services">

<document doc-selector="resource-lists/users/user1/friends"

new-etag="7hahsd"/>

</document>

<document doc-selector="resource-lists/users/user1/coworkers"

new-etag="ffds66a">

</document>

</xcap-diff>

The content of the document element contains a new-etag and a previous etag element with identical value and no list of instructions. This way it is indicated that this is the reference XML diff document. This documents has only the information about the etags and the document URI’s covered by that subscription.

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

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

Table A.3.6.1-10: 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=323551024"

P-Charging-Function-Addresses:

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

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

From:

To:

Call-ID:

CSeq:

Subscription-State:

Event:

Contact:

Content-Length:

(…)

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

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

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

Event:

Contact:

Content-Length:

(…)

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

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

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

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

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

Table A.3.6.1-13: 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=323551024"

From:

To:

Call-ID:

CSeq:

Content-Length:

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

The S-CSCF#2 forwards the response to the RLS in the home network of the UE.

Table A.3.6.1-14: 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=323551024"; orig-ioi=home1.net; term-ioi=home1.net

From:

To:

Call-ID:

CSeq:

Content-Length:

15. User retrieves current resource list via XCAP get

As user1 does not have a local copy of the resource list identified by the etag he retrieves the corresponding list via XCAP get.

16. Resource List gets modified via XCAP

The resource list of user1 gets modified via XCAP procedures.

17. NOTIFY request (RLS to S-CSCF) – see example in table A.3.6.1-17

In this example it is assumed that the RLS has received a XCAP request to delete user2_public@home1.net from the resource list of user1.

Table A.3.6.1-17 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=423551024"; 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_public1@home1.net>;tag=151170

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

Call-ID: b89rjhnedlrfjflslj40a222

CSeq: 90 NOTIFY

Subscription-State: active;expires=5000

Event: xcap-diff

Contact: <sip:rls.home1.net>

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

Content-Length: (…)

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

<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"

xcap-root="http://xcap.home1.net/services">

<document doc-selector="resource-lists/users/user1/coworkers"

new-etag="aaaab" previous-etag="ffds66a">

<change-log>

<put-eventnode-selector="resource-lists/list[@name="coworkers"]" content-type="application/el+xml">

<![CDATA[<entry uri="sip:new-worker@example.com"/>]]>

</put-event>

</change-log>

</document>

</xcap-diff>

Content-Type: Set to application/xcap-diff+xml.

The message body in the NOTIFY request contains information of the new-etag of the changed document, the change method and the element that was changed in accordance with RFC 5874 [39].

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

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

Table A.3.6.1-18: 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=423551024"

P-Charging-Function-Addresses:

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:

(…)

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

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

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

Content-Type:

Content-Length:

(…)

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

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

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

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

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

Table A.3.6.1-21: 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=423551024"

From:

To:

Call-ID:

CSeq:

Content-Length:

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

The S-CSCF#2 forwards the response to the RLS in the home network of the UE.

Table A.3.6.1-22: 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=423551024"; orig-ioi=home1.net; term-ioi=home1.net

From:

To:

Call-ID:

CSeq:

Content-Length: