B.2.3 Example information flows for a UE-originating IP multimedia session that requires transcoding
23.2183GPPIM call modelIP Multimedia (IM) session handlingRelease 17Stage 2TS
The two figures B.2.3.1 and B.2.3.2 that follow illustrate the MRFC providing transcoding for a UE-originating session, where the MRFC is receiving directions from the AS operating as a B2BUA.
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 originating UE as usual to establish the dialog. The B2BUA AS interacts with the MRFC using a third party control model to establish the dialog with the called party after receiving the initial failure indication. The B2BUA AS manages the interactions between the two dialogs.
An INVITE request is generated from a UE. A 606 (Not Acceptable) response is received from the called party. The AS uses third party call control to request transcoding facilities from the MRFC. A separate dialog is established from the AS to the MRFC for each of the two parties. New dialogs are also established between the AS and each of the UE endpoints. The media from each UE is connected at the transcoding resource at the MRFP.
In the first figure B.2.3.1 below, the called party returns an indication of an acceptable codec. For this case, the request to the MRFC will include the appropriate codec for the called party and the offer/answer model as defined in IETF RFC 3264 [15] with the MRFC is used. In figure B.2.3.2 below, the called party does not indicate any SDP, which means that more steps will be required on the subsequent INVITE request to set up transcoding with the MRFC. An INVITE request without SDP is sent to the MRFC to get the list of codecs it supports. The AS then sends that list of codecs in the new INVITE request that it sends to the called party. The B2BUA function of the AS matches up the responses.
The offer/answer model 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.
Figure B.2.3.1: Transcoding call flow (called party indicates codec)
Notes for figure B.2.3.1:
1) INVITE request received at S-CSCF from UE [Call-ID 1].
2) 100 (Trying) response returned.
3) INVITE request forwarded to an AS, based on filter criteria.
4) AS service logic determines to proceed with the call.
5) New INVITE request is sent towards destination, via the S-CSCF, to establish a new dialog [Call-ID 2].
6) S-CSCF forwards the INVITE request.
7) Called UA returns 606 (Not Acceptable) response to the INVITE request. Included in the response is an indicator that the offered codec is not acceptable plus information on what codec would be acceptable.
8) An ACK request is sent to the called UA to complete the dialog for Call-ID 2.
9) 606 (Not Acceptable) response is forwarded to the AS.
10) AS service logic determines that there is an MRFC that can perform the transcoding.
11) ACK request sent to S-CSCF to complete the dialog for Call-ID 2.
12 – 17) New INVITE request sent to MRFC to establish transcoding for called UA [Call-ID 3].
18 – 25) New INVITE request sent to called UA to establish session between UA and MRF [Call-ID 4].
26 – 29) New INVITE request sent to MRFC to establish transcoding for calling UE [Call-ID 5].
30 – 53) Normal call establishment procedures from here on, with B2BUA AS performing the appropriate signalling translations between the associated dialogs.
Figure B.2.3.2: Transcoding call flow (called party codec negotiated)
Notes for figure B.2.3.2:
1) INVITE request received at S-CSCF from UE [Call-ID 1].
2) 100 (Trying) response returned.
3) INVITE request forwarded to an AS, based on filter criteria.
4) AS service logic determines to proceed with the call.
5) New INVITE request is sent towards destination, via the S-CSCF, to establish a new dialog [Call-ID 2].
6) S-CSCF forwards the INVITE request.
7) Called UA returns 606 (Not Acceptable) response to the INVITE request. Included in the response is an indicator that the offered codec is not acceptable but there is no information on what codec would be acceptable (no SDP).
8) ACK request sent to called UA to complete the dialog for Call-ID 2.
9) 606 (Not Acceptable) response is forwarded to the AS.
10) AS service logic determines that there is an MRFC that can perform the transcoding.
11) ACK request sent to S-CSCF to complete the dialog for Call-ID 2.
12 – 15) New INVITE request sent to MRFC to establish transcoding for called UA and to get the list codecs supported by the MRF [Call-ID 3].
16 – 19) New INVITE request sent to called UA with SDP for all codecs supported by the MRF to establish session between UA and MRF [Call-ID 4]. UA returns SDP with acceptable codecs.
20 – 23) A new offer with the codecs provided by the UA is sent in PRACK request and the 200 (OK) response indicates the selected codec.
24 – 31) Acknowledgements sent to complete Call-ID 3.
Call establishment procedures from here on are common with the previous transcoding call flow.