The MRFC/MRFP are resources of the IMS that provide support for bearer related services such as for example multi-party sessions, announcements to a user or bearer transcoding. This clause describes how the resources of the MRFC/MRFP are used.
In some cases an operator may wish to make an MRFC available directly to a UE, for example to support ad-hoc multi-party sessions to be initiated by the UE. In this case, the operator advertises the name of one or more MRFCs and a UE will invite an MRFC to a session. The session invitation would need to contain additional information indicating the specific capabilities (e.g. multi-party) desired. A conference ID would be assigned by the MRFC and returned to the UE. This would then be used by the UE in subsequent interactions with the MRFC and other UEs participating in the session.
There are two approaches to invite new participants to the multiparty session. In the first, a UE directs other UEs to join the multiparty session based on the use of the SIP REFER method. This allows session invitations with consultation. In the second method, the MRFC uses information received from a UE e.g. within a list of session participants to invite other UEs to the multiparty session. This allows session invitations without consultation.
The MRFC/MRFP resources may also be used, based on service control in an IMS, for services such as multiparty sessions, announcements or transcoding. In this case an Application Server interacts with an MRFC. Session control messages are exchanged between the AS and the MRFC.
There are two approaches for the AS to control the sessions. In the first, the AS uses 3rd party call control. The second approach uses the SIP REFER method.
In either case, the appropriate service in the AS would be triggered by a UE initiated SIP message containing information indicating the specific capabilities desired. This session invitation would also carry additional information indicating the specific capabilities (e.g. multi-party). A conference ID would be assigned by the MRFC and would be used by the AS in subsequent interactions with the MRFC in INVITE messages connecting other endpoints.
3rd party call control can also be used to invoke announcement and transcoding services. That is, the AS will send an INVITE to the MRFC with an indication of the capability being requested and with additional information related to the specific service such as identification of the announcement to be played or identification of the specific transcoding requirements.
Network services hosted on an AS and configurable by the user via the Ut interface may also use the capabilities provided by the MRFC. For this case, the AS either supports MRFC capabilities, or communicates with an MRFC.
Communications across the Ut interface between the UE and the AS allow the UE to securely manage and configure data for such services (e.g. conference type services). Means for the AS to propagate this management and configuration information to the MRFC is not standardized in this Release.
Network services involving MRFC and MRFP are not limited to conferencing and announcements, but also involve transcoding support for interworking between IMSs or inter-domain sessions, and intra-domain sessions between access technologies supported in an IMS (e.g. wireline wireless interworking, or interworking with non-3GPP wireless technologies).
The MRFC and MRFP act as transcoding entity in an IMS solving media encoding mismatches due to codec selection between operator networks, as well as to deal with encoding formats in a converged service environment. Service requests sent to the MRFC shall contain sufficient information to associate the systems that require media transcoding, and also for reservation of resources required at the MRFP. The MRFC shall always grant the requests from the control plane, unless there is a lack of resources. Media transcoding support based on MRFC/MRFP shall support the offer/answer procedure as defined in RFC 3264
Additional description of transcoding support involving the MRFC/MRFP is provided in Annex P