tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6917

 
 
 

Media Resource Brokering

Part 2 of 6, p. 12 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
5.  MRB Interface Definitions

   The intention of this specification is to provide a toolkit for a
   variety of deployment architectures where media resource brokering
   can take place.  Two main interfaces are required to support the
   differing requirements.  The two interfaces are described in the
   remainder of this section and have been named the Media Server
   Resource Publish and Media Server Resource Consumer interfaces.

   It is beyond the scope of this document to define exactly how to
   construct an MRB using the interfaces described.  It is, however,
   important that the two interfaces are complimentary so that
   development of appropriate MRB functionality is supported.

5.1.  Media Server Resource Publish Interface

   The Media Server Resource Publish interface is responsible for
   providing an MRB with appropriate Media Server resource information.
   As such, this interface is assumed to provide both general and
   specific details related to Media Server resources.  This information
   needs to be conveyed using an industry standard mechanism to provide
   increased levels of adoption and interoperability.  A Control Package
   for the Media Control Channel Framework will be specified to fulfill
   this interface requirement.  It provides an establishment and
   monitoring mechanism to enable a Media Server to report appropriate
   statistics to an MRB.  The Publish interface is used with both the
   Query mode and In-line mode of MRB operation.

   As already discussed in Section 1, the MRB view of Media Server
   resource availability will in reality be approximate -- i.e., partial
   and imperfect.  The MRB Publish interface does not provide an
   exhaustive view of current Media Server resource consumption; the
   Media Server may in some cases provide a best-effort computed view of
   resource consumption parameters conveyed in the Publish interface
   (e.g., Digital Signal Processors (DSPs) with a fixed number of

Top      Up      ToC       Page 13 
   streams versus Graphics Processing Units (GPUs) with CPU
   availability).  Media resource information may only be reported
   periodically over the Publish interface to an MRB.

   It is also worth noting that while the scope of the MRB is in
   providing interested Application Servers with the available
   resources, the MRB also allows for the retrieval of information about
   consumed resources.  While this is of course a relevant piece of
   information (e.g., for monitoring purposes), such functionality
   inevitably raises security considerations, and implementations should
   take this into account.  See Section 12 for more details.

   The MRB Publish interface uses the Media Control Channel Framework
   ([RFC6230]) as the basis for interaction between a Media Server and
   an MRB.  The Media Control Channel Framework uses an extension
   mechanism to allow specific usages that are known as Control
   Packages.  Section 5.1.1 defines the Control Package that MUST be
   implemented by any Media Server wanting to interact with an MRB
   entity.

5.1.1.  Control Package Definition

   This section fulfills the requirement for information that must be
   specified during the definition of a Control Framework package, as
   detailed in Section 8 of [RFC6230].

5.1.1.1.  Control Package Name

   The Media Channel Control Framework requires a Control Package
   definition to specify and register a unique name and version.

   The name and version of this Control Package is "mrb-publish/1.0".

5.1.1.2.  Framework Message Usage

   The MRB Publish interface allows a Media Server to convey available
   capabilities and resources to an MRB entity.

   This package defines XML elements in Section 5.1.2 and provides an
   XML schema in Section 10.

   The XML elements in this package are split into requests, responses,
   and event notifications.  Requests are carried in CONTROL message
   bodies; the <mrbrequest> element is defined as a package request.
   This request can be used for creating new subscriptions and updating/
   removing existing subscriptions.  Event notifications are also
   carried in CONTROL message bodies; the <mrbnotification> element is

Top      Up      ToC       Page 14 
   defined for package event notifications.  Responses are carried
   either in REPORT message or Control Framework 200 response bodies;
   the <mrbresponse> element is defined as a package-level response.

   Note that package responses are different from framework response
   codes.  Framework error response codes (see Section 7 of [RFC6230])
   are used when the request or event notification is invalid; for
   example, a request has invalid XML (400) or is not understood (500).
   Package-level responses are carried in framework 200 response or
   REPORT message bodies.  This package's response codes are defined in
   Section 5.1.4.

5.1.1.3.  Common XML Support

   The Media Control Channel Framework [RFC6230] requires a Control
   Package definition to specify if the attributes for media dialog or
   conference references are required.

   The Publish interface defined in Section 10 does import and make use
   of the common XML schema defined in the Media Control Channel
   Framework.

   The Consumer interface defined in Section 11 does import and make use
   of the common XML schema defined in the Media Control Channel
   Framework.

5.1.1.4.  CONTROL Message Body

   A valid CONTROL message body MUST conform to the schema defined in
   Section 10 and described in Section 5.1.2.  XML messages appearing in
   CONTROL messages MUST contain either an <mrbrequest> or
   <mrbnotification> element.

5.1.1.5.  REPORT Message Body

   A valid REPORT message body MUST conform to the schema defined in
   Section 10 and described in Section 5.1.2.  XML messages appearing in
   REPORT messages MUST contain an <mrbresponse> element.

5.1.1.6.  Audit

   The 'mrb-publish/1.0' Media Control Channel Framework package does
   not require any additional auditing capability.

Top      Up      ToC       Page 15 
5.1.2.  Element Definitions

   This section defines the XML elements for the Publish interface Media
   Control Channel package defined in Section 5.1.  The formal XML
   schema definition for the Publish interface can be found in
   Section 10.

   The root element is <mrbpublish>.  All other XML elements (requests,
   responses, notifications) are contained within it.  The MRB Publish
   interface request element is detailed in Section 5.1.3.  The MRB
   Publish interface notification element is detailed in Section 5.1.5.
   The MRB Publish interface response element is detailed in
   Section 5.1.4.

   The <mrbpublish> element has the following attributes:

   version:  a token specifying the mrb-publish package version.  The
      value is fixed as '1.0' for this version of the package.  The
      attribute MUST be present.

   The <mrbpublish> element has the following child elements, and there
   MUST NOT be more than one such child element in any <mrbpublish>
   message:

      <mrbrequest> for sending an MRB request.  See Section 5.1.3.

      <mrbresponse> for sending an MRB response.  See Section 5.1.4.

      <mrbnotification> for sending an MRB notification.  See
      Section 5.1.5.

