Media Resource Brokering
Extracted elements (26)
HTTP is chosen as the transport for the Query mode Consumer interface because combining HTTP and XML reduces complexity and leverages widely available tooling. The MRB view of Media Server resources is explicitly described as 'best effort' and approximate, since resource information is only reported periodically over the Publish interface.
The Hybrid Query MRB deployments (MRB co-hosted on an AS or on a single MS) are explicitly supported to accommodate environments where a dedicated MRB entity is operationally undesirable. When co-hosted on the MS, the topology suits a single MS acting as a front-end for a cluster, with the Publish interface collapsing internally.
The MRB entity is introduced to handle M:N deployment architectures where multiple Application Servers and multiple heterogeneous Media Servers with differing capabilities and capacities must be dynamically matched. Without an MRB, selecting an appropriate Media Server based on capability and availability in such topologies is intractable using static signaling alone.
Two distinct MRB deployment models are defined: Query MRB (AS explicitly queries MRB via HTTP or SIP before connecting to MS, MRB is off the signaling path) and In-line MRB (AS sends control/media signaling directly to MRB, which remains in the path). Both share the same Publish interface so MS implementations need not change.
In-line Unaware MRB Mode (IUMM) allows an MRB to function transparently for Application Servers with no knowledge of the MRB. The MRB deduces resource requirements by inspecting SDP content, the AS address, or Request-URI parameters (per RFC 4240), rather than receiving explicit <mediaResourceRequest> XML.
A successful Consumer interface response MUST contain a <response-session-info> element. The <session-id> MUST be included in all future related requests. The Consumer client MUST increment the returned <seq> value for each subsequent request in the same session.
If no available Media Server can be reached or all Control Channel negotiations fail, the MRB MUST reply with SIP 503 including a non-zero Retry-After header. The Application Server MUST NOT attempt a new session until the Retry-After period has passed.
In IAMM, the SIP INVITE MUST include a 'multipart/mixed' payload with one part of type 'application/sdp' (for the Control Channel) and one part of type 'application/mrb-consumer+xml' containing a <mediaResourceRequest> element without XML prolog.
In Query mode, the <mediaResourceRequest> MUST be carried in the body of an HTTP/HTTPS POST request. The media type MUST be 'application/mrb-consumer+xml' and MUST be reflected in Content-Type and Accept headers. The HTTP/HTTPS 200 response body MUST contain only an <mrbconsumer> with a single <mediaResourceResponse> child.
The first <subscription> MUST contain a non-zero 'seqnumber', and each subsequent subscription MUST contain a strictly higher 'seqnumber'. A lower or equal seqnumber MUST cause the Media Server to reply with status code 405 (Wrong sequence number).
The Media Server MUST reply with status 200 on success; 400 on syntax/schema error; 420 when an unrecognized attribute or element is present; 406 when a create request uses an already-existing 'id'; 404 when update/remove references a nonexistent subscription; and 401/402/403 for resource-exhaustion failures matching the action type.
The 'mrb-publish/1.0' Media Control Channel Framework Control Package MUST be implemented by any Media Server that wants to interact with an MRB entity.
The <seq> counter in Consumer requests is limited to the 0..2^31-1 range. If the counter reaches the maximum value, it MUST be reset to 0. The initial <seq> value SHOULD be randomly generated by the MRB to reduce the risk of session disruption by a malicious entity.
XML messages in CONTROL message bodies MUST contain either an <mrbrequest> or <mrbnotification> element. XML messages in REPORT message bodies MUST contain an <mrbresponse> element. Both MUST conform to the schema in Section 10.
The <encryption> element in <mrbnotification> declares Media Server support for SRTP media encryption per RFC 3711. Its presence implies DTLS-SRTP (RFC 5763) support. The element has no attributes or child elements.
The 'mrb-publish/1.0' Control Package is the Publish interface used by Media Servers to report capabilities and resource status to an MRB via the Media Control Channel Framework (RFC 6230). It defines <mrbrequest>, <mrbresponse>, and <mrbnotification> elements carried in CONTROL and REPORT messages.
The <mrbconsumer> root element wraps Consumer interface messages. It carries either a <mediaResourceRequest> (from AS to MRB) or a <mediaResourceResponse> (from MRB to AS). The Consumer interface supports both HTTP/HTTPS (Query mode) and SIP INVITE (IAMM) transports, using the 'application/mrb-consumer+xml' media type.
The <mrbnotification> element is sent by a Media Server to an MRB to report current status. It carries mandatory 'id' (matching the subscription session) and 'seqnumber' (independently increasing per-notification counter). Key child elements include <media-server-id>, <media-server-status>, <active-rtp-sessions>, <non-active-rtp-sessions>, <supported-codecs>, and <supported-packages>.
The <mrbpublish> root element wraps all Publish interface messages. Its 'version' attribute (fixed at '1.0') MUST be present, and it MUST NOT contain more than one child element (<mrbrequest>, <mrbresponse>, or <mrbnotification>) per message.
The <mrbresponse> element carries status codes for subscription operations: 200 OK, 400 Syntax error, 401/402/403 Unable to create/update/remove subscription, 404 Subscription does not exist, 405 Wrong sequence number, 406 Subscription already exists, 420 Unsupported attribute or element.
The <subscription> element (child of <mrbrequest>) manages subscription sessions. It carries mandatory attributes 'id' (unique session token), 'seqnumber' (monotonically increasing command counter), and 'action' (create/update/remove). Optional children <expires>, <minfrequency>, and <maxfrequency> are advisory; the Media Server MAY modify them and MUST report changes in its <mrbresponse>.
This document registers the 'mrb-publish/1.0' Control Package with the Media Control Channel Framework Package Registry (Section 13.1), and registers two new MIME types: 'application/mrb-publish+xml' (Section 13.2) and 'application/mrb-consumer+xml' (Section 13.3).
Two URN sub-namespace registrations are created: 'urn:ietf:params:xml:ns:mrb-publish' (Section 13.4) and 'urn:ietf:params:xml:ns:mrb-consumer' (Section 13.5). Corresponding XML Schema registrations are made for both the mrb-publish and mrb-consumer schemas (Sections 13.6 and 13.7).
The MRB Publish interface exposes consumed resource information (in addition to available resources) for monitoring purposes; implementations must take security implications into account, as unauthorized access to this data could expose internal infrastructure state. Access controls should be applied to restrict who can query consumed-resource data.
The <seq> value in Consumer sessions SHOULD be randomly initialized by the MRB to reduce the likelihood that a malicious entity (e.g., a rogue MRB) could predict and disrupt an existing session by injecting requests with valid sequence numbers. The 0..2^31-1 range provides the randomization space.
The <media-server-status> element (MUST be present in each <mrbnotification>) defines three Media Server states: 'active' (available for service), 'deactivated' (withdrawn from service, no new requests until active again), and 'unavailable' (processing existing requests but not accepting new ones until active again).