Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6917

Media Resource Brokering

Pages: 136
Proposed Standard
Part 3 of 6 – Pages 39 to 57
First   Prev   Next

Top   ToC   RFC6917 - Page 39   prevText

5.2.5. Media Service Resource Request

This section provides the element definitions for use in Consumer interface requests. The requests are carried in the <mediaResourceRequest> element.
5.2.5.1. <mediaResourceRequest>
The <mediaResourceRequest> element provides information for clients wishing to query an external MRB entity. The <mediaResourceRequest> element has a single mandatory attribute, 'id': this attribute contains a random identifier, generated by the client, that will be included in the response in order to map it to a specific request. The <mediaResourceRequest> element has <generalInfo>, <ivrInfo>, and <mixerInfo> as child elements. These three elements are used to describe the requirements of a client requesting a Media Server and are covered in Sections 5.2.5.1.1, 5.2.5.1.2, and 5.2.5.1.3, respectively.
5.2.5.1.1. <generalInfo>
The <generalInfo> element provides general Consumer request information that is neither IVR specific nor mixer specific. This includes session information that can be used for subsequent requests as part of the leasing mechanism described in Section 5.2.3. The following sub-sections describe the <session-info> and <packages> elements, as used by the <generalInfo> element. 5.2.5.1.1.1. <session-info> The <session-info> element is included in Consumer requests when an update is being made to an existing media resource session. The ability to change and remove an existing media resource session is described in more detail in Section 5.2.3. The element MAY be present. The <session-info> element has no attributes. The <session-info> element has zero or more of the following child elements: <session-id>: A unique identifier that explicitly references an existing media resource session on the MRB. The identifier is included to update the existing session and is described in more detail in Section 5.2.3.
Top   ToC   RFC6917 - Page 40
   <seq>:  Used in association with the <session-id> element in a
      subsequent request to update an existing media resource session on
      an MRB.  The <seq> number is incremented from its original value
      returned in response to the initial request for media resources.
      Its value is a non-negative integer that MUST be limited within
      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.  More information about its use is provided in
      Section 5.2.3.

   <action>:  Provides the operation that should be carried out on an
      existing media resource session on an MRB:

      *  The value of 'update' instructs the MRB to attempt to update
         the existing media resource session with the information
         contained in the <ivrInfo> and <mixerInfo> elements.

      *  The value of 'remove' instructs the MRB to attempt to remove
         the existing media resource session.  More information on its
         use is provided in Section 5.2.3.

5.2.5.1.1.2.  <packages>

   The <packages> element provides a list of Media Control Channel
   Framework compliant packages that are required by the Consumer
   client.  The element MAY be present.

   The <packages> element has no attributes.

   The <packages> element has a single child element:

   <package>:  Contains a string representing the Media Control Channel
      Framework package required by the Consumer client.  The <package>
      element can appear multiple times.  A valid value is a Control
      Package name compliant with Section 13.1.1 of [RFC6230].

5.2.5.1.2. <ivrInfo>
The <ivrInfo> element provides information for general Consumer request information that is IVR specific. The following sub-sections describe the elements of the <ivrInfo> element: <ivr-sessions>, <file-formats>, <dtmf>, <tones>, <asr-tts>, <vxml>, <location>, <encryption>, <application-data>, <max-prepared-duration>, and <file-transfer-modes>.
Top   ToC   RFC6917 - Page 41
5.2.5.1.2.1.  <ivr-sessions>

   The <ivr-sessions> element indicates the number of IVR sessions that
   a Consumer client requires from a media resource.  The element MAY be
   present.

   The <ivr-sessions> element has no attributes.

   The <ivr-sessions> element has a single child element:

   <rtp-codec>:  Describes a required codec and the number of 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> contains the number of RTP
      sessions required for decoding using the specified codec, and the
      child element <encoding> contains the number of RTP sessions
      required for encoding using the specified codec.

5.2.5.1.2.2.  <file-formats>

   The <file-formats> element provides a list of file formats required
   for the purpose of playing media.  It should be noted that this
   element describes media types and might better have been named
   "media-formats", but due to existing implementations the name
   "file-formats" is being used.  The element MAY be present.

   The <file-formats> element has no attributes.

   The <file-formats> element has a single child element:

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

   The <dtmf> element specifies the required methods to detect DTMF
   tones and to generate them.  The element MAY be present.

   The <dtmf> element has no attributes.

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

   <detect>:  Indicates the required support for DTMF detection.  The
      <detect> element has no attributes.  The <detect> element 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 required and is 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 required support for DTMF generation.  The
      <generate> element has no attributes.  The <generate> element has
      a single child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes: 'name' and 'package'.  The 'name' attribute
      provides the type of DTMF required and is 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 required 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 required and is 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   ToC   RFC6917 - Page 43