5.1.3.  <mrbrequest>

   This section defines the <mrbrequest> element used to initiate
   requests from an MRB to a Media Server.  The element describes
   information relevant for the interrogation of a Media Server.

   The <mrbrequest> element has no defined attributes.

   The <mrbrequest> element has the following child element:

      <subscription> for initiating a subscription to a Media Server
      from an MRB.  See Section 5.1.3.1.

Top      Up      ToC       Page 16 
5.1.3.1.  <subscription>

   The <subscription> element is included in a request from an MRB to a
   Media Server to provide the details relating to the configuration of
   updates (known as a subscription session).  This element can be used
   either to request a new subscription or to update an existing one
   (e.g., to change the frequency of the updates), and to remove ongoing
   subscriptions as well (e.g., to stop an indefinite update).  The MRB
   will inform the Media Server regarding how long it wishes to receive
   updates and the frequency that updates should be sent.  Updates
   related to the subscription are sent using the <mrbnotification>
   element.

   The <subscription> element has the following attributes:

   id:  Indicates a unique token representing the subscription session
      between the MRB and the Media Server.  The attribute MUST be
      present.

   seqnumber:  Indicates a sequence number to be used in conjunction
      with the subscription session ID to identify a specific
      subscription command.  The first subscription MUST contain a
      non-zero number 'seqnumber', and subsequent subscriptions MUST
      contain a higher number than the previous 'seqnumber' value.  If a
      subsequent 'seqnumber' is not higher, a 405 response code is
      generated as per Section 5.1.4.  The attribute MUST be present.

   action:  Provides the operation that should be carried out on the
      subscription:

      *  The value of 'create' instructs the Media Server to attempt to
         set up a new subscription.

      *  The value of 'update' instructs the Media Server to attempt to
         update an existing subscription.

      *  The value of 'remove' instructs the Media Server to attempt to
         remove an existing subscription and consequently stop any
         ongoing related notification.

      The attribute MUST be present.

Top      Up      ToC       Page 17 
   The <subscription> element has zero or more of the following child
   elements:

   <expires>:  Provides the amount of time in seconds that a
      subscription should be installed for notifications at the Media
      Server.  Once the amount of time has passed, the subscription
      expires, and the MRB has to subscribe again if it is still
      interested in receiving notifications from the Media Server.  The
      element MAY be present.

   <minfrequency>:  Provides the minimum frequency in seconds that the
      MRB wishes to receive notifications from the Media Server.  The
      element MAY be present.

   <maxfrequency>:  Provides the maximum frequency in seconds that the
      MRB wishes to receive notifications from the Media Server.  The
      element MAY be present.

   Please note that these three optional pieces of information provided
   by the MRB only act as a suggestion: the Media Server MAY change the
   proposed values if it considers the suggestions unacceptable (e.g.,
   if the MRB has requested a notification frequency that is too high).
   In such a case, the request would not fail, but the updated,
   acceptable values would be reported in the <mrbresponse> accordingly.

5.1.4.  <mrbresponse>

   Responses to requests are indicated by an <mrbresponse> element.

   The <mrbresponse> element has the following attributes:

   status:  numeric code indicating the response status.  The attribute
      MUST be present.

   reason:  string specifying a reason for the response status.  The
      attribute MAY be present.

   The <mrbresponse> element has a single child element:

      <subscription> for providing details related to a subscription
      requested by a Media Server (see below in this section).

Top      Up      ToC       Page 18 
   The following status codes are defined for 'status':

   +-----------+-------------------------------------------------------+
   | code      | description                                           |
   +-----------+-------------------------------------------------------+
   | 200       | OK                                                    |
   |           |                                                       |
   | 400       | Syntax error                                          |
   |           |                                                       |
   | 401       | Unable to create Subscription                         |
   |           |                                                       |
   | 402       | Unable to update Subscription                         |
   |           |                                                       |
   | 403       | Unable to remove Subscription                         |
   |           |                                                       |
   | 404       | Subscription does not exist                           |
   |           |                                                       |
   | 405       | Wrong sequence number                                 |
   |           |                                                       |
   | 406       | Subscription already exists                           |
   |           |                                                       |
   | 420       | Unsupported attribute or element                      |
   +-----------+-------------------------------------------------------+

                    Table 1: <mrbresponse> Status Codes

   If a new subscription request made by an MRB (action='create') has
   been accepted, the Media Server MUST reply with an <mrbresponse> with
   status code 200.  The same rule applies whenever a request to update
   (action='update') or remove (action='remove') an existing transaction
   can be fulfilled by the Media Server.

   A subscription request, nevertheless, may fail for several reasons.
   In such a case, the status codes defined in Table 1 must be used
   instead.  Specifically, if the Media Server fails to handle a request
   due to a syntax error in the request itself (e.g., incorrect XML,
   violation of the schema constraints, or invalid values in any of the
   attributes/elements), the Media Server MUST reply with an
   <mrbresponse> with status code 400.  If a syntactically correct
   request fails because the request also includes any attribute/element
   the Media Server doesn't understand, the Media Server MUST reply with
   an <mrbresponse> with status code 420.  If a syntactically correct
   request fails because the MRB wants to create a new subscription, but
   the provided unique 'id' for the subscription already exists, the
   Media Server MUST reply with an <mrbresponse> with status code 406.
   If a syntactically correct request fails because the MRB wants to
   update/remove a subscription that doesn't exist, the Media Server
   MUST reply with an <mrbresponse> with status code 404.  If the Media

Top      Up      ToC       Page 19 
   Server is unable to accept a request for any other reason (e.g., the
   MRB has no more resources to fulfill the request), the Media Server
   MUST reply with an <mrbresponse> with status code 401/402/403,
   depending on the action the MRB provided in its request:

   o  action='create' --> 401;

   o  action='update' --> 402;

   o  action='remove' --> 403;

   A response to a subscription request that has a status code of 200
   indicates that the request is successful.  The response MAY also
   contain a <subscription> child that describes the subscription.  The
   <subscription> child MAY contain 'expires', 'minfrequency', and
   'maxfrequency' values even if they were not contained in the request.

   The Media Server can choose to change the suggested 'expires',
   'minfrequency', and 'maxfrequency' values provided by the MRB in its
   <mrbrequest> if it considers them unacceptable (e.g., the requested
   frequency range is too high).  In such a case, the response MUST
   contain a <subscription> element describing the subscription as the
   Media Server accepted it, and the Media Server MUST include in the
   <subscription> element all of those values that it modified relative
   to the request, to inform the MRB about the change.

