RFC 6917
Media Resource Brokering
Pages: 136
Proposed Standard
Proposed Standard
Part 3 of 6 – Pages 39 to 57
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.
<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>.
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.
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.
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>,
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.
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
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
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
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.,
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.
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.
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
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.
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.
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
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.
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
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)