5.2.5.1.2.4.  <tones>

   The <tones> element provides requested tones that a Media Server must
   support for IVR.  In particular, the request refers to both support
   for country codes (ISO 3166-1 [ISO.3166-1]) and requested
   functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).  The
   element MAY be present.

   The <tones> element has no attributes.

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

   <country-codes>:  Describes the requested country codes in relation
      to tones.  The <country-codes> element has no attributes.  The
      <country-codes> element has one child element.  The child element,
      <country-code>, requests 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 requested.

   <h248-codes>:  Describes the requested H.248 codes in relation to
      tones.  The <h248-codes> element has no attributes.  The
      <h248-codes> element has one child element.  The child element,
      <h248-code>, requests 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 requested.

5.2.5.1.2.5.  <asr-tts>

   The <asr-tts> element requests information about the support for
   Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
   functionality in a Media Server.  The functionality is requested by
   referring to the supported languages (using ISO 639-1 [ISO.639.2002]
   codes) in relation to both ASR and TTS.  The <asr-tts> element has no
   attributes.  The <asr-tts> 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>,
Top   ToC   RFC6917 - Page 44
      requests 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.

   <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>,
      requests 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.2.5.1.2.6.  <vxml>

   The <vxml> element specifies if the Consumer client requires VoiceXML
   and, if so, which protocols are supported (e.g., via the control
   framework, RFC 4240 [RFC4240], or RFC 5552 [RFC5552]).  The element
   MAY be present.

   The <vxml> element has a single child element:

   <vxml-mode>:  Has two attributes: 'package' and 'require'.  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 'require' attribute specifies
      the type of VXML support required by the Consumer client (e.g.,
      RFC 5552 [RFC5552], RFC 4240 [RFC4240], or IVR Package [RFC6231]),
      and valid values are case-insensitive RFC references (e.g.,
      "rfc6231" to specify that the client requests support for VoiceXML
      as provided by the IVR Package [RFC6231]).

   The presence of at least one <vxml> child element would indicate that
   the Consumer client requires VXML support as specified by the child
   element itself.  An empty <vxml> element would otherwise indicate
   that the Consumer client does not require VXML support.

5.2.5.1.2.7.  <location>

   The <location> element requests a civic location for an IVR Media
   Server.  The request 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 is
   implementation specific in its level of population.

   The <location> element has no attributes.
Top   ToC   RFC6917 - Page 45
   The <location> element has a single child element:

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

5.2.5.1.2.8.  <encryption>

   The <encryption> element allows a Consumer client to request 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 [RFC5763].

   The <encryption> element has no attributes.

   The <encryption> element has no child elements.

5.2.5.1.2.9.  <application-data>

   The <application-data> element provides an arbitrary string of
   characters as IVR 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.

5.2.5.1.2.10.  <max-prepared-duration>

   The <max-prepared-duration> element indicates the amount of time
   required by the Consumer client representing media dialog preparation
   in the system before it is executed.  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
Top   ToC   RFC6917 - Page 46
      provides the name of the Media Control Channel Framework package,
      compliant with Section 13.1.1 of [RFC6230], for which the time
      period applies.

5.2.5.1.2.11.  <file-transfer-modes>

   The <file-transfer-modes> element allows the Consumer client to
   specify which scheme names are required for file transfer to a Media
   Server for each Media Control Channel Framework package type.  For
   example, does the Media Server support fetching media resources via
   HTTP, HTTPS, NFS, etc.?  The element MAY be present.

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

   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 required
      for fetching resources: valid values are case-insensitive scheme
      names (e.g., HTTP, HTTPS, NFS, etc.).  The 'package' attribute
      provides the name of the Media Control Channel Framework package,
      compliant with Section 13.1.1 of [RFC6230], for which the scheme
      name applies.

   The same considerations relating to file transfer and live streaming
   are explained further in Section 5.1.5.15 and apply here as well.