5.1.5.  <mrbnotification>

   The <mrbnotification> element is included in a request from a Media
   Server to an MRB to provide the details relating to current status.
   The Media Server will inform the MRB of its current status as defined
   by the information in the <subscription> element.  Updates are sent
   using the <mrbnotification> element.

   The <mrbnotification> element has the following attributes:

   id:  indicates a unique token representing the session between the
      MRB and the Media Server and is the same as the one appearing in
      the <subscription> element.  The attribute MUST be present.

   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session ID to identify a specific
      notification update.  The first notification update MUST contain a
      non-zero number 'seqnumber', and subsequent notification updates
      MUST contain a higher number than the previous 'seqnumber' value.
      If a subsequent 'seqnumber' is not higher, the situation should be

Top      Up      ToC       Page 20 
      considered an error by the entity receiving the notification
      update.  How the receiving entity deals with this situation is
      implementation specific.  The attribute MUST be present.

   It's important to point out that the 'seqnumber' that appears in an
   <mrbnotification> is not related to the 'seqnumber' appearing in a
   <subscription>.  In fact, the latter is associated with subscriptions
   and would increase at every command issued by the MRB, while the
   former is associated with the asynchronous notifications the Media
   Server would trigger according to the subscription and as such would
   increase at every notification message to enable the MRB to keep
   track of them.

   The following sub-sections provide details of the child elements that
   make up the contents of the <mrbnotification> element.

5.1.5.1.  <media-server-id>

   The <media-server-id> element provides a unique system-wide
   identifier for a Media Server instance.  The element MUST be present
   and MUST be chosen such that it is extremely unlikely that two
   different Media Servers would present the same id to a given MRB.

5.1.5.2.  <supported-packages>

   The <supported-packages> element provides the list of Media Control
   Channel packages supported by the Media Server.  The element MAY be
   present.

   The <supported-packages> element has no attributes.

   The <supported-packages> element has a single child element:

   <package>:  Gives the name of a package supported by the Media
      Server.  The <package> element has a single attribute, 'name',
      which provides the name of the supported Media Control Channel
      Framework package, compliant with Section 13.1.1 of [RFC6230].

5.1.5.3.  <active-rtp-sessions>

   The <active-rtp-sessions> element provides information detailing the
   current active Real-time Transport Protocol (RTP) sessions.  The
   element MAY be present.

   The <active-rtp-sessions> element has no attributes.

Top      Up      ToC       Page 21 
   The <active-rtp-sessions> element has a single child element:

   <rtp-codec>:  Describes a supported codec and the number of active
      sessions using that codec.  The <rtp-codec> element has one
      attribute.  The value of the attribute, 'name', is a media type
      (which can include parameters per [RFC6381]).  The <rtp-codec>
      element has two child elements.  The child element <decoding> has
      as content the decimal number of RTP sessions being decoded using
      the specified codec, and the child element <encoding> has as
      content the decimal number of RTP sessions being encoded using the
      specified codec.

5.1.5.4.  <active-mixer-sessions>

   The <active-mixer-sessions> element provides information detailing
   the current active mixed RTP sessions.  The element MAY be present.

   The <active-mixer-sessions> element has no attributes.

   The <active-mixer-sessions> element has a single child element:

   <active-mix>:  Describes a mixed active RTP session.  The
      <active-mix> element has one attribute.  The value of the
      attribute, 'conferenceid', is the name of the mix.  The
      <active-mix> element has one child element.  The child element,
      <rtp-codec>, contains the same information relating to RTP
      sessions as that defined in Section 5.1.5.3.  The element MAY be
      present.

5.1.5.5.  <non-active-rtp-sessions>

   The <non-active-rtp-sessions> element provides information detailing
   the currently available inactive RTP sessions, that is, how many more
   RTP streams this Media Server can support.  The element MAY be
   present.

   The <non-active-rtp-sessions> element has no attributes.

   The <non-active-rtp-sessions> element has a single child element:

   <rtp-codec>:  Describes a supported codec and the number of
      non-active sessions for that codec.  The <rtp-codec> element has
      one attribute.  The value of the attribute, 'name', is a media
      type (which can include parameters per [RFC6381]).  The
      <rtp-codec> element has two child elements.  The child element
      <decoding> has as content the decimal number of RTP sessions

Top      Up      ToC       Page 22 
      available for decoding using the specified codec, and the child
      element <encoding> has as content the decimal number of RTP
      sessions available for encoding using the specified codec.

5.1.5.6.  <non-active-mixer-sessions>

   The <non-active-mixer-sessions> element provides information
   detailing the current inactive mixed RTP sessions, that is, how many
   more mixing sessions this Media Server can support.  The element MAY
   be present.

   The <non-active-mixer-sessions> element has no attributes.

   The <non-active-mixer-sessions> element has a single child element:

   <non-active-mix>:  Describes available mixed RTP sessions.  The
      <non-active-mix> element has one attribute.  The value of the
      attribute, 'available', is the number of mixes that could be used
      using that profile.  The <non-active-mix> element has one child
      element.  The child element, <rtp-codec>, contains the same
      information relating to RTP sessions as that defined in
      Section 5.1.5.5.  The element MAY be present.

5.1.5.7.  <media-server-status>

   The <media-server-status> element provides information detailing the
   current status of the Media Server.  The element MUST be present.  It
   can return one of the following values:

   active:  Indicates that the Media Server is available for service.

   deactivated:  Indicates that the Media Server has been withdrawn from
      service, and as such requests should not be sent to it before it
      becomes 'active' again.

   unavailable:  Indicates that the Media Server continues to process
      past requests but cannot accept new requests, and as such should
      not be contacted before it becomes 'active' again.

   The <media-server-status> element has no attributes.

   The <media-server-status> element has no child elements.

