A.7 PNA subscription for the reg-event package

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

Figure A.7-1 shows the registration signalling flow for the scenario when the user is not registered. For the purpose of this registration signalling flow, the subscriber is considered to be roaming. This signalling flow also shows the authentication of the private user identity.

This is followed by the subscription procedure for the reg-event package, whereby the PNA requests to be notified by the S-CSCF when a registration event has occurred. This is done using the ‘reg-event’ package as described in 3GPP TS 24.229 [9].

Figure A.7-1: Registration signalling: user not registered

1-22. See 3GPP TS 24.228 [8], subclause 6.2 steps 1 through 22

23. Initial filter criteria

The S-CSCF analyses the incoming request against the initial filter criteria and decides to send a third-party REGISTER request to the PNA.

24. REGISTER request (S-CSCF to PNA) – see example in table A.7-24

This signalling flow forwards the REGISTER request from the S-CSCF to the PNA.

Table A.7-24: REGISTER request (S-CSCF to PNA)

REGISTER sip:ps.home1.net SIP/2.0

Via: SIP/2.0/UDP sip:scscf1.home1.net

Max-Forwards: 70

P-Access-Network-Info:

P-Visited-Network-ID:

P-Charging-Vector:

P-Charging-Function-Addresses:

From: sip:scscf1.home1.net

To: <sip:user1_public1@home1.net>

Contact: <sip:scscf1.home1.net>

Expires: 600000

Call-ID: apb03a0s09dkjdfglkj49112

CSeq: 43 REGISTER

Content-Length: 0

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

The PNA sends a 200 (OK) response to the S-CSCF indicating that Registration was successful.

Table A.7-25: 200 OK response (PNA to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP sip:scscf1.home1.net

From:

To:

Call-ID:

Contact: <sip:scscf1.home1.net>;expires=600000

CSeq:

Date: Wed, 11 July 2001 08:49:37 GMT

Content-Length:

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

The PNA sends the SUBSCRIBE request for the reg event package.

Table A.7-26: SUBSCRIBE request (PNA to S-CSCF)

SUBSCRIBE sip:user1_public1@home1.net SIP/2.0

Via: SIP/2.0/UDP sip:ps.home1.net

Max-Forwards: 70

P-Asserted-Identity: <sip:ps.home1.net>

Privacy: none

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

To: <sip:user1_public1@home1.net>

Call-ID: dre36d2v32gnlgiiomm72445

CSeq: 61 SUBSCRIBE

Event: reg

Expires: 600000

Accept: application/reginfo+xml

Contact: <sip:ps.home1.net>

Content-Length: 0

From: This header is populated with the SIP URI that identifies the PNA.

Contact: This is where the NOTIFY requests for this subscription will be sent.

Event: This field is set to the value ‘reg’ to specify the use of the reg event package.

Accept: This field is set to the value "application/reginfo+xml".

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

The S-CSCF sends a 200 (OK) response to the PNA indicating that registration was successful.

Table A.7-27: 200 (OK) response (S-CSCF to PNA)

SIP/2.0 200 OK

Via: SIP/2.0/UDP sip:ps.home1.net

P-Asserted-Identity: <sip:scscf1.home1.net>

Privacy:

From:

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

Call-ID:

CSeq:

Contact: <sip:scscf1.home1.net>

Expires:

Content-Length:

Expires: If value of the Expires header in SUBSCRIBE request is different from the one received in REGISTER method, then the value of Expires header in the 200 (OK) response is set to match the value of Expires header in REGISTER method.

28. NOTIFY request (S-CSCF to PNA) – see example in table A.7-28

The S-CSCF sends a first NOTIFY request towards the PNA in order to inform the PNA about the registration status of monitored user.

Table A.7-28: NOTIFY request (S-CSCF to PNA)

NOTIFY sip:pcscf1.visited1.net SIP/2.0

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 70

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

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

Call-ID: dre36d2v32gnlgiiomm72445

CSeq: 42 NOTIFY

Subscription-State: active;expires=600000

Event: reg

Content-Type: application/reginfo+xml

Contact: <sip:scscf1.home1.net>

Content-Length: (…)

<?xml version="1.0"?>

<reginfo xmlns="urn:ietf:params:xml:ns:reginfo"

version="1" state="full">

<registration aor="sip:user1_public1@home1.net" id="a7" state="active">

<contact id="76" state="active" event="registered">

<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>

</contact>

</registration>

<registration aor="sip:user1_public2@home1.net" id="a8" state="active">

<contact id="77" state="active" event="created">

<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>

</contact>

</registration>

<registration aor="tel:+358504821437" id="a9" state="active">

<contact id="78" state="active" event="created">

<uri>sip:[5555::aaa:bbb:ccc:ddd]</uri>

</contact>

</registration>

</reginfo>

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 value of the Accept header received in the SUBSCRIBE request or "application/reginfo+xml" if the Accept header was not present in the SUBSCRIBE request.

The message body in the NOTIFY request that carries the subscriber’s registration state is formed as indicated in 3GPP TS 24.229 [9].

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

PNA sends the 200 (OK) response to the S-CSCF.

Table A.7-29: 200 (OK) response (PNA to S-CSCF)

SIP/2.0 200 OK

Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bK332b23.1

From:

To:

Call-ID:

CSeq:

Content-Type:

Content-Length: 0