5.2.5.1.3. <mixerInfo>
The <mixerInfo> element provides information for general Consumer request information that is mixer specific. The following sub-sections describe the elements of the <mixerInfo> element: <mixers>, <file-formats>, <dtmf>, <tones>, <mixing-modes>, <application-data>, <location>, and <encryption>. 5.2.5.1.3.1. <mixers> The <mixers> element provides information detailing the required mixed RTP sessions. The element MAY be present. The <mixers> element has no attributes. The <mixers> element has a single child element: <mix>: Describes the required mixed RTP sessions. The <mix> element has one attribute. The value of the attribute, 'users', is the number of participants required in the mix. The <mix> element has
Top   ToC   RFC6917 - Page 47
      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.2.5.1.3.2.  <file-formats>

   The <file-formats> element provides a list of file formats required
   by the Consumer client for the purpose of playing media to a mix.
   The element MAY be present.

   The <file-formats> element has no attributes.

   The <file-formats> element has a single child element:

   <required-format>:  Has a single attribute, 'name', which provides
      the type of file format supported.  A valid value is a media type
      that, depending on its definition, can include additional
      parameters (e.g., [RFC6381]).  The <required-format> element has a
      child element, <required-file-package>.  The
      <required-file-package> element contains a single attribute,
      'required-file-package-name', which contains 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.2.5.1.3.3.  <dtmf>

   The <dtmf> element specifies the required methods to detect DTMF
   tones and to generate them in a mix.  The element MAY be present.

   The <dtmf> element has no attributes.

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

   <detect>:  Indicates the required 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 is 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 required support for DTMF generation.  The
      <generate> element has no attributes.  The <generate> element has
      a single child element, <dtmf-type>.  The <dtmf-type> element has
      two attributes: 'name' and 'package'.  The 'name' attribute
Top   ToC   RFC6917 - Page 48
      provides the type of DTMF being used and is 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 required support for passing DTMF
      through without re-encoding.  The <passthrough> element has no
      attributes.  The <passthrough> element has a single 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 is 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.

5.2.5.1.3.4.  <tones>

   The <tones> element provides requested tones that a Media Server must
   support for a mix.  In particular, the request refers to both support
   for country codes (ISO 3166-1 [ISO.3166-1]) and requested
   functionality (ITU-T Recommendation Q.1950 [ITU-T.Q.1950]).  The
   element MAY be present.

   The <tones> element has no attributes.

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

   <country-codes>:  Describes the requested country codes in relation
      to tones.  The <country-codes> element has no attributes.  The
      <country-codes> element has a single child element.  The child
      element, <country-code>, requests 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 the specification in the related
      IANA registry (e.g., "msc-ivr/1.0"), in which the tones from the
      specified country code are requested.

   <h248-codes>:  Describes the requested H.248 codes with respect to
      tones.  The <h248-codes> element has no attributes.  The
      <h248-codes> element has a single child element.  The child
      element, <h248-code>, requests 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.,
Top   ToC   RFC6917 - Page 49
      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
      requested.

5.2.5.1.3.5.  <mixing-modes>

   The <mixing-modes> element requests information relating to support
   for audio and video mixing, more 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 requested 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 requested mixing
      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 is requested.

   <video-mixing-modes>:  Describes the requested video presentation
      layouts for 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
      Consumer client requires automatic Voice Activated Switching.  The
      'activespeakermix' attribute is of type boolean with a value of
      'true' indicating that the Consumer client requires 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, or to non-XCON layouts as well,
      as long as they are appropriately prefixed.  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 is requested.
Top   ToC   RFC6917 - Page 50
5.2.5.1.3.6.  <application-data>

   The <application-data> element provides an arbitrary string of
   characters as mixer 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.

5.2.5.1.3.7.  <location>

   The <location> element requests a civic location for a mixer Media
   Server.  The request 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 <location> element has no attributes.

   The <location> element has a single child element:

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

5.2.5.1.3.8.  <encryption>

   The <encryption> element allows a Consumer client to request support
   for encrypting mixed RTP media streams using RFC 3711 [RFC3711].  The
   element MAY be present.  If the element is present, then the Media
   Server supports DTLS-SRTP [RFC5763].

   The <encryption> element has no attributes.

   The <encryption> element has no child elements.
Top   ToC   RFC6917 - Page 51

5.2.6. Media Service Resource Response

