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