In-Line MRB; strawman for draft-ietf-mediactrl-mrb

By Boulton & Miniero

Internet-Draft, Media Resource Brokering, July 2009

4.2. In-Line MRB

The "In-line" MRB is architecturally different from the "Query" model that was discussed in the previous section. The Concept of a "Media Server Consumer Interface" disappears. The client of the MRB simply uses the signalling to offload the decision making process - this applies to both media server Control and Media dialogs. This type of deployment is illustrated in Figure 8.

Figure 8: In-line MRB

The Media Servers still use the 'Media Server Publishing Interface' to convey capabilities and resources to the MRB - as illustrated by (1). The media server Control and Media dialogs are sent to the MRB (2) which then selects an appropriate Media Server (3). The result of such an architecture is that the signalling decision is left entirely to the MRB and the Application Server has no choice in the final selection process. This is the opposite to the "Query" model which provided information that would help influence the Media Server decision making process on the application server and resulted in it directly contacting an appropriate Media Server instance. As a by-product of this decision shift, a lot more emphasis is placed on the intelligence of the MRB to interpret the required capabilities of the request. The MRB will actually have to inspect both the SIP signalling and the media server control protocol PDUs for the purpose of Media Server selection. This includes, for example, looking for explicit capabilities in the signalling and session details such as media types, codecs and bandwidth requirements. Ultimately the decision making and policy enforcement is removed from the Application Server and shifted to the MRB logical entity.

In-line MRB can be split into two distinct logical roles which can be applied on a per request basis. They are:

In-line Unaware MRB Mode (IUMM)) Allows an MRB to act on behalf of clients requiring media services who are not aware of an MRB or its operation.
In-line Aware MRB Mode (IAMM) Allows an MRB to act on behalf of clients requiring media services who are aware of an MRB and its operation.

The two modes are discussed in more detail in the following subsections.

4.2.1. In-line Unaware MRB Mode

It should be noted that the introduction of an MRB entity into the network, as specified in this document, requires interfaces to be implemented by those requesting media server resources (for example an application server). This applies when using both the Consumer interface as discussed in Section 5.2 and IAMM. It is for this reason that an MRB is able to act in a client unaware mode when it is deployed into the network. This allows any SIP compliant client entity, as defined by RFC 3261 [RFC3261] and its extensions, to send requests to an MRB and it will select an appropriate media server based on knowledge of media server resources it currently has available. Mechanisms used to connect to media servers are detailed in the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework]. Using an MRB in this mode allows for easy migration of current applications and services that are unaware of the MRB concept and would simply require a configuration change resulting in the MRB being set as a SIP outbound proxy for clients requiring media services. Any client of media services wishing to take advantage of the advanced techniques detailed in this document when using In-line mode would implement IAMM which is covered in Section 4.2.2. The techniques used for selecting an appropriate Media Server by an MRB acting in IUMM is outside the scope of this document.

4.2.2. In-line Aware MRB Mode

An In-Line Aware Mode MRB (IAMM) is one that complies to the extended functionality provided in this section. A client entity, such as an application server, wishing to use advanced MRB functionality can provide additional contextual information to an MRB. This information is identical to that used in the Consumer interface in Section 5.2 with the only difference being the underlying transport mechanism of the contextual information, as specified by the 'application/mrb-consumer+xml' payload in Section 7. A client of an IAMM uses SIP signalling to convey the 'application/mrb-consumer+xml' payload to the IAMM. The Consumer interface, as specified in Section 5.2 , uses HTTP. A client of an IAMM requiring media services, as well as creating a standard SIP complaint request, MUST use the following steps to ensure that the request is dealt with appropriately:

The client of the IAMM constructs a SIP INVITE request to connect to a Media Server as detailed in the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework] with one exception.
The client of the IAMM includes a MIME content type of multipart/mixed as defined in RFC 2046 [RFC2046]. As part of this mixed payload, the client MUST at least include a content-type of type 'application/sdp' and a content type of type 'application/mrb-consumer+xml'. The part of type application/sdp represents the media server connection details and MUST adhere to the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework]. The part of type 'application/mrb-consumer+xml' represents the IAMM contextual information and MUST adhere to the schema defined in Section 7.
Once the SIP INVITE request is constructed, it is sent to the recipient as per RFC 3261 [RFC3261].

[EDITORS NOTE: Include example of valid IAMM payload.] On receiving a SIP INVITE request containing the multipart mixed payload as specified previously, the IAMM will complete a number of steps to fulfil the request. It will:

Extract the multipart MIME payload from the SIP INVITE request. It will then use the contextual information provided by the client in the 'application/mrb-consumer+xml' part to determine which media server should be selected to service the request.
Extract the 'application/sdp' part from the payload and use it to populate a new SIP INVITE request for connecting the client to the selected media server, as defined in the Media Channel Control Framework[I-D.ietf-mediactrl-sip-control-framework]. The IAMM acts as a Back-to-Back-UA (B2BUA) that extracts the 'application/mrb-consumer+xml' information from the SIP INVITE request and then forwards to the selected Media Server.

[EDITORS NOTE: Consumer interface has a proposal to update a request for media services based on HTTP. There are times when an application server might want to override the MS view of resources. For example, a conference where participants leave and can rejoin. Need to decide if this use of consumer XML should also allow for updates using SIP reINVITE and UPDATE.]