This section provides the element definitions for use in Consumer interface responses. The responses are carried in the <mediaResourceResponse> element.
5.2.6.1. <mediaResourceResponse>
The <mediaResourceResponse> element provides information for clients receiving response information from an external MRB entity. The <mediaResourceResponse> element has two mandatory attributes: 'id' and 'status'. The 'id' attribute must contain the same value that the client provided in the 'id' attribute in the <mediaResourceRequest> to which the response is mapped. The 'status' attribute indicates the status code of the operation. The following status codes are defined for 'status': +-----------+-------------------------------------------------------+ | code | description | +-----------+-------------------------------------------------------+ | 200 | OK | | | | | 400 | Syntax error | | | | | 405 | Wrong sequence number | | | | | 408 | Unable to find Resource | | | | | 409 | Unable to update Resource | | | | | 410 | Unable to remove Resource | | | | | 420 | Unsupported attribute or element | +-----------+-------------------------------------------------------+ Table 2: <mediaResourceResponse> Status Codes If a new media resource request made by a client application has been accepted, the MRB MUST reply with a <mediaResourceResponse> 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 MRB. A media resource request, nevertheless, may fail for several reasons. In such a case, the status codes defined in Table 2 must be used instead. Specifically, if the MRB fails to handle a request due to a syntax error in the request itself (e.g., incorrect XML, violation of
Top   ToC   RFC6917 - Page 52
   the schema constraints, or invalid values in any of the attributes/
   elements), the MRB MUST reply with a <mediaResourceResponse> with
   status code 400.  If a syntactically correct request fails because
   the request also includes any attribute/element the MRB doesn't
   understand, the MRB MUST reply with a <mediaResourceResponse> with
   status code 420.  If a syntactically correct request fails because it
   contains a wrong sequence number, that is, a 'seq' value not
   consistent with the increment the MRB expects according to
   Section 5.2.3, the MRB MUST reply with a <mediaResourceResponse> with
   status code 405.  If a syntactically correct request fails because
   the MRB couldn't find any Media Server able to fulfill the
   requirements presented by the Application Server in its request, the
   MRB MUST reply with a <mediaResourceResponse> with status code 408.
   If a syntactically correct request fails because the MRB couldn't
   update an existing request according to the new requirements
   presented by the Application Server in its request, the MRB MUST
   reply with a <mediaResourceResponse> with status code 409.  If a
   syntactically correct request fails because the MRB couldn't remove
   an existing request and release the related resources as requested by
   the Application Server, the MRB MUST reply with a
   <mediaResourceResponse> with status code 410.

   Further details on status codes 409 and 410 are included in
   Section 5.2.3, where the leasing mechanism, along with its related
   scenarios, is described in more detail.

   The <mediaResourceResponse> element has <response-session-info> as a
   child element.  This element is used to describe the response of a
   Consumer interface query and is covered in the following sub-section.

5.2.6.1.1. <response-session-info>
The <response-session-info> element is included in Consumer responses. This applies to responses to both requests for new resources and requests to update an existing media resource session. The ability to change and remove an existing media resource session is described in more detail in Section 5.2.3. If the request was successful, the <mediaResourceResponse> MUST have one <response-session-info> child, which describes the media resource session addressed by the request. If the request was not successful, the <mediaResourceResponse> MUST NOT have a <response-session-info> child. The <response-session-info> element has no attributes.
Top   ToC   RFC6917 - Page 53
   The <response-session-info> element has zero or more of the following
   child elements:

   <session-id>:  A unique identifier that explicitly references an
      existing media resource session on the MRB.  The identifier is
      included to update the existing session and is described in more
      detail in Section 5.2.3.

   <seq>:  Used in association with the <session-id> element in a
      subsequent request to update an existing media resource session on
      an MRB.  The <seq> number is incremented from its original value
      returned in response to the initial request for media resources.
      More information on its use is provided in Section 5.2.3.

   <expires>:  Includes the number of seconds that the media resources
      are reserved as part of this interaction.  If the lease is not
      refreshed before expiry, the MRB will reclaim the resources and
      they will no longer be guaranteed.  It is RECOMMENDED that a
      minimum value of 300 seconds be used for the value of the
      'expires' attribute.  It is also RECOMMENDED that a Consumer
      client refresh the lease at an interval that is not too close to
      the expiry time.  A value of 80% of the timeout period could be
      used.  For example, if the timeout period is 300 seconds, the
      Consumer client would refresh the transaction at 240 seconds.
      More information on its use is provided in Section 5.2.3.

   <media-server-address>:  Provides information to reach the Media
      Server handling the requested media resource.  One or more
      instances of these elements may appear.  The
      <media-server-address> element has a single attribute named 'uri',
      which supplies a SIP URI that reaches the specified Media Server.
      It also has three optional elements: <connection-id>,
      <ivr-sessions>, and <mixers>.  The <ivr-sessions> and <mixers>
      elements are defined in Sections 5.2.5.1.2.1 and 5.2.5.1.3.1,
      respectively, and have the same meaning but are applied to
      individual Media Server instances as a subset of the overall
      resources reported in the <connection-id> element.  If multiple
      Media Servers are assigned in an IAMM operation, exactly one
      <media-server-address> element, more specifically the Media Server
      that provided the media dialog or CFW response, will have a
      <connection-id> element.  Additional information relating to the
      use of the <connection-id> element for media dialogs is included
      in Section 6.
