A.3 Communication request rejected
24.6283GPPCommon Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 17TS
Service logic in an AS, e.g. the ACR service, can decide to reject a communication request and provide an announcement to explain the reason for the rejection to the originating user. The AS can:
1) Send the announcement as in-band information.
2) Include a reference to the announcement in a 3xx, 4xx, 5xx and 6xx response.
A.3.1 Sending the announcement as in-band information
The network can generate announcement using one of the following procedures:
1) using early media i.e. the AS establish an early session and uses that early session to send the in-band announcement; or
2) using an established session i.e. the AS accepts the INVITE request and uses the established session to send the in-band announcement.
A.3.1.1 Using early media
This subclause explains how an AS can use an early media session to send the in-band announcement and when the announcement is sent reject the communication request with an appropriate reject code.
Figure A.8 shows the signalling flow for the scenario.
Figure A.8: Using early media to send in-band announcement
The originating user initiates communication by means of an INVITE request. A long the path towards the terminating user an AS determines that the INVITE request cannot be forwarded to the terminating user. The steps of the flow are as follows:
1) S-CSCF receives an INVITE request from the originating user. The originating user can 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) Service logic in the AS decides to reject the communication request and to send an announcement in‑band in order to give a detailed reason to the originating user.
7) The MRFC collocated with the AS interact with the MRFP and reserves resources for the announcement.
8) The AS sends a 183 (Session progress) response to S-CSCF. The response includes:
a) the Require header field with the option‑tag "100rel";
b) an answer to the SDP received in the INVITE request; and
c) an answer to the SDP received in the INVITE request.
9) S-CSCF sends the 183 (Session Progress) response towards the originating user.
10) The MRFC collocated with the AS interact with the MRFP in order to start the announcement.
11) S-CSCF receives a PRACK request from the originating user.
12) S-CSCF sends the PRACK request to the AS.
13) The AS sends the 200 (OK) response to the PRACK request to S-CSCF.
14) S-CSCF sends the 200 (OK) response to the PRACK request to the originating user.
15)MRFP sends the announcement towards the UE.
16) The MRFP interacts with the MRFC collocated with the AS to indicate that the announcement is sent.
17) The MRFC collocated with the AS interact with the MRFP in order to release resources reserved for the announcement.
18) The AS sends a 3xx, 4xx, 5xx or 6xx response to the INVITE request to S‑CSCF.
19) S‑CSCF sends a 3xx, 4xx, 5xx or 6xx response to the INVITE request to the originating user.
20) S‑CSCF receives an ACK request from the originating user.
21) S‑CSCF sends an ACK request to the AS.
A.3.1.2 Using an established session
This subclause explains how an AS can use an established session to send the in‑band announcement and when the announcement is sent, release the communication and include an appropriate reject code in the BYE request.
Figure A.9 shows the signalling flow for the scenario.
Figure A.9: In-band information generated by network when
an invitation to a communication is rejected
The originating user initiates communication by means of an INVITE request. A long the path towards the terminating user an AS determines that the INVITE request cannot be forwarded to the terminating user.
The steps are as follows:
1) S-CSCF receives an INVITE request from the originating user. The originating user can 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 decides to reject the communication request and to send an announcement in-band in order to give a detailed reason to the originating user.
7) The MRFC collocated with the AS interact with the MRFP and reserves resources for the announcement.
8) The AS sends a 200 (OK) response to the INVITE request to S-CSCF.
9) S-CSCF sends the 200 (OK) response to the INVITE request towards the originating user.
10) The MRFC collocated with the AS interact with the MRFP in order to start the announcement.
11S-CSCF receives an ACK request from the originating user.
12) S-CSCF sends the ACK request to the AS.
13) MRFP sends the announcement towards the originating user.
14) The MRFP interacts with the MRFC collocated with the AS to indicate that the announcement is sent.
15) The MRFC collocated with the AS interact with the MRFP in order to release resources reserved for the announcement.
16) The AS sends a BYE request to S-CSCF. The BYE request can include an appropriate reject reason.
17) S-CSCF sends the BYE request towards the originating user.
18) S-CSCF receives a 200 (OK) response to the BYE request from the originating user.
19) S-CSCF sends the 200 (OK) response to the BYE request to the AS.
A.3.2 Including an Error-Info header field in a 3xx, 4xx, 5xx and 6xx response
This subclause explains how an AS can include a reference to an announcement stored in the network.
IETF defines an Error-Info header field for use in 3xx, 4xx, 5xx and 6xx responses to the INVITE request. The Error‑Info header field transports a reference to a file e.g. a file containing an announcement.
When the originating UE receives the reference the UE retrieves the announcement and plays it for the user.
Figure A.10 shows the message flow for the scenario.
Figure A.10: Error-Info header in 3xx, 4xx, 5xx and 6xx responses
The originating user initiates communication by means of an INVITE request. A long the path towards the terminating user an AS determines that the INVITE request cannot be forwarded to the terminating user.
The steps are as follows:
1) S-CSCF receives an INVITE request from the originating user (in the case the AS is an O-AS) or the originating network (in the case the AS is a T-AS).
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 decides to reject the invitation to communication and to provide a reference to an announcement explaining the reason in more detail.
7) The AS sends a 3xx, 4xx, 5xx or 6xx response to S-CSCF. The application server inserts a valid Error-Info header field in either a 3xx, 4xx, 5xx or 6xx response to the INVITE request, including a URL to a media file containing the appropriate tone, announcement or music.
EXAMPLE: http://operator.net/announcement.wav, in the picture abbreviated to http://url.wav, is played at the originating UE (after step 10).
8) S-CSCF sends the ACK request to the AS.
9) S-CSCF sends the 3xx, 4xx, 5xx or 6xx response towards the originating user.
10) S-CSCF receives the ACK request.
A.3.3 Announcements provided by the PSTN/ISDN
The signalling flow for this scenario is the same as the signalling flow example given in subclause A.1.3.
A.3.4 Announcement provided to a user connected to the PSTN/ISDN
The signalling flow for this scenario is the same as the signalling flow example given in subclause A.1.4.