A.4 Providing announcements to a user during the release of a communication session

24.5283GPPCommon Basic Communication proceduresProtocol specificationRelease 8TISPANTS

The way an announcement is sent to a user during the release of a communication depends on the scenario.

The following scenarios exist:

  • scenario 1: two users are communicating with (at least) one AS in the signalling path (UE-AS-UE); or
  • scenario 2: two (or more) users communicating with (at least) one AS in the signalling path and MRFP in the media path (UE-AS/MRFC/MRFP-UE).

A.4.1 Scenario 1: UE – AS – UE

Two users are communicating with (at least) one AS in the signalling path.

Figure A.10 shows the signalling flow for the scenario.

NOTE: The party still in the communication may return provisional responses to the INVITE request. However, for simplicity those responses are left out.

Figure A.10: Play announcement using new media during the release of a communication

The steps of the signalling flow are as follows:

  1. S-CSCF receives a BYE request.
  2. S-CSCF sends the BYE request to the AS.
  3. Service logic in the AS decides to send an announcement to the party still in the communication.
  4. The MRFC interacts with the MRFP in order to reserve resources for the announcement. As part of the interaction with MRFP, the AS retrieves the media parameters from MRFP e.g. IP address and port numbers, and provide the IP address and port numbers of media that original dialog used to the party still in the communication.
  5. The AS sends a re-INVITE request to S-CSCF.
  6. S-CSCF sends the re-INVITE request towards the party still in the communication.
  7. S-CSCF receives a 200 (OK) response.
  8. S-CSCF sends the 200 (OK) response to the AS.
  9. The AS sends an ACK request to S-CSCF.
  10. S-CSCF sends the ACK request to the party still in the communication.
  11. The MRFC interacts with the MRFP in order to start the alternative ring tone.
  12. The MRFP sends the announcement towards the party still in the communication.
  13. The complete announcement is sent and the MRFP interacts with the AS/MRFC in order to inform that the announcement is terminated.
  14. The MRFC interacts with the MRFP in order to release the resources used for the announcement.
  15. The AS sends the BYE request to S-CSCF. The BYE request contains the same information as the BYE request received in step 2 with the modification done by AS according to rules and procedures of DES TISPAN-ES 283 003 [1].
  16. S-CSCF sends the BYE request towards the party still in the communication.

A.4.2 Scenario 2: UE – AS/MRFC/MRFP – UE

This clause describes the scenario when two (or more) users are communicating with (at least) one AS controlling the media path. The MRFP is in the media path. In this scenario the AS acts as a B2BUA.

Figure A.11 shows the signalling flow for the scenario.

Figure A.11: Play announcement using exist media during the release of a communication

The steps of the signalling flow are as follows:

  1. The AS receives a BYE request.
  2. Service logic in the AS decides to start an in‑band announcement towards a user.
  3. The AS using the co-located MRFC interacts with the MRP in order to reserve resources for the announcement.
  4. The MRFC co-located with the AS interacts with the MRFP in order to start the announcement.
  5. The MRFP sends the announcement towards the remote user.
  6. The MRFC co-located with the AS interacts with the MRFP to stop the announcement.

The AS sends the BYE request towards the remote user. The BYE request contains the same information as the BYE request received in step 1 with the modification done by AS according to rules and procedures of ES 283 003 [1].

Annex B (informative):
Signalling flows for Network Determined User Busy (NDUB)