Top   ToC   RFC6917 - Page 54

5.3. In-Line Unaware MRB Interface

An entity acting as an In-line MRB can act in one of two roles for a request, as introduced in Section 4.2: the In-line Unaware MRB Mode (IUMM) of operation and the In-line Aware MRB Mode (IAMM) of operation. This section further describes IUMM. 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 the Consumer interface as discussed in Sections 5.2.1 (Query mode) and 5.2.2 (IAMM). An MRB entity can also act in a client-unaware mode when 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 that in turn will select an appropriate Media Server based on knowledge of Media Server resources it currently has available transparently to the client entity. 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. With IUMM, the MRB may conclude that an assigned media resource is no longer needed when it receives a SIP BYE from the Application Server or Media Server that ends the SIP dialog that initiated the request. As with IAMM, in IUMM the SIP INVITE from the Application Server could convey the application/sdp payload to either set up a media dialog or a Control Framework Control Channel. In either case, in order to permit the Application Server to associate a media dialog with a Control Channel to the same Media Server, using the procedures of [RFC6230] Section 6, the MRB should be acting as a SIP proxy (and not a B2BUA). This allows the SIP URI of the targeted Media Server to be transparently passed back to the Application Server in the SIP response, resulting in a direct SIP dialog between the Application Server and the Media Server. While IUMM has the least impact on legacy Application Servers, it also provides the least versatility. See Section 8.

6. MRB Acting as a B2BUA

An MRB entity can act as a SIP Back-to-Back User Agent (B2BUA) or a SIP Proxy Server as defined in RFC 3261 [RFC3261]. When an MRB acts as a B2BUA, issues can arise when using Media Control Channel packages such as the IVR [RFC6231] and mixer [RFC6505] packages. Specifically, the framework attribute 'connectionid' as provided in
Top   ToC   RFC6917 - Page 55
   Appendix A ("Common Package Components") of [RFC6230] uses a
   concatenation of the SIP dialog identifiers to be used for
   referencing SIP dialogs within the Media Control Channel.  When a
   request traverses an MRB acting as a B2BUA, the SIP dialog
   identifiers change, and so the 'connectionid' cannot be used as
   intended due to this change.  For this reason, when an MRB wishes to
   act as a SIP B2BUA when handling a request from an Application Server
   to set up a media dialog to a Media Server, it MUST include the
   optional <connection-id> element in a Consumer interface response
   with a value that provides the equivalent for the 'connectionid'
   ('Local Dialog Tag' + 'Remote Dialog Tag') for the far side of the
   B2BUA.  If present, this value MUST be used as the value for the
   'connectionid' in packages where the Common Package Components are
   used.  The <connection-id> element MUST NOT be included in an HTTP
   Consumer interface response.

   It is important to point out that although more Media Server
   instances may be returned in a Consumer response (i.e., the MRB has
   assigned more than one Media Server to a Consumer request to fulfill
   the Application Server requirements), in IAMM the MRB will only act
   as a B2BUA with a single Media Server.  In this case, exactly one
   <media-server-address> element, describing the media dialog or CFW
   response, will have a <connection-id> element that will not be
   included in any additional <media-server-address> elements.

7. Multimodal MRB Implementations

