Content for TS 23.218 Word version: 18.0.0

1… 5… 6… 7… 9… 9.2… 9.4… 10… A B… B.2… B.2.2 B.2.3 B.3… C…

B.2 Announcement, conferencing and transcoding examples using MRFC B.2.1 Example information flow for a UE-originating IP multimedia session that results in playing an announcement
...

B.2 Announcement, conferencing and transcoding examples using MRFC p. 56

B.2.1 Example information flow for a UE-originating IP multimedia session that results in playing an announcement p. 56

Figure B.2.1.1 shows an example of playing an announcement for a UE-originating IP multimedia session. An AS (acting as B2BUA) performs third party call control with the MRFC, where the S-CSCF is in the signalling path.

The "[x]" notation in the Figure is an indicator of a unique SIP dialog. The "dot" notation on the AS line indicates B2BUA actions are taking place along with AS service logic. The 100 (Trying) responses are not shown in the Figure, but it is assumed that a 100 (Trying) response is sent in response to each INVITE request.

The B2BUA AS interacts with the UE as usual to establish the dialog. The B2BUA AS interacts with the MRFC using a third party control model to establish the dialog. The B2BUA AS manages the interactions between the two dialogs.

The offer/answer model as defined in RFC 3264 is used for SDP negotiation between the AS/S-CSCF and the MRFC. The MRFC should always grant the requests from the AS (unless there is a resource problem). The MRFC responds to the INVITE request with a 200 (OK) response indicating the selected codec in the SDP. The MRFC will also reserve the requested local resources at that time. The selected codec is included by the B2BUA AS in the 183 (Session Progress) response to the UE. The receipt of the ACK request at the MRFC triggers the playing of the tone or announcement.

Copy of original 3GPP image for 3GPP TS 23.218, Fig. B.2.1.1: Tones and announcements call flow

Figure B.2.1.1: Tones and announcements call flow
(⇒ copy of original 3GPP image)

Notes for Figure B.2.1.1:

Step 1.

INVITE request is received at the S-CSCF [Call-ID 1].

Step 2.

INVITE request is forwarded to an AS, based on the filter criteria.

Step 3.

The AS service logic determines to proceed with the call.

Step 4.

New INVITE request is sent towards destination, via the S-CSCF, to establish a new dialog [Call-ID 2].

Step 5.

S-CSCF experiences a failure, such as not being able to determine the next hop for the SIP URL.

Step 6.

Session failure returned to the AS.

Step 7.

ACK request returned to complete this dialog [Call-ID 2].

Step 8.

The AS service logic determines to play an announcement to the calling party.

Step 9.

New INVITE request is sent to the MRFC, via the S-CSCF, to establish a new dialog for playing an announcement [Call-ID 3]. Sufficient information is included to specify the details for the announcement.

Step 10.

S-CSCF relays the INVITE request to the MRFC.

Step 11.

The MRFC allocates the requested resource and returns a 200 (OK) response, with SDP-M indicating selected media.

Step 12.

S-CSCF relays 200 (OK) response to the AS.

Step 13 - 30.

The B2BUA AS manages the dialog for Call-ID 1 as normal, with the SDP-M supplied from the MRFC. The MRFC is instructed to play the announcement using the ACK request at flow 26 for Call-ID 3.