Media Resource Broker Revealed

By Chris Boulton

What exactly is a Media Resource Broker, or MRB as it's known to some? If you haven't already heard of an MRB yet, you certainly will soon and won't believe what you have been missing. The NS-Technologies article 'Introduction to Media Resource Brokering' covers the history and background relating to the emergence of media server resources and is recommended reading for those new to this leading edge topic. While that article provides the background to MRB evolution, the intention of this article is to provide an introduction to the MRB network entity itself including its common decision making process, the interfaces available for application server and media server interaction, and the roles it can assume.

The MRB concept is currently being devised in the Internet Engineering Task Force (IETF) in the Media Control (mediactrl) work group. The core document for an MRB can be found at the following location - http://tools.ietf.org/html/draft-ietf-mediactrl-mrb. An MRB can play one of two roles defined in the specification depending on the requirements of the situation. It can either act as a query MRB or an in-line MRB. Underpinning both flavours of MRB is a selection engine that provides the client of media resources with the most appropriate media server to fulfil a specific request. Figure 1 provides an extremely simplistic illustration of the common MRB selection engine.

Figure 1 - MRB Selection Process

At the bottom of Figure 1 it can be seen that media servers report the appropriate properties to the MRB. This would typically be details of the media servers capabilities as well as its current status, including the amount of resources that are available to the network. The MRB decision engine is then able to track available media servers and resources in the network and have a complete view of availability. On the left of Figure 1, a request for media resources arrives at the MRB from a requesting application. The request for media resources will contain contextual information that provides input into the decision making process. The MRB will examine the parameters provided by the requesting client and then use its view of the available media resources to map the most appropriate media server candidates. Once a decision has been made, the MRB provides the information for execution of the media resource request. The exact mechanism of execution depends on the type of role that MRB is assuming. It can act as either an in-line MRB or a query MRB, both of which are described in more detail in the following two subsections.

In-line MRB

The decision making process discussed earlier in this section remains constant through all forms of MRB operation. The difference between the two flavours of MRB is the transport protocol used for interrogation of available media resources by the media resource client. The In-line MRB uses the Session Initiation Protocol (SIP) to receive requests from clients requiring media resources. It effectively sits in the signalling path between the client and a media server, hence the name 'In-line'. Figure 2 provides an illustration of an In-line MRB.

Figure 2 - In-line MRB

Figure 2 shows that a client composes a request and sends it to the In-line MRB for processing. On receiving the request, the In-line MRB selects an appropriate media server and dispatches the request accordingly. The In-line mode plays a fully interactive role in the signalling path of a request which is in total contrast to the Query mode discussed in the next section.

On receiving a SIP request, an In-line MRB can act in one of two roles. The first role is called an In-line Unaware MRB Mode (IUMM). The IUMM allows an MRB to receive SIP requests from clients that are not compliant to the MRB specification. This functionality is included to allow legacy applications to interact with an MRB without the need for code modification. As far as the client is aware it is constructing a compliant request to a media server which happens to be routed via an MRB. An MRB acting in this mode is capable of examining the request and making a media server selection decision based on its view of the available media servers. The inclusion of IUMM is extremely important as it allows deployment and integration of an MRB into an evolving network without the need for any code change to existing legacy applications. The second role is called In-line Aware MRB Mode (IAMM). The IAMM allows an MRB to receive SIP requests from clients that are fully compliant to the MRB specification. The SIP request received by the MRB contains additional contextual information defined in the specification. The MRB will extract the information provided by the client requesting media resources and use it to help determine an appropriate media server. IAMM provides advanced functionality for future applications deployed to the network which allows accurate media selection based on both availability of a media server in conjunction with appropriate client requirements.

Query MRB

In the previous section, the Query MRB uses the same decision making process with the exception that the transport protocol is different. A Query MRB operation uses the Hypertext Transport Protocol (HTTP) as the communication channel between a client requiring media resources. Figure 3 provides an illustration of Query MRB operation.

Figure 3 - Query MRB

As shown in Figure 3, an MRB acting in query mode receives the request for media resources using the HTTP protocol. The Query MRB will inspect the incoming HTTP message for contextual information relating to the required media resources. It extracts the information and uses it to determine which media servers should be returned to service the client. The Query MRB will return the the selected media servers in a HTTP response which is then used by the media resource client to connect directly to the appropriate media server. The primary difference between In-line and Query mode MRB operation can be seen when comparing Figure 2 and Figure 3. While the In-line operation uses the SIP protocol to receive requests within the core signalling protocol and then forwards them onwards to an appropriate media server, Query operation examines the request and returns an appropriate response. Both modes of operation use the same underlying decision making process that is influenced by contextual information supplied by the media resource client and status information from the media server. An In-line MRB directly interacts with a media server on behalf of the media resource client while a Query MRB supplies the media resource client, using the HTTP request/response protocol, with the media server for it to connect with directly. Query and In-line MRB operational modes both have valid use-cases and roles to play in next generation communications networks.

In conclusion, the MRB entity is emerging as an important entity in current and next generation multimedia networks. The flexible approach being defined by the IETF provides a necessary tool kit for fulfilling varying requirements of network deployments. This includes acting in both IUMM and IAMM modes of operation for pure SIP based solutions and also providing a HTTP query interface for those wanting a request/response solution. The inclusion of IUMM is also important as it provides a feasible migration path for legacy services that interact with a media server without the pain of changing existing services/applications. The HTTP interface also allows non-SIP aware media servers to be used in the network if required. The first generation MRB will mark a pivotal point in the evolution of next generation networks and will allow large networks to expand efficiently and effectively without hindrance from spiralling capital and operational expenditure costs.