An MRB implementation may operate multimodally with a collection of Application Server clients all sharing the same pool of media resources. That is, an MRB may be simultaneously operating in Query mode, IAMM, and IUMM. It knows in which mode to act on any particular request from a client, depending on the context of the request: o If the received request is an HTTP POST message with application/ mrb-consumer+xml content, then the MRB processes it in Query mode. o If the received request is a SIP INVITE with application/ mrb-consumer+xml content and application/sdp content, then the MRB processes it in IAMM. o If the received request is a SIP INVITE without application/ mrb-consumer+xml content but with application/sdp content, then the MRB processes it in IUMM.
Top   ToC   RFC6917 - Page 56

8. Relative Merits of Query Mode, IAMM, and IUMM

At a high level, the possible Application Server MRB interactions can be distinguished by the following basic types: a. Query mode - the client is requesting the assignment by the MRB of suitable Media Server resources; b. IAMM/media dialog - the client is requesting the assignment by the MRB of suitable Media Server resources and the establishment of a media dialog to one of the Media Servers; c. IAMM/Control Channel - the client is requesting the assignment by the MRB of suitable Media Server resources and the establishment of a CFW Control Channel to one of the Media Servers; d. IUMM/media dialog - the client is requesting the establishment of a media dialog to a Media Server resource; e. IUMM/Control Channel - the client is requesting the establishment of a CFW Control Channel to a Media Server resource. Each type of interaction has advantages and disadvantages, where such considerations relate to the versatility of what the MRB can provide, technical aspects such as efficiency in different application scenarios, complexity, delay, use with legacy Application Servers, or use with the Media Control Channel Framework. Depending on the characteristics of a particular setting that an MRB is intended to support, some of the above interaction types may be more appropriate than others. This section provides a few observations on relative merits but is not intended to be exhaustive. Some constraints of a given interaction type may be subtle. o Operation with other types of media control: Any of the types of interactions work with the mechanisms described in RFC 4240 [RFC4240] and RFC 5552 [RFC5552] where initial control instructions are conveyed in the SIP INVITE from the Application Server for the media dialog to the Media Server and subsequent instructions may be fetched using HTTP. Query mode (a), IAMM/ media dialog (b), and IUMM/media dialog (d) work with the Media Server Markup Language (MSML) as per RFC 5707 [RFC5707] or the Media Server Control Markup Language (MSCML) as per RFC 5022 [RFC5022]. o As stated previously, IUMM has no interface impacts on an Application Server. When using IUMM, the Application Server does not specify the characteristics of the type of media resource it requires, as the <mediaResourceRequest> element is not passed to
Top   ToC   RFC6917 - Page 57
      the MRB.  For IUMM/media dialog (d), the MRB can deduce an
      appropriate media resource on a best-effort basis using
      information gleaned from examining information in the SIP INVITE.
      This includes the SDP information for the media dialog, or initial
      control information in the SIP Request-URI as per RFC 4240
      [RFC4240].  With IUMM/Control Channel (e), there is even less
      information for the MRB to use.

   o  If using IUMM/Control Channel (e), the subsequent sending of the
      media dialog to the Media Server should not be done using IUMM/
      media dialog.  That is, the SIP signaling to send the media dialog
      to the selected Media Server must be directly between the
      Application Server and that Media Server, and not through the MRB.
      Unless resources can be confidentially identified, the MRB could
      send the media dialog to a different Media Server.  Likewise, if
      using IUMM/media dialog (d), the subsequent establishment of a
      Control Channel should not be done with IUMM/Control Channel (e)
      unless definitive information is available.

   o  Query mode (a) and IAMM/Control Channel (c) lend themselves to
      requesting a pool of media resources (e.g., a number of IVR or
      conferencing ports) in advance of use and retaining use over a
      period of time, independent of whether there are media dialogs to
      those resources at any given moment, whereas the other types of
      interactions do not.  This also applies to making a subsequent
      request to increase or decrease the amount of resources previously
      awarded.

   o  While Query mode (a) and IAMM/Control Channel (c) are the most
      versatile interaction types, the former is completely decoupled
      from the use or non-use of a Control Channel, whereas the latter
      requires the use of a Control Channel.

   o  When Media Control Channel Framework Control Channels are to be
      used in conjunction with the use of an MRB, Query mode (a) would
      typically result in fewer such channels being established over
      time, as compared to IAMM/Control Channel (c).  That is because
      the latter would involve setting up an additional Control Channel
      every time an Application Server has a new request for an MRB for
      media resources.


(next page on part 4)

Next Section