This interface is used to send subscriber data to the S-CSCF, including Filter Criteria (and their priority); which indicates which SIP requests should be proxied to which Application Servers. The protocol used between the HSS and CSCF (Cx Interface) is specified in TS 29.228 and TS 29.229.

The Sh interface is between the HSS and the SIP Application Servers and the OSA SCS and may be used for transferring User Profile information such as user service related information or user location information or charging function addresses. Requirements for the Sh interface are specified in TS 23.228. The Sh interface also supports mechanisms that allow Application Servers to activate/deactivate their own existing initial filter criteria stored in the HSS on a per subscriber basis. The protocol used between the HSS and AS (Sh Interface) is specified in TS 29.328 and TS 29.329.

The protocol used on the interface between the HSS and the CAMEL Service Environment (CSE) is the MAP protocol [16].

The interfaces between the HSS and the IM-SSF Application Server are:

• the Si interface when the MAP protocol as specified in TS 23.278 and TS 29.002 is used
• the Sh interface when the Diameter based protocol as specified in TS 29.328, TS 29.329 and TS 29.364 is used

The Si and the Sh interfaces between HSS and the IM-SSF Application Server are used for transferring IMS CAMEL specific information.

The functionality of the MRFC is defined in TS 23.228. 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.

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 RFC 3264 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.

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 RFC 3264 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).

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 RFC 3264 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.

The protocol used between MRFC and S-CSCF is based on Session Initiation Protocol, which is specified in TS 24.229. 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).

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 TS 24.229. The protocols which use this interface are specified in TS 24.229, TS 24.147 and TS 24.247.

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 TS 24.229.

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 TS 24.229.

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