3GPP TS 24.228 -- IMS Signalling flows for Register
|
|
|
|
|
|
|
| Session Initiation: Non Hiding |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| Session Initiation: Hiding |
| |
|
| |
|
| |
|
| |
|
| | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
This example describes the subscription procedure for the registration state event , whereby the UE requests to be
notified by the S-CSCF when the event has occurred.
| |
| - |
It is assumed that the user has registered prior to initiating subscription of an event.
For this example the trigger point at the P-CSCF for sending out the SUBSCRIBE
request is the 200 (OK) response of the user's registration.
|
|
|
|
|
|
|
|
| - |
Route:
Contains the P-CSCF address learnt during P-CSCF discovery, plus the elements from the
Service-Route header from registration. The P-CSCF URI contains the port number learnt
during the security agreement negotiation.
| |
| - |
Event:
This field is populated with the value "reg" to specify the use of the registration state package.
| |
| - |
Accept:
This field is populated with the value "application/reginfo+xml".
| |
| - |
Security-Verify:
Contains the security agreement as represented by the previously received Security-Server header.
|
|
|
|
|
|
|
|
| - |
P-CSCF1 removes the Security-Verify header and associated "sec-agree" option-tags prior to
forwarding the request. As the Require and Proxy-Require headers are empty, it removes these headers
completely.
| |
| - |
P-Asserted-Identity:
P-CSCF1 inserts the SIP URI in the P-Asserted-Identity header field and it also removes
P-Preferred-Identity header field.
| |
| - |
P-Access-Network-Info:
This header contains information from the UE.
| |
| - |
P-Charging-Vector:
P-CSCF1 inserts this header and populates the icid parameters with a globally
unique value.
|
|
|
|
|
|
|
|
|
|
| - |
S-CSCF1 first authorizes the subscription. As S-CSCF1 can trust the content of the P-Asserted-Identity
header and <sip:user1_public1@home1.net> is on the list of the authorized users for the "reg"
event package stored by S-CSCF1, therefore S-CSCF1 sends an acknowledgement towards the UE
indicating that the subscription was successful. This response will traverse the path that the
SUBSCRIBE request took as described in the Via list.
|
|
|
|
|
|
|
|
| - |
Expires:
If the 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| - |
S-CSCF1 sends a first NOTIFY request towards UE1 in order to inform UE1 about the
registration status of the monitored user.
| |
| - |
In the example below, the NOTIFY request specifies the following public user identity as registered
(i.e. status=open): sip:user1_public1@home1.net, tel:+358504821437.
| |
| - |
The following public user identity has been deregistered (i.e. status=closed)
sip:user1_public2@home1.net. They are arranged in the preferred order of priority in this example.
|
|
|
|
|
|
|
|
| - |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