Top      Up      ToC       Page 23 
5.1.5.8.  <supported-codecs>

   The <supported-codecs> element provides information detailing the
   current codecs supported by a Media Server and associated actions.
   The element MAY be present.

   The <supported-codecs> element has no attributes.

   The <supported-codecs> element has a single child element:

   <supported-codec>:  Has a single attribute, 'name', which provides
      the name of the codec about which this element provides
      information.  A valid value is a media type that, depending on its
      definition, can include additional parameters (e.g., [RFC6381]).
      The <supported-codec> element then has a further child element,
      <supported-codec-package>.  The <supported-codec-package> element
      has a single attribute, 'name', which provides the name of the
      Media Control Channel Framework package, compliant with
      Section 13.1.1 of [RFC6230], for which the codec support applies.
      The <supported-codec-package> element has zero or more
      <supported-action> children, each one of which describes an action
      that a Media Server can apply to this codec:

      *  'decoding', meaning a decoder for this codec is available;

      *  'encoding', meaning an encoder for this codec is available;

      *  'passthrough', meaning the Media Server is able to pass a
         stream encoded using that codec through, without re-encoding.

5.1.5.9.  <application-data>

   The <application-data> element provides an arbitrary string of
   characters as application-level data.  This data is meant to only
   have meaning at the application-level logic and as such is not
   otherwise restricted by this specification.  The set of allowed
   characters is the same as those in XML (viz., tab, carriage return,
   line feed, and the legal characters of Unicode and ISO/IEC 10646
   [ISO.10646.2012] (see also Section 2.2 of
   <http://www.w3.org/TR/xml/>)).  The element MAY be present.

   The <application-data> element has no attributes.

   The <application-data> element has no child elements.

Top      Up      ToC       Page 24 
5.1.5.10.  <file-formats>

   The <file-formats> element provides a list of file formats supported
   for the purpose of playing media.  The element MAY be present.

   The <file-formats> element has no attributes.

   The <file-formats> element has zero of more the following child
   elements:

   <supported-format>:  Has a single attribute, 'name', which provides
      the type of file format that is supported.  A valid value is a
      media type that, depending on its definition, can include
      additional parameters (e.g., [RFC6381]).  The <supported-format>
      element then has a further child element,
      <supported-file-package>.  The <supported-file-package> element
      provides the name of the Media Control Channel Framework package,
      compliant with Section 13.1.1 of [RFC6230], for which the file
      format support applies.

5.1.5.11.  <max-prepared-duration>

   The <max-prepared-duration> element provides the maximum amount of
   time a media dialog will be kept in the prepared state before timing
   out (see Section 4.4.2.2.6 of RFC 6231 [RFC6231].  The element MAY be
   present.

   The <max-prepared-duration> element has no attributes.

   The <max-prepared-duration> element has a single child element:

   <max-time>:  Has a single attribute, 'max-time-seconds', which
      provides the amount of time in seconds that a media dialog can be
      in the prepared state.  The <max-time> element then has a further
      child element, <max-time-package>.  The <max-time-package> element
      provides the name of the Media Control Channel Framework package,
      compliant with Section 13.1.1 of [RFC6230], for which the time
      period applies.

Top      Up      ToC       Page 25 
5.1.5.12.  <dtmf-support>

   The <dtmf-support> element specifies the supported methods to detect
   Dual-Tone Multi-Frequency (DTMF) tones and to generate them.  The
   element MAY be present.

   The <dtmf-support> element has no attributes.

   The <dtmf-support> element has zero of more of the following child
   elements:

   <detect>:  Indicates the support for DTMF detection.  The <detect>
      element has no attributes.  The <detect> element then has a
      further child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes: 'name' and 'package'.  The 'name' attribute
      provides the type of DTMF being used, and it can only be a case-
      insensitive string containing either 'RFC4733' [RFC4733] or
      'Media' (detecting tones as signals from the audio stream).  The
      'package' attribute provides the name of the Media Control Channel
      Framework package, compliant with Section 13.1.1 of [RFC6230], for
      which the DTMF type applies.

   <generate>:  Indicates the support for DTMF generation.  The
      <generate> element has no attributes.  The <generate> element then
      has a further child element, <dtmf-type>.  The <dtmf-type> element
      has two attributes: 'name' and 'package'.  The 'name' attribute
      provides the type of DTMF being used, and it can only be a case-
      insensitive string containing either 'RFC4733' [RFC4733] or
      'Media' (generating tones as signals in the audio stream).  The
      'package' attribute provides the name of the Media Control Channel
      Framework package, compliant with Section 13.1.1 of [RFC6230], for
      which the DTMF type applies.

   <passthrough>:  Indicates the support for passing DTMF through
      without re-encoding.  The <passthrough> element has no attributes.
      The <passthrough> element then has a further child element,
      <dtmf-type>.  The <dtmf-type> element has two attributes: 'name'
      and 'package'.  The 'name' attribute provides the type of DTMF
      being used, and it can only be a case-insensitive string
      containing either 'RFC4733' [RFC4733] or 'Media' (passing tones as
      signals through the audio stream).  The 'package' attribute
      provides the name of the Media Control Channel Framework package,
      compliant with Section 13.1.1 of [RFC6230], for which the DTMF
      type applies.

Top      Up      ToC       Page 26 
5.1.5.13.  <mixing-modes>

   The <mixing-modes> element provides information about the support for
   audio and video mixing of a Media Server, specifically a list of
   supported algorithms to mix audio and a list of supported video
   presentation layouts.  The element MAY be present.

   The <mixing-modes> element has no attributes.

   The <mixing-modes> element has zero or more of the following child
   elements:

   <audio-mixing-modes>:  Describes the available algorithms for audio
      mixing.  The <audio-mixing-modes> element has no attributes.  The
      <audio-mixing-modes> element has one child element.  The child
      element, <audio-mixing-mode>, contains a specific available
      algorithm.  Valid values for the <audio-mixing-mode> element are
      algorithm names, e.g., 'nbest' and 'controller' as defined in
      [RFC6505].  The element has a single attribute, 'package'.  The
      attribute 'package' provides the name of the Media Control Channel
      Framework package, compliant with Section 13.1.1 of [RFC6230], for
      which the algorithm support applies.

   <video-mixing-modes>:  Describes the available video presentation
      layouts and the supported functionality related to video mixing.
      The <video-mixing-modes> element has two attributes: 'vas' and
      'activespeakermix'.  The 'vas' attribute is of type boolean with a
      value of 'true' indicating that the Media Server supports
      automatic Voice Activated Switching.  The 'activespeakermix' is of
      type boolean with a value of 'true' indicating that the Media
      Server is able to prepare an additional video stream for the
      loudest speaker participant without its contribution.  The
      <video-mixing-modes> element has one child element.  The child
      element, <video-mixing-mode>, contains the name of a specific
      video presentation layout.  The name may refer to one of the
      predefined video layouts defined in the XCON conference
      information data model [RFC6501], or to non-XCON layouts as well,
      as long as they are properly prefixed according to the schema they
      belong to.  The <video-mixing-mode> element has a single
      attribute, 'package'.  The attribute 'package' provides the name
      of the Media Control Channel Framework package, compliant with
      Section 13.1.1 of [RFC6230], for which the algorithm support
      applies.

Top      Up      ToC       Page 27 
5.1.5.14.  <supported-tones>

   The <supported-tones> element provides information about which tones
   a Media Server is able to play and recognize.  In particular, the
   support is reported by referring to both support for country codes
   (ISO 3166-1 [ISO.3166-1]) and supported functionality (ITU-T
   Recommendation Q.1950 [ITU-T.Q.1950]).  The element MAY be present.

   The <supported-tones> element has no attributes.

   The <supported-tones> element has zero or more of the following child
   elements:

   <supported-country-codes>:  Describes the supported country codes
      with respect to tones.  The <supported-country-codes> element has
      no attributes.  The <supported-country-codes> element has one
      child element.  The child element, <country-code>, reports support
      for a specific country code, compliant with the ISO 3166-1
      [ISO.3166-1] specification.  The <country-code> element has a
      single attribute, 'package'.  The attribute 'package' provides the
      name of the Media Control Channel Framework package, compliant
      with Section 13.1.1 of [RFC6230], in which the tones from the
      specified country code are supported.

   <supported-h248-codes>:  Describes the supported H.248 codes with
      respect to tones.  The <supported-h248-codes> element has no
      attributes.  The <supported-h248-codes> element has one child
      element.  The child element, <h248-code>, reports support for a
      specific H.248 code, compliant with the ITU-T Recommendation
      Q.1950 [ITU-T.Q.1950] specification.  The codes can be either
      specific (e.g., cg/dt to only report the Dial Tone from the Call
      Progress Tones package) or generic (e.g., cg/* to report all the
      tones from the Call Progress Tones package), using wildcards.  The
      <h248-code> element has a single attribute, 'package'.  The
      attribute 'package' provides the name of the Media Control Channel
      Framework package, compliant with Section 13.1.1 of [RFC6230], in
      which the specified codes are supported.

5.1.5.15.  <file-transfer-modes>

   The <file-transfer-modes> element allows the Media Server to specify
   which scheme names are supported for transferring files to a Media
   Server for each Media Control Channel Framework package type, for
   example, whether the Media Server supports fetching resources via
   HTTP, HTTPS, NFS, etc.  The element MAY be present.

   The <file-transfer-modes> element has no attributes.

Top      Up      ToC       Page 28 
   The <file-transfer-modes> element has a single child element:

   <file-transfer-mode>:  Has two attributes: 'name' and 'package'.  The
      'name' attribute provides the scheme name of the protocol that can
      be used for file transfer (e.g., HTTP, HTTPS, NFS, etc.); the
      value of the attribute is case insensitive.  The 'package'
      attribute provides the name of the Media Control Channel Framework
      package, compliant with the specification in the related IANA
      registry (e.g., "msc-ivr/1.0"), for which the scheme name applies.

   It is important to point out that this element provides no
   information about whether or not the Media Server supports any flavor
   of live streaming: for instance, a value of "HTTP" for the IVR
   (Interactive Voice Response) Package would only mean the 'http'
   scheme makes sense to the Media Server within the context of that
   package.  Whether or not the Media Server can make use of HTTP to
   only fetch resources, or also to attach an HTTP live stream to a
   call, is to be considered implementation specific to the Media Server
   and irrelevant to the Application Server and/or MRB.  Besides, the
   Media Server supporting a scheme does not imply that it also supports
   the related secure versions: for instance, if the Media Server
   supports both HTTP and HTTPS, both the schemes will appear in the
   element.  A lack of the "HTTPS" value would need to be interpreted as
   a lack of support for the 'https' scheme.

5.1.5.16.  <asr-tts-support>

   The <asr-tts-support> element provides information about the support
   for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
   functionality in a Media Server.  The functionality is reported by
   referring to the supported languages (using ISO 639-1 [ISO.639.2002]
   codes) regarding both ASR and TTS.  The element MAY be present.

   The <asr-tts-support> element has no attributes.

   The <asr-tts-support> element has zero or more of the following child
   elements:

   <asr-support>:  Describes the available languages for ASR.  The
      <asr-support> element has no attributes.  The <asr-support>
      element has one child element.  The child element, <language>,
      reports that the Media Server supports ASR for a specific
      language.  The <language> element has a single attribute,
      'xml:lang'.  The attribute 'xml:lang' contains the ISO 639-1
      [ISO.639.2002] code of the supported language.

Top      Up      ToC       Page 29 
   <tts-support>:  Describes the available languages for TTS.  The
      <tts-support> element has no attributes.  The <tts-support>
      element has one child element.  The child element, <language>,
      reports that the Media Server supports TTS for a specific
      language.  The <language> element has a single attribute,
      'xml:lang'.  The attribute 'xml:lang' contains the ISO 639-1
      [ISO.639.2002] code of the supported language.

5.1.5.17.  <vxml-support>

   The <vxml-support> element specifies if the Media Server supports
   VoiceXML (VXML) and, if it does, through which protocols the support
   is exposed (e.g., via the control framework, RFC 4240 [RFC4240], or
   RFC 5552 [RFC5552]).  The element MAY be present.

   The <vxml-support> element has no attributes.

   The <vxml-support> element has a single child element:

   <vxml-mode>:  Has two attributes: 'package' and 'support'.  The
      'package' attribute provides the name of the Media Control Channel
      Framework package, compliant with Section 13.1.1 of [RFC6230], for
      which the VXML support applies.  The 'support' attribute provides
      the type of VXML support provided by the Media Server (e.g.,
      RFC 5552 [RFC5552], RFC 4240 [RFC4240], or the IVR Package
      [RFC6231]), and valid values are case-insensitive RFC references
      (e.g., "rfc6231" to specify that the Media Server supports
      VoiceXML as provided by the IVR Package [RFC6231]).

   The presence of at least one <vxml-mode> child element would indicate
   that the Media Server does support VXML as specified by the child
   element itself.  An empty <vxml> element would otherwise indicate
   that the Media Server does not support VXML at all.

5.1.5.18.  <media-server-location>

   The <media-server-location> element provides information about the
   civic location of a Media Server.  Its description makes use of the
   Civic Address Schema standardized in RFC 5139 [RFC5139].  The element
   MAY be present.  More precisely, this section is entirely optional,
   and it's implementation specific to fill it with just the details
   each implementer deems necessary for any optimization that may be
   needed.

   The <media-server-location> element has no attributes.

Top      Up      ToC       Page 30 
   The <media-server-location> element has a single child element:

   <civicAddress>:  Describes the civic address location of the Media
      Server, whose representation refers to Section 4 of RFC 5139
      [RFC5139].

5.1.5.19.  <label>

   The <label> element allows a Media Server to declare a piece of
   information that will be understood by the MRB.  For example, the
   Media Server can declare if it's a blue or green one.  It's a string
   to allow arbitrary values to be returned to allow arbitrary
   classification.  The element MAY be present.

   The <label> element has no attributes.

   The <label> element has no child elements.

5.1.5.20.  <media-server-address>

   The <media-server-address> element allows a Media Server to provide a
   direct SIP URI where it can be reached (e.g., the URI that the
   Application Server would call in order to set up a Control Channel
   and relay SIP media dialogs).  The element MAY be present.

   The <media-server-address> element has no attributes.

   The <media-server-address> element has no child elements.

5.1.5.21.  <encryption>

   The <encryption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server
   supports DTLS-SRTP (a Secure Real-time Transport Protocol (SRTP)
   extension for Datagram Transport Layer Security (DTLS)) [RFC5763].

   The <encryption> element has no attributes.

   The <encryption> element has no child elements.

5.2.  Media Service Resource Consumer Interface

   The Media Server Consumer interface provides the ability for clients
   of an MRB, such as Application Servers, to request an appropriate
   Media Server to satisfy specific criteria.  This interface allows a
   client to pass detailed meta-information to the MRB to help select an
   appropriate Media Server.  The MRB is then able to make an informed

Top      Up      ToC       Page 31 
   decision and provide the client with an appropriate Media Server
   resource.  The MRB Consumer interface includes both 1) the In-line
   Aware MRB Mode (IAMM), which uses the Session Initiation Protocol
   (SIP) and 2) the Query mode, which uses the Hypertext Transfer
   Protocol (HTTP) [RFC2616].  The MRB Consumer interface does not
   include the In-line Unaware Mode (IUMM), which is further explained
   in Section 5.3.  The following sub-sections provide guidance on
   using the Consumer interface, which is represented by the
   'application/mrb-consumer+xml' media type in Section 11, with HTTP
   and SIP.

5.2.1.  Query Mode/HTTP Consumer Interface Usage

   An appropriate interface for such a 'query' style interface is in
   fact an HTTP usage.  Using HTTP and XML combined reduces complexity
   and encourages the use of common tools that are widely available in
   the industry today.  The following information explains the primary
   operations required to request and then receive information from an
   MRB, by making use of HTTP [RFC2616] and HTTPS [RFC2818] as transport
   for a query for a media resource, and the appropriate response.

   The media resource query, as defined by the <mediaResourceRequest>
   element from Section 11, MUST be carried in the body of an HTTP/HTTPS
   POST request.  The media type contained in the HTTP/HTTPS request/
   response MUST be 'application/mrb-consumer+xml'.  This value MUST be
   reflected in the appropriate HTTP headers, such as 'Content-Type' and
   'Accept'.  The body of the HTTP/HTTPS POST request MUST only contain
   an <mrbconsumer> root element with only one child
   <mediaResourceRequest> element as defined in Section 11.

   The media resource response to a query, as defined by the
   <mediaResourceResponse> element from Section 11, MUST be carried in
   the body of an HTTP/HTTPS 200 response to the original HTTP/HTTPS
   POST request.  The media type contained in the HTTP/HTTPS request/
   response MUST be 'application/mrb-consumer+xml'.  This value MUST be
   reflected in the appropriate HTTP headers, such as 'Content-Type' and
   'Accept'.  The body of the HTTP/HTTPS 200 response MUST only contain
   an <mrbconsumer> root element with only one child
   <mediaResourceResponse> element as defined in Section 11.

   When an Application Server wants to release previously awarded media
   resources granted through a prior request/response exchange with an
   MRB, it will send a new request with an <action> element with value
   'remove', as described in Section 5.2.3 ("Consumer Interface Lease
   Mechanism").

Top      Up      ToC       Page 32 
5.2.2.  In-Line Aware Mode/SIP Consumer Interface Usage

   This document provides a complete toolkit for MRB deployment that
   includes the ability to interact with an MRB using SIP for the
   Consumer interface.  The following information explains the primary
   operations required to request and then receive information from an
   MRB, by making use of SIP [RFC3261] as transport for a request for
   media resources, and the appropriate response when using IAMM as the
   mode of operation (as discussed in Section 5.2.2.1).

   The use of IAMM, besides having the MRB select appropriate media
   resources on behalf of a client application, includes setting up
   either a Control Framework Control Channel between an Application
   Server and one of the Media Servers (Section 5.2.2.1) or a media
   dialog session between an Application Server and one of the Media
   Servers (Section 5.2.2.2).  Note that in either case the SIP URIs of
   the selected Media Servers are made known to the requesting
   Application Server in the SIP 200 OK response by means of one or more
   <media-server-address> child elements in the <response-session-info>
   element (Section 5.2.6).

5.2.2.1.  IAMM and Setting Up a Control Framework Control Channel

   The media resource request information, as defined by the
   <mediaResourceRequest> element from Section 11, is carried in a SIP
   INVITE request.  The INVITE request will be constructed as it would
   have been to connect to a Media Server, as defined by the Media
   Control Channel Framework [RFC6230].  It should be noted that this
   specification does not exclude the use of an offerless INVITE as
   defined in RFC 3261 [RFC3261].  Using offerless INVITE messages to an
   MRB can potentially cause confusion when applying resource selection
   algorithms, and an MRB, like any other SIP device, can choose to
   reject with a 4xx response.  For an offerless INVITE to be treated
   appropriately, additional contextual information would need to be
   provided with the request; this is out of scope for this document.
   The following additional steps MUST be followed when using the
   Consumer interface:

   o  The Consumer client will include a payload in the SIP INVITE
      request of type 'multipart/mixed' [RFC2046].  One of the parts to
      be included in the 'multipart/mixed' payload MUST be the
      'application/sdp' format, which is constructed as specified in the
      Media Control Channel Framework [RFC6230].

   o  Another part of the 'multipart/mixed' payload MUST be of type
      'application/mrb-consumer+xml', as specified in this document and
      defined in Section 11.  The body part MUST be an XML document
      without prolog and whose root element is <mediaResourceRequest>.

Top      Up      ToC       Page 33 
   o  The INVITE request will then be dispatched to the MRB, as defined
      by [RFC6230].

   On receiving a SIP INVITE request containing the multipart/mixed
   payload as specified previously, the MRB will complete a number of
   steps to fulfill the request.  It will:

   o  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 (or Media Servers, if more than one is deemed to be
      needed) should be selected to service the request.

   o  Extract the 'application/sdp' part from the payload and use it as
      the body of a new SIP INVITE request for connecting the client to
      one of the selected Media Servers, as defined in the Media Channel
      Control Framework [RFC6230].  The policy the MRB follows to pick a
      specific Media Server out of the Media Servers it selects is
      implementation specific and out of scope for this document.  It is
      important to configure the SIP elements between the MRB and the
      Media Server in such a way that the INVITE will not fork.  In the
      case of a failure in reaching the chosen Media Server, the MRB
      SHOULD proceed to the next one, if available.

   If none of the available Media Servers can be reached, the MRB MUST
   reply with a SIP 503 error message that includes a Retry-After header
   with a non-zero value.  The Application Server MUST NOT attempt to
   set up a new session before the time that the MRB asked it to wait
   has passed.

   If at least one Media Server is reachable, the MRB acts as a Back-to-
   Back User Agent (B2BUA) that extracts the 'application/
   mrb-consumer+xml' information from the SIP INVITE request and then
   sends a corresponding SIP INVITE request to the Media Server it has
   selected, to negotiate a Control Channel as defined in the Media
   Channel Control Framework [RFC6230].

   In the case of a failure in negotiating the Control Channel with the
   Media Server, the MRB SHOULD proceed to the next one, if available,
   as explained above.  If none of the available Media Servers can be
   reached, or the negotiations of the Control Channel with all of them
   fail, the MRB MUST reply with a SIP 503 error message that includes a
   Retry-After header with a non-zero value.  The Application Server
   MUST NOT attempt to set up a new session before the time that the MRB
   asked it to wait has expired.

Top      Up      ToC       Page 34 
   Once the MRB receives the SIP response from the selected media
   resource (i.e., Media Server), it will in turn respond to the
   requesting client (i.e., Application Server).

   The media resource response generated by an MRB to a request, as
   defined by the <mediaResourceResponse> element from Section 11, MUST
   be carried in the payload of a SIP 200 OK response to the original
   SIP INVITE request.  The SIP 200 OK response will be constructed as
   it would have been to connect from a Media Server, as defined by the
   Media Control Channel Framework [RFC6230].  The following additional
   steps MUST be followed when using the Consumer interface:

   o  Include a payload in the SIP 200 response of type 'multipart/
      mixed' as per RFC 2046 [RFC2046].  One of the parts to be included
      in the 'multipart/mixed' payload MUST be the 'application/sdp'
      format, which is constructed as specified in the Media Control
      Channel Framework [RFC6230] and based on the incoming response
      from the selected media resource.

   o  Another part of the 'multipart/mixed' payload MUST be of type
      'application/mrb-consumer+xml', as specified in this document and
      defined in Section 11.  Only the <mediaResourceResponse> and its
      child elements can be included in the payload.

   o  The SIP 200 response will then be dispatched from the MRB.

   o  A SIP ACK to the 200 response will then be sent back to the MRB.

   Considering that the use of SIP as a transport for Consumer
   transactions may result in failure, the IAMM relies on a successful
   INVITE transaction to address the previously discussed sequence
   (using the 'seq' XML element) increment mechanism.  This means that
   if the INVITE is unsuccessful for any reason, the Application Server
   MUST use the same 'seq' value as previously used for the next
   Consumer request that it may want to send to the MRB for the same
   session.

   An MRB implementation may be programmed to conclude that the
   requested resources are no longer needed when it receives a SIP BYE
   from the Application Server or Media Server that concludes the SIP
   dialog that initiated the request, or when the lease (Section 5.2.3)
   interval expires.

Top      Up      ToC       Page 35 
5.2.2.2.  IAMM and Setting Up a Media Dialog

   This scenario is identical to the description in the previous section
   for setting up a Control Framework Control Channel, with the
   exception that the application/sdp payload conveys content
   appropriate for setting up the media dialog to the media resource, as
   per RFC 3261 [RFC3261], instead of setting up a Control Channel.

5.2.3.  Consumer Interface Lease Mechanism

   The Consumer interface defined in Sections 5.2 and 11 allows a client
   to request an appropriate media resource based on information
   included in the request (either an HTTP POST or SIP INVITE message).
   In the case of success, the response that is returned to the client
   MUST contain a <response-session-info> element in either the SIP 200
   or HTTP 200 response.  The success response contains the description
   of certain resources that have been reserved to a specific Consumer
   client in a (new or revised) "resource session", which is identified
   in the <response-session-info>.  The resource session is a "lease",
   in that the reservation is scheduled to expire at a particular time
   in the future, releasing the resources to be assigned for other uses.
   The lease may be extended or terminated earlier by future Consumer
   client requests that identify and reference a specific resource
   session.

   Before delving into the details of such a lease mechanism, it is
   worth clarifying its role within the context of the Consumer
   interface.  As explained in Section 5.1, the knowledge the MRB has of
   the resources of all the Media Servers it is provisioned to manage is
   not real-time.  How an MRB actually manages such resources is
   implementation specific -- for example, an implementation may choose
   to have the MRB keeping track and state of the allocated resources,
   or simply rely on the Media Servers themselves to provide the
   information using the Publish interface.  Further information may
   also be inferred by the signaling, in the case where an MRB is in the
   path of media dialogs.

Top      Up      ToC       Page 36 
   The <mediaResourceResponse> element returned from the MRB contains a
   <response-session-info> element if the request is successful.  The
   <response-session-info> element has zero or more of the following
   child elements, which provide the appropriate resource session
   information:

   o  <session-id> is a unique identifier that enables a Consumer client
      and MRB to correlate future media resource requests related to an
      initial media resource request.  The <session-id> MUST be included
      in all future related requests (see the <session-id> paragraph
      later in this section, where constructing a subsequent request is
      discussed).

   o  <seq> is a numeric value returned to the Consumer client.  On
      issuing any future requests related to the media resource session
      (as determined by the <session-id> element), the Consumer client
      MUST increment the value returned in the <seq> element and include
      it in the request (see the <seq> paragraph later in this section,
      where constructing a subsequent request is discussed).  Its value
      is a non-negative integer that MUST be limited within the
      0..2^31-1 range.

   o  <expires> provides a value indicating the number of seconds that
      the request for media resources is deemed alive.  The Consumer
      client should issue a refresh of the request, as discussed later
      in this section, if the expiry is due to fire and the media
      resources are still required.

   o  <media-server-address> provides information representing an
      assigned Media Server.  More instances of this element may appear
      should the MRB assign more Media Servers to a Consumer request.

   The <mediaResourceRequest> element is used in subsequent Consumer
   interface requests if the client wishes to manipulate the session.
   The Consumer client MUST include the <session-info> element, which
   enables the receiving MRB to determine an existing media resource
   allocation session.  The <session-info> element has the following
   child elements, which provide the appropriate resource session
   information to the MRB:

   o  <session-id> is a unique identifier that allows a Consumer client
      to indicate the appropriate existing media resource session to be
      manipulated by the MRB for this request.  The value was provided
      by the MRB in the initial request for media resources, as
      discussed earlier in this section (<session-id> element included
      as part of the <session-info> element in the initial
      <mediaResourceResponse>).

Top      Up      ToC       Page 37 
   o  <seq> is a numeric value returned to the Consumer client in the
      initial request for media resources, as discussed earlier in this
      section (<seq> element included as part of the <session-info>
      element in the initial <mediaResourceResponse>).  On issuing any
      future requests related to the specific media resource session (as
      determined by the <session-id> element), the Consumer client MUST
      increment the value returned in the <seq> element from the initial
      response (contained in the <mediaResourceResponse>) for every new
      request.  The value of the <seq> element in requests acts as a
      counter and when used in conjunction with the unique <session-id>
      allows for unique identification of a request.  As anticipated
      before, the <seq> value is limited to the 0..2^31-1 range: in the
      unlikely case that the counter increases to reach the highest
      allowed value, the <seq> value MUST be set to 0.  The first
      numeric value for the <seq> element is not meant to be '1' but
      SHOULD be generated randomly by the MRB: this is to reduce the
      chances of a malicious MRB disrupting the session created by this
      MRB, as explained in Section 12.

   o  <action> provides the operation to be carried out by the MRB on
      receiving the request:

      *  The value of 'update' is a request by the Consumer client to
         update the existing session on the MRB with alternate media
         resource requirements.  If the requested resource information
         is identical to the existing MRB session, the MRB will attempt
         a session refresh.  If the information has changed, the MRB
         will attempt to update the existing session with the new
         information.  If the operation is successful, the 200 status
         code in the response is returned in the status attribute of the
         <mediaResourceResponseType> element.  If the operation is not
         successful, a 409 status code in the response is returned in
         the status attribute of the <mediaResourceResponseType>
         element.

      *  The value of 'remove' is a request by the Consumer client to
         remove the session on the MRB.  This provides a mechanism for
         Consumer clients to release unwanted resources before they
         expire.  If the operation is successful, a 200 status code in
         the response is returned in the status attribute of the
         <mediaResourceResponseType> element.  If the operation is not
         successful, a 410 status code in the response is returned in
         the status attribute of the <mediaResourceResponseType>
         element.

   Omitting the 'action' attribute means requesting a new set of
   resources.

Top      Up      ToC       Page 38 
   When used with HTTP, the <session-info> element MUST be included in
   an HTTP POST message (as defined in [RFC2616]).  When used with SIP,
   the <session-info> element MUST instead be included in either a SIP
   INVITE or a SIP re-INVITE (as defined in [RFC3261]), or in a SIP
   UPDATE (as defined in [RFC3311]) request: in fact, any SIP dialog, be
   it a new or an existing one, can be exploited to carry leasing
   information, and as such new SIP INVITE messages can update other
   leases as well as request a new one.

   With IAMM, the Application Server or Media Server will eventually
   send a SIP BYE to end the SIP session, whether it was for a Control
   Channel or a media dialog.  That BYE contains no Consumer interface
   lease information.

5.2.4.  <mrbconsumer>

   This section defines the XML elements for the Consumer interface.
   The formal XML schema definition for the Consumer interface can be
   found in Section 11.

   The root element is <mrbconsumer>.  All other XML elements (requests,
   responses) are contained within it.  The MRB Consumer interface
   request element is detailed in Section 5.2.5.1.  The MRB Consumer
   interface response element is detailed in Section 5.2.6.1.

   The <mrbconsumer> element has the following attributes:

   version:  a token specifying the mrb-consumer package version.  The
      value is fixed as '1.0' for this version of the package.  The
      attribute MUST be present.

   The <mrbconsumer> element may have zero or more children of one of
   the following child element types:

      <mediaResourceRequest> for sending a Consumer request.  See
      Section 5.2.5.1.

      <mediaResourceResponse> for sending a Consumer response.  See
      Section 5.2.6.1.


Next RFC Part