8 Functional requirements of the MRFC

23.2183GPPIM call modelIP Multimedia (IM) session handlingRelease 17Stage 2TS

8.1 Functionality of the MRFC

8.1.1 Overview of MRFC Functionality

The functionality of the MRFC is defined in 3GPP TS 23.228 [3]. These subclauses describe how an Application Server may interact with a MRFC. In some cases a UE may interact directly with the MRFC, however these cases are outside the scope of this specification and only the cases of Application Server control for service provision are considered here. In all cases of Application Server control, all session control requests that are passed between the Application Server and the MRFC may be either exchanged directly via the Mr’ interface or sent via the S-CSCF using the ISC interface and the interface of the Mr reference point. In addition to the session control requests, media control related commands and resources may be passed between the Application Server and the MRFC using the Cr interface.

MRFC addresses are made known via peer-to-peer arrangements within the IM CN subsystem.

Figure 8.1.1.1 describes the relationship of the Application Server with the S-CSCF and MRFC.

Figure 8.1.1.1: Relationship of MRFC and MRFP with S-CSCF, and Application Servers

8.1.2 Tones and announcements

An Application Server is in control of the tone/announcement selection and is aware of MRFC capabilities.

The MRFC accepts INVITE requests sent from an Application Server, either directly using the Mr’ interface or via the S-CSCF using the ISC interface, for the purpose of applying tones and announcements. The INVITE request sent to the MRFC will contain sufficient information to play the appropriate tone or announcement or sufficient information for the request to be linked to a media control command passed between the Application Server and MRFC using the Cr interface that will contain that information.

Any additional resources required (for example announcement files) may be fetched from the Application Server via the Cr interface.

The MRFC shall support both the offer/answer as defined in IETF RFC 3264 [15] and the offer/answer with preconditions models for SDP negotiation with the AS. However, the offer/answer model for SDP negotiation between the AS and the MRFC is sufficient for applying tones and announcements. The MRFC should always grant the requests from the AS (unless there is a resource problem). The receipt of the ACK request or media control command at the MRFC triggers the playing of the tone or announcement.

The tone or announcement should end when a BYE request is received. Alternatively, an expiration time may have been specified from the AS within the SDP of the INVITE request or a media control command. In this case, the MRFC may terminate the media on its own and generate a BYE request towards the AS. A tone or announcement may also have a pre-determined play time (e.g., confirmation tone), and so there may not be a need for the AS to send a request to stop it or to include the play time in the request.

See annex B for a call flow example of playing an announcement for a UE-originating call.

8.1.3 Ad-hoc conferences (multiparty calls)

An Application Server can control an Ad-Hoc conference (multiparty call) and is aware of MRFC capabilities.

The MRFC accepts INVITE requests sent from an Application Server, either directly using the Mr’ interface or via the S-CSCF using the ISC interface, for the purpose of managing ad hoc conferences. The INVITE request sent to the MRFC shall contain sufficient information to initiate, add and remove parties from the conference. ReINVITE requests can also be sent for managing floor control and for parties to leave and rejoin the media path.

Media control commands to control the conference (for example conference gain) may be sent between the Application Server and the MRFC via the Cr interface.

The MRFC shall support both the offer/answer as defined in IETF RFC 3264 [15] and the offer/answer with preconditions models for SDP negotiation with the AS. However, the offer/answer model for SDP negotiation between the AS and the MRFC is sufficient for managing ad hoc conferences. The MRFC should always grant the requests from the AS (unless there is a resource problem). The MRFC will reserve the requested local resources and return the appropriate resource identifiers in the 200 (OK) response.

See annex B for a call flow example of an Ad Hoc Conference (Multiparty Call).

8.1.4 Transcoding

An Application Server can control a transcoding session and is aware of MRFC capabilities.

The MRFC accepts INVITE requests sent from an Application Server, either directly using the Mr’ interface or via the S-CSCFusing the ISC interface, for the purpose of transcoding. The INVITE request sent to the MRFC shall contain sufficient information to associate the two sessions that require transcoding.

The MRFC shall support both the offer/answer as defined in IETF RFC 3264 [15] and the offer/answer with preconditions models for SDP negotiation with the AS. Either may be necessary 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).

For the offer/answer model, the MRFC responds to the INVITE request with a 200 (OK) response indicating the selected media in the SDP. The MRFC will also reserve the requested local resources at that time and return the appropriate resource identifiers in the 200 (OK) response.

For the offer/answer with preconditions model, the MRFC responds to the INVITE request with a 183 (Session Progress) response indicating the list of codecs supported by the MRFC. When the PRACK request is received indicating the selected media in the SDP, the MRFC will reserve the requested local resources at that time and return the appropriate resource identifiers in the 200 (OK) response.

See annex B for call flow examples of providing transcoding.

8.2 Interfaces defined for MRFC

8.2.1 MRFC – S-CSCF (Mr) interface

The protocol used between MRFC and S-CSCF is based on Session Initiation Protocol, which is specified in 3GPP TS 24.229 [5].

The interface is used where it is wished to use the services of the S-CSCF to route to the MRF.

The interface is also used to support the establishment of a media control channel with the MRF, or between the MRF and the MRB.

The interface is also used where the S-CSCF, I-CSCF or UE wishes to address the MRF directly. These entities can also use an MRB (using this interface) to support selection of the appropriate MRF. Such usage is however limited to In-Line mode (see subclause 13.2).

8.2.2 Application Server – MRFC (Cr) interface

The Cr interface allows interaction between an Application Server and an MRFC.

The Cr interface enables the MRFC to fetch and cache documents and resources from an Application Server and to return data to an Application server.

The Cr interface enables media control protocol requests, responses and notifications to be sent between the MRFC and an Application Server.

The establishment and management of the media control protocol is done via SIP messages sent between the Application Server and the MRFC (either directly using the Mr’ interface or via the S-CSCF using the ISC interface ) and is specified in 3GPP TS 24.229 [5].

The protocols which use this interface are specified in 3GPP TS 24.229 [5], 3GPP TS 24.147 [23] and 3GPP TS 24.247 [24].

8.2.3 Application Server – MRFC (Mr’) interface

Mr’ interface allows an Application Server and an MRFC to exchange session control messages without passing through an S-CSCF.

The protocol used between Application Server and MRFC over Mr’ interface is based on Session Initiation Protocol, which is specified in 3GPP TS 24.229 [5].

8.2.4 MRB – MRFC (Mr’) interface

This interface is used for an MRB operating in In-Line mode. The use of this interface is described in subclause 13.2.

This interface can also be used by the MRFC to establish a media control channel between the MRB and the MRFC to allow the publication of resource information, see subclause 13.3.

Mr’ interface allows an MRB and an MRFC to exchange session control messages without passing through an S-CSCF.

The protocol used between MRB and MRFC over Mr’ interface is based on Session Initiation Protocol, which is specified in 3GPP TS 24.229 [5].

8.2.5 MRB – MRFC (Cr) interface

This interface is used for an MRFC to publish information to the MRB. The use of this interface is described in subclause 13.3.