A.1 Providing announcements to a user during the establishment of a communication session
24.6283GPPCommon Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS
A.1.1 Providing in-band announcement
This subclause shows an example signalling flow of how an AS can send an announcement to the calling user during the establishment of a communication when using multiple early dialogs as described in annex D.
Separate dialogs are established between the origination UE and the AS controlling the announcement, and the originating UE and the terminating UE. It is allowed that a different SDP answer is sent in the 200 (OK) response from the terminating UE than the SDP answer that was previously sent from the AS in the 183 (Session progress) response.
The AS can e.g. be the AS serving the calling party or the AS serving a called party and may apply for example when a communication is going to be diverted and the AS serving the diverting user inform the calling party that the communication is going to be diverted.
Figure A.1 shows the signalling flow for the scenario.
NOTE: The called party can return provisional responses to the INVITE request. However, for simplicity those responses are left out.
Figure A.1: Announcement started during the establishment of a communication
The calling party initiates a communication by means of an INVITE request. The INVITE request is forwarded toward the called party.
Along the signalling path, created by the INVITE request, some service logic in an Application Server (AS) wants to send an announcement towards the calling party.
The flow is based on the assumptions that the Supported header field includes the option‑tag "100rel".
The steps of the signalling flow are as follows:
1) S-CSCF receives an INVITE request.
2) S-CSCF sends the 100 (Trying) response towards to sender of the INVITE request.
3) S-CSCF evaluates the initial Filter Criteria.
4) S-CSCF sends the INVITE request to the AS.
5) The AS sends the 100 (Trying) to S-CSCF.
6) Service logic in the AS decides to send an announcement to the calling party.
7) The MRFC interacts with the MRFP in order to reserve resources for the announcement. As part of the interaction with MRFP the AS receives the necessary media parameters e.g. IP address and port numbers and provide the IP address and port number for the calling party to the MRFP.
8) The AS sends a 183 (Session progress) response to S-CSCF. The response includes:
a) an answer to the SDP received in the INVITE request;
b) a P-Early-Media header field set to "sendonly"; and
c) the Require header field set to "100rel".
9) S-CSCF sends the 183 (Session progress) response towards the calling party.
10) S-CSCF receives a PRACK request.
11) S-CSCF sends the PRACK request to the AS.
12) The AS sends a 200 (OK) to the PRACK request to S‑CSCF.
13) S-CSCF sends the 200 (OK) towards the calling party.
14) The MRFC interacts with the MRFP in order to start the announcement.
15) The MRFP sends the announcement towards the calling party.
16) The complete announcement is sent and the MRFP interacts with the AS/MRFC in order to inform that the announcement is terminated.
17) The MRFC interacts with the MRFP in order to release the resources used for the announcement.
18) The AS sends the INVITE request towards the called party. The INVITE request contains the same information as the INVITE request received in step 4 with the modification done by AS according to rules and procedures of 3GPP TS 24.229 [1].
19) S-CSCF sends the 100 (Trying) response to the AS.
20) S-CSCF sends the INVITE request towards the called party.
21) S-CSCF receives a 100 (Trying) response.
22) S-CSCF receives a 200 (OK) response to the INVITE request.
23) S-CSCF sends the 200 (OK) response to the INVITE request to the AS.
24) The AS sends the 200 (OK) response to the INVITE request to the S-CSCF.
25) S-CSCF sends the 200 (OK) response to the INVITE request towards the calling party.
26) S-CSCF receives an ACK request.
27) S-CSCF sends the ACK request to the AS.
28) The AS sends the ACK request to S-CSCF.
29) S-CSCF sends the ACK towards the called party.
When the UE of the calling party receives the 200 (OK) response to the INVITE request the UE can regard the early dialog created for the announcement between the UE and the AS terminated.
A.1.2 Including Alert-Info header field in the 180 (Ringing) response
IETF RFC 3261 [4] specifies the Alert-Info header field as a means to indicate a source of media to play an alternative ring tone by an originating endpoint.
An example of this mechanism is shown in figure A.2.
NOTE: In the figure the SDP signalling details to establish media are not shown for simplicity.
Figure A.2: Alert-Info header field in the 180 (Ringing) response to indicate an alternative ring tone
The steps of the flow are as follows:
1) S-CSCF receives an INVITE request from the originating user. The originating user may be a user served by this S-CSCF, a user served by another S-CSCF or a user connected to PSTN/ISDN via a MGCF.
2) S-CSCF sends a 100 (Trying) response.
3) S-CSCF evaluates the Initial Filter Criteria.
4) S-CSCF sends the INVITE request to the AS.
5) The AS sends a 100 (Trying) response to S-CSCF.
6) The AS sends the INVITE request to S-CSCF.
7) S-CSCF sends the 100 (Trying) response to the AS.
8) S-CSCF sends the INVITE request towards the called party. The called party may be a user served by another S-CSCF or a user connected to PSTN/ISDN via a MGCF.
9) S-CSCF receives a 100 (Trying) response.
10) S-CSCF receives a 180 (Ringing) response.
11) S-CSCF sends the 180 (Ringing) response to the AS.
12) The AS inserts a valid Alert-Info header field in the 180 (Ringing) including a URL to a media file containing the appropriate tone and sends the 180 (Ringing) response to S-CSCF.
EXAMPLE: This file http://operator.net/tone.wav, in the picture abbreviated to http://url.wav is played at the originating UE (step 14).
13) S-CSCF sends the 180 (Ringing) response towards the originating user.
14) The http://url.wav (for example http://operator.net/tone.wav) is retrieved and played at the originating user.
15-18) S-CSCF receives a 200 (OK) response to the INVITE request and forwards it to the originating user via the AS.
19) The originating user stops playing the tone.
20-23) S-CSCF receives an ACK request and forwards it towards the called party via the AS.
A.1.3 Announcements provided by the PSTN/ISDN
This subclause shows the signalling flow for a scenario where a user connected to the IP network establish a communication with a user connected to the PSTN/ISDN. During the establishment of the communication the PSTN/ISDN provides an announcement e.g. "The communication is forwarded" or "The user is not reachable".
Figure A.3 shows the signalling flow for the scenario.
NOTE: The flow assumes the use of the option‑tag "100rel" defined in RFC 3262 [5] other scenarios may also apply. T-MGF is left out of the figure for simplicity.
Figure A.3: Announcement provided by PSTN/ISDN during the establishment of a communication
The steps of the flow are as follows:
1) The MGCF receives an INVITE request from the IP network. The request includes an SDP offer.
2) The MGCF sends a 100 (Trying) response to the IP network.
3) The MGCF sends an IAM towards PSTN.
4) The MGCF receives an early ACM from the PSTN/ISDN with an indication that "In-band information may be available".
5) The MGCF sends a 183 (Session Progress) response to the IP network. The response includes:
a) the answer to the SDP offer received in the INVITE request;
b) A P-Early-Media header field set to "sendonly"; and
c) The option‑tag "100rel" in the Require header.
6) The MGCF receives the PRACK request.
7) The MGCF sends a 200 (OK) response to the PRACK request.
8) The T-MGF sends the in-band announcement received from the PSTN/ISDN to the IP network.
Depending on the reason for the announcement the establishment of the communication continues or the establishment of the communication is aborted.
A.1.4 Announcement provided towards a user connected to the PSTN/ISDN
This subclause shows an example signalling flow for a scenario where a user in PSTN/ISDN establishes a communication with a user connected to IMS. During the establishment an AS in the IP network provides an announcement,
e.g. "The communication is forwarded" or "The user is not reachable".
Figure A.4 shows the signalling flow for the scenario.
NOTE: The flow assumes the use of the option-tag "100rel" defined in RFC 3262 [5] other scenarios can also apply. T-MGF is left out of the figure for simplicity.
Figure A.4: Announcement provided towards a user connected to PSTN/ISDN
during establishment of a communication
The steps of the flow are as follows:
1) The MGCF receives an IAM from the PSTN/ISDN.
2) The MGCF sends an INVITE request to the IP network. The request includes a SDP offer.
3) The MGCF receives a 100 (Trying) response from the IP network.
4) The MGCF receives a 183 (Session Progress) response from the IP network.The response includes:
a) the answer to the SDP offer sent in the INVITE request;
b) a P-Early-Media header field set to "sendonly"; and
c) the option-tag "100rel" in the Require header field.
5) The MGCF sends a PRACK request towards the IP network.
6) The MGCF sends an early ACM to the PSTN/ISDN. The early ACM contains the "in-band information may be available" indication.
7) The MGCF receives a 200 (OK) response to the PRACK request.
8) The T-MGF receives the in-band announcement from the IP network and forwards the announcement to the PSTN/ISDN network.
Depending on the reason for the announcement the establishment of the communication continues or the establishment of the communication is aborted.
A.1.5 Providing in-band announcement after a reliable provisional response has been received by the terminating UE
This subclause shows an example signalling flow of how an AS can send an announcement to the calling user during the establishment of a communication, in the case the terminating UE has already sent SDP within a reliable provisional response.
Separate dialogs are established between the origination UE and the AS controlling the announcement, in accordance with annex A.1.1.
Figure A.5 shows the signalling flow for the scenario.
Figure A.5: Originating announcement during communication establishment considering terminating early media
The calling party initiates a communication by means of an INVITE request. The INVITE request is forwarded toward the called party.
Along the signalling path, created by the INVITE request, some service logic in an AS wants to send an announcement towards the calling party.
The flow is based on the assumptions that the Supported header field includes the option‑tag "100rel".
The steps of the signalling flow are as follows:
1) S-CSCF receives an INVITE request with the initial SDP offer
2) S-CSCF evaluates the initial Filter Criteria
3) S-CSCF sends the INVITE request to the AS
4), 5) the AS forwards the INVITE to the terminating UE
6), 7) the terminating UE answers with a reliable 180 (Ringing) response including a SDP answer.
8) based on the received response the service logic in the AS decides to send an announcement to the calling party
9), 10) the AS forwards the received SDP answer within a reliable183 (Session progress) response, in order to establish an e2e dialog between the originating and terminating UEs
11) to 18) the originating UE confirms the reliable response to the terminating UE
19) The MRFC interacts with the MRFP in order to reserve resources for the announcement. As part of the interaction with MRFP the AS receives the necessary media parameters e.g. IP address and port numbers and provide the IP address and port number for the calling party to the MRFP.
20) to 25) the AS sends a reliable 180 (Ringing) response to the originating UE and creates a new dialog between the AS and the originating UE. The response includes:
a) an answer to the SDP received in the INVITE request;
b) a P-Early-Media header field set to "sendonly"; and
c) the Require header field set to "100rel".
26) The MRFC interacts with the MRFP in order to start the announcement.
27) The MRFP sends the announcement towards the calling party.
28), 29) the terminating UE answers with a 200 OK response without SDP
30) The MRFC interacts with the MRFP in order to release the resources used for the announcement.
31), 32) the AS forwards the 200 OK response in the e2e dialog to the originating UE
33) to 36) the communication is confirmed