A.11 Mobile Initiated De-Registration / 5GS
34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification
IMS de-registration is initiated on the UE. The SS waits for the UE to send a REGISTER request, in accordance with 3GPP TS 24.229 [7], clause 5.1.1.6.
Expected sequence:
Step |
Direction |
Message |
Comment |
|
UE |
SS |
|||
0A |
🡪 |
SUBSCRIBE |
Optional: The UE unsubscribes from one of its subscribed to event packages. |
|
0B |
🡨 |
200 OK |
If the UE sent SUBSCRIBE, the SS responds to SUBSCRIBE with 200 OK. |
|
0C |
🡨 |
NOTIFY |
If the UE sent SUBSCRIBE, the SS sends a final NOTIFY |
|
0D |
🡪 |
200 OK |
If the UE sent SUBSCRIBE, the UE responds to NOTIFY with 200 OK. |
|
1 |
🡪 |
REGISTER |
The UE sends a de-registration request for IMS services. |
|
2 |
🡨 |
200 OK |
The SS responds to REGISTER with 200 OK. |
|
Note 1: Steps 0A-0D may be repeated for any or all event packages subscribed to by the UE. It is the UE’s decision which unsubscriptions to perform. Note 2: The UE can send the 200 OK for NOTIFY (step 0D) after the REGISTER request (step 1) or even not send it at all. |
Specific message contents
SUBSCRIBE (step 0A)
Use the default message “SUBSCRIBE for reg-event package” in Annex A.1.4 of TS 34.229-1 [2] or “SUBSCRIBE for conference event package” in Annex A.5.1 of TS 34.229-1 [2] or “SUBSCRIBE for message-summary event package” in Annex A.6.1 of TS 34.229-1 [2], and with the following exceptions:
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
From |
||||
addr-spec |
Same as in original SUBSCRIBE that set up the corresponding subscription |
|||
tag |
Same as in original SUBSCRIBE that set up the corresponding subscription |
|||
To |
||||
addr-spec |
As specified in TS 34.229-1 [2] Annex A.1.4/A.5.1/A.6.1 |
|||
tag |
Same as in 200 OK for original SUBSCRIBE that set up the corresponding subscription |
|||
CSeq |
||||
value |
value of the previous SUBSCRIBE sent by the UE for this dialog incremented by one |
|||
method |
SUBSCRIBE |
|||
Expires |
||||
delta-seconds |
0 |
200 OK for SUBSCRIBE (step 0B)
Use the default message “200 OK for SUBSCRIBE” in Annex A.1.5, A.5.2 or A.6.3 of TS 34.229-1 [2], whatever appropriate, with the following exceptions:
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
To |
RFC 3261 [6] |
|||
addr-spec |
As specified in TS 34.229-1 [2] Annex A.1.4/A.5.1/A.6.1 |
|||
tag |
Same as in step 0A |
|||
Expires |
RFC 3261 [6] |
|||
delta-seconds |
0 |
NOTIFY (step 0C)
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Request-Line |
RFC 3261 [6] |
|||
Method |
NOTIFY |
|||
Request-URI |
UE’s contact address in SIP URI form, as provided in the Contact header within the SUBSCRIBE creating the dialog |
|||
SIP-Version |
SIP/2.0 |
|||
Via |
order of the parameters in this header must be like in this table |
RFC 3261 [6] |
||
via-param1: |
||||
sent-protocol |
SIP/2.0/UDP when using UDP or |
|||
sent-by |
IP address and protected server port of SS |
|||
via-branch |
value starting with ‘z9hG4bK’ (NOTE 1) |
|||
via-param2: |
||||
sent-protocol |
SIP/2.0/UDP when using UDP or |
|||
sent-by |
scscf.3gpp.org |
|||
via-branch |
value starting with ‘z9hG4bK’ (NOTE 1) |
|||
From |
RFC 3261 [6] |
|||
addr-spec |
same URI as received in the To header of the corresponding SUBSCRIBE message |
|||
tag |
same as to-tag in step 0A |
|||
To |
RFC 3261 [6] |
|||
addr-spec |
same URI as received in the From header of the corresponding SUBSCRIBE message |
|||
tag |
same as from-tag in step 0A |
|||
Call-ID |
RFC 3261 [6] |
|||
callid |
same as value received in SUBSCRIBE message |
|||
CSeq |
RFC 3261 [6] |
|||
value |
1 |
|||
method |
NOTIFY |
|||
Contact |
RFC 3261 [6] |
|||
addr-spec |
A1 |
<sip:scscf.3gpp.org> |
||
addr-spec |
A2 |
sip:final@conf-factory. appended with px_IMS_HomeDomainName |
||
addr-spec |
A3 |
<scscf.3gpp.org> |
||
Event |
RFC 6665 [28] |
|||
event-type |
A1 |
reg |
||
event-type |
A2 |
conference |
||
event-type |
A3 |
message-summary |
||
Max-Forwards |
RFC 3261 [6] |
|||
value |
69 |
|||
Subscription-State |
RFC 6665 [28] |
|||
substate-value |
terminated |
|||
Content-Length |
||||
value |
0 |
Condition |
Explanation |
A1 |
Final NOTIFY sent for reg-event |
A2 |
Final NOTIFY sent for conf-event |
A3 |
Final NOTIFY sent for message-summary |
NOTE 1: Branch parameter values sent by SS are different within a test case execution.
200 OK (step 0D)
Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in Annex A.3.1 of TS 34.229-1 [2].
REGISTER (step 1)
Use the default message “REGISTER” in Annex A.1.1 of TS 34.229-1 [1] with conditions A2 and A17 "UE initiated IMS re-registration or de-registration" with the following exceptions:
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Contact |
RFC 3261 [6] |
|||
addr-spec |
SIP URI with IP address or FQDN and protected server port of the UE, AND, +sip.instance="<urn:gsma:imei: (gsma-specifier-defined-substring)>”, OR |
|||
expires |
0 (if present) |
|||
Expires |
(must be present if addr-spec is *) |
RFC 3261 [6] |
||
delta-seconds |
0 (if present) |
|||
Supported |
header may be missing or it may contain any value |
|||
Authorization |
value not checked |
NOTE: In contrast to Annex A.1.1 of TS 34.229-1 [2], the Contact header does not have any further mandatory feature parameters.
200 OK (step 2)
Use the default message “200 OK for REGISTER” in Annex A.1.3 of TS 34.229-1 [2] with the following exceptions:
Header/param |
Cond |
Value/remark |
Rel |
Reference |
---|---|---|---|---|
Contact |
RFC 3261 [6] |
|||
addr-spec |
same value as in REGISTER request if "*" is not included in the Contact header field of the REGISTER request in step 1 |
|||
expires |
0 |
|||
NOTE: According to 3GPP TS 24.229 [7] clause 5.4.1.4.1 when the S-CSCF gets a wild-carded contact address for de-registration it shall include all de-registered contact addresses in the contact header of the 200 OK response ⇒ there is no “*” in DL |