5.4.5 Call release

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.4.5.1 S-CSCF-initiated session release

5.4.5.1.1 Cancellation of a session currently being established

Upon receipt of a network internal indication to release a session which is currently being established, the S-CSCF shall:

1) cancel the related dialogs by sending the CANCEL request according to the procedures described in RFC 3261 [26]; and

2) send an appropriate response to the sender of the original INVITE request.

5.4.5.1.2 Release of an existing session

Upon receipt of a network internal indication to release an existing multimedia session, the S-CSCF shall:

1) if the S-CSCF serves the calling user of the session, generate a BYE request destined for the called user based on the information saved for the related dialog, including:

– a Request-URI, set to the stored Contact header field provided by the called user;

– a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

– a From header field, set to the From header field value as received in the initial INVITE request;

– a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

– a CSeq header field, set to the CSeq value that was stored for the direction from the calling to the called user, incremented by one;

– a Route header field, set to the routeing information towards the called user as stored for the dialog;

– a Reason header field that contains proper SIP response code;

– further header fields, based on local policy;

– treat the BYE request as if received directly from the calling user, i.e. the S-CSCF shall send the BYE request to the internal service control and based on the outcome further on towards the called user; and

2) if the S-CSCF serves the calling user of the session, generate an additional BYE request destined for the calling user based on the information saved for the related dialog, including:

– a Request-URI, set to a contact address obtained from the stored Contact header field if provided by the calling user. If the stored Contact header field contained either a public or a temporary GRUU, the S-CSCF shall set the Request-URI either to:

a) the contact address bound to the respective GRUU, if the stored Contact header field did not include an "ob" SIP URI parameter; or

b) the contact address that the UE used to send the initial INVITE request, if the stored Contact header field included an "ob" SIP URI parameter;

NOTE 1: Since the same public GRUU can be bound to multiple contact addresses of the UE that were registered as specified in RFC 5626 [92], the S-CSCF selects the contact address that the UE used to send the initial INVITE request.

– a To header field, set to the From header field value as received in the initial INVITE request;

– a From header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

– a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;

– a CSeq header field, set to the CSeq value that was stored for the direction from the called to the calling user, incremented by one – if no CSeq value was stored for that session the S-CSCF shall generate and apply a random number within the valid range for CSeqs;

– a Route header field, set to the routeing information towards the calling user as stored for the dialog;

– a Reason header field that contains proper SIP response code;

– further header fields, based on local policy;

– send the BYE request directly to the calling user.

3) if the S-CSCF serves the called user of the session, generate a BYE request destined for the called user based on the information saved for the related dialog, including:

– a Request-URI, set to a contact address that the S-CSCF uses to send the in-dialog requests towards the called UE as defined in RFC 5626 [92] and RFC 5627 [93];

– a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE request;

– a From header, set to the From header value as received in the initial INVITE request;

– a Call-ID header, set to the Call-Id header value as received in the initial INVITE request;

– a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user, incremented by one;

– a Route header, set to the routeing information towards the called user as stored for the dialog;

– a Reason header that contains proper SIP response code;

– further headers, based on local policy;

– send the BYE request directly to the called user; and

4) if the S-CSCF serves the called user of the session, generate an additional BYE request destined for the calling user based on the information saved for the related dialog, including:

– a Request-URI, set to the stored Contact header field provided by the calling user;

– a To header, set to the From header field value as received in the initial INVITE request;

– a From header, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;

– a Call-ID header, set to the Call-Id header field value as received in the initial INVITE request;

– a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user, incremented by one – if no CSeq value was stored for that session the BYE shall generate and apply a random number within the valid range for CSeqs;

– a Route header field, set to the routeing information towards the calling user as stored for the dialog;

– a Reason header field that contains proper SIP response code;

– further headers, based on local policy;

– treat the BYE request as if received directly from the called user, i.e. the S-CSCF shall send the BYE request to the internal service control and based on the outcome further on towards the calling user..

Upon receipt of the 2xx responses for both BYE requests, the S-CSCF shall release all information related to the dialog and the related multimedia session.

5.4.5.1.2A Release of the existing dialogs due to registration expiration

When:

1) the registration lifetime of the only public user identity currently registered with its associated set of implicitly registered public user identities (i.e. no other is registered) and bound either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used) expires;

2) there are still active multimedia sessions that includes either this user’s contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used);

3) the session was initiated by or terminated towards the user using the public user identity currently registered or with one of the implicitly registered public used identities bound either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used);

then the S-CSCF shall:

– release each of these multimedia sessions by applying the steps listed in the subclause 5.4.5.1.2. The S-CSCF shall only release dialogs associated with the multi media sessions originated or terminated towards the registered user’s contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used).

5.4.5.1.3 Abnormal cases

Upon receipt of a request on a dialog for which the S-CSCF initiated session release, the S-CSCF shall terminate the received request and answer it with a 481 (Call/Transaction Does Not Exist) response.

5.4.5.2 Session release initiated by any other entity

Upon receipt of a 2xx response for a BYE request matching an existing dialog, the S-CSCF shall delete all the stored information related to the dialog.

5.4.5.3 Session expiration

If the S-CSCF requested the session to be refreshed periodically, and the S-CSCF got the indication that the session will be refreshed, when the session timer expires, the S-CSCF shall delete all the stored information related to the dialog.