Media Resource
BrokeringNS-Technologieschris@ns-technologies.comMeetechoVia Carlo Poerio 8980100NapoliItalylorenzo@meetecho.comAT&T200 Laurel Avenue SouthMiddletown07748New JerseyUSAgamunson@att.comThe MediaCtrl work group in the IETF has proposed an architecture
for controlling media services. The Session Initiation Protocol (SIP) is used as
the signalling protocol which provides many inherent capabilities for
message routing. In addition to such signalling properties, a need
exists for intelligent, application level media service selection based
on non-static signalling properties. This is especially true when considered in
conjunction with deployment architectures that include 1:M and M:N combinations
of Application Servers and Media Servers. This document introduces a Media
Resource Broker (MRB) entity which manages the availability of Media Servers and the
media resource demands of Application Servers. The document includes potential deployment
options for an MRB and appropriate interfaces to Application Servers and Media Servers.
The topic of Media Resource management has been in discussion for a number of years with
varying proprietary solutions being used today. It is clear that, as we move towards
a consistent architecture and protocol for Media Server Control, a standard mechanism
is required for accurate media resource selection.As IP based multimedia infrastructures mature, the complexity and demands from
deployments increase. Such complexity will result in a wide variety of capabilities
from a range of vendors that should all be interoperable using the architecture
and protocols produced by the MediaCtrl work group. It should be possible
for a controlling entity to be assisted in Media Server selection so that
the most appropriate resource is selected for a particular operation. The
importance increases when you introduce a flexible level of deployment scenarios,
as specified in the RFC 5167 and RFC 5567 documents.
These documents make statements like
"it should be possible to have a many-to-many relationship between Application
Servers and Media Servers that use this protocol". This leads to the following
deployment architectures being possible when considering media resources, to provide
what can be effectively described as Media Resource Brokering.
The simplest deployment view is illustrated in .
This simply involves a single Application Server and Media Server. Expanding
on this view, it is also possible for an Application Server to control
multiple (greater that 1) Media Server instances at any one time. This deployment view is illustrated in
. Typically, such architectures are associated with
application logic that requires high demand media services. It is more than possible
that each media server possesses a different media capability set. Media servers
may offer different media services as specified in the Mediactrl architecture document.
A Media server may have similar media functionality but may have different capacity
or media codec support. conveys the opposite view to that in .
In this model there are a number of (greater than 1) application servers, possibly supporting
dissimilar applications, controlling a single media server. Typically, such architectures are
associated with application logic that requires low demand media services.
The final deployment view is the most complex. In this model (M:N) there
exists any number of Application Servers and any number of Media Servers. It is
again possible in this model that media servers might not be homogeneous and have
different capability sets and capacity.The remaining sections in this specification will focus on a new entity called
a Media Resource Broker (MRB) which can be utilised in the deployment architectures
described previously in this section. The MRB entity provides the ability to obtain
media resource information and appropriately allocate(broker) on behalf of client
applications.The high level deployment options discussed in this section rely
on network architecture and policy to prohibit inappropriate use. Such
policies are out of the scope of this document.This document will take a look at the specific problem areas related
to such deployment architectures. It is recognised that the solutions
proposed in this document should be equally adaptable to all of the
previously described deployment models. It is also recognised that
the solution is far more relevant to some of the previously discussed
deployment models and can almost be viewed as redundant
on others.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.This document inherits terminology proposed in
RFC 5567 and
Media Control Channel Framework documents.
In addition, the following terms are defined for use in this document and for
use in the context of the MediaCtrl Work group in the IETF:
A logical entity that is responsible for
both collection of appropriate published Media Server (MS)
information and selecting appropriate MS resources on behalf of
consuming entities.An instantiation of an MRB (See previous definition) that provides
an interface for an Application Server to retrieve the address of an appropriate Media Server. The result
returned to the Application Server can be influenced by information contained in the query
request.An instantiation of an MRB (See definition) that
directly receives requests on the signalling path. There is no
separate query.Media Control Channel Framework, as specified in .
Within the context of In-line MRBs, additional terms are defined:
Defined in .Defined in .
The document will often specify when a specific identifier in a protocol message
needs to be unique. Unless differently stated, such uniqueness will always need to
be intended within the scope of the Media Servers controlled by the same Media
Resource Broker. The interaction among different Media Resource Brokers, as the
partitioning of a logical Media Resource Broker, is out of scope to this document.
As anticipated in , the main aim of the MediaCtrl group
is to produce a solution that must service a wide variety of deployment architectures.
These range from the simplest 1:1 relationship between Media Servers and Application
Servers to potentially linearly scaling 1:M, M:1 and M:N deployments.This still does not seem like a major issue for the proposed solution until
you add a number of additional factors into the equation that increase
complexity. As Media Servers evolve it must be taken into consideration that,
where many can exist in a deployment, they may not have been produced by the same
vendor and may not have the same capability set. It should be possible for an
Application Server that exists in a deployment to select a Media Service based
on a common, appropriate capability set. In conjunction with capabilities, it is
also important to take available resources into consideration. The ability
to select an appropriate Media Service function is an extremely useful
feature but becomes even more powerful when considered with
available resources for servicing a request.In conclusion, the intention is to create a tool set that allows MediaCtrl
deployments to effectively utilize the available media resources. It should
be noted that in the simplest deployments where only a single media server exists,
an MRB function is probably not required. Only a single capability set exists
and resource unavailability can be handled using the appropriate underlying
signalling, e.g., SIP response. This document does not prohibit such uses of
an MRB, it simply provides the tools for various entities to interact
where appropriate. It is also worth noting that the tools provided
in this document aim to provide a 'best effort' view of media resources
at the time of request for initial Media Server routing decisions. Any
dramatic change in media capabilities after a request has taken place
should be handled by the underlying protocol.Please note that there may be additional information that it is
desirable for the MRB to have for purposes of selecting a MS resource, such as
resource allocation rules across different applications, planned or unplanned
downtime of Media Server resources, the planned addition of future Media Server
resources, or MS resource capacity models. How the MRB acquires such information
is outside the scope of this document. The techniques used for selecting an
appropriate Media Resource by an MRB is outside the scope of this document.On researching Media Resource Brokering it became clear that a couple of high level
models exist. The general principles of "in-line" and "query"
MRB concepts are discussed in the rest of this section.
The "Query" model for MRB interactions provides the ability for
a client of media services (for example an Application Server) to
"ask" an MRB for an appropriate Media Server, as illustrated
in .
In this deployment, the Media Servers use the "Media Server Resource
Publish Interface", as discussed in , to
convey capability sets as well as resource information. This is depicted
by (1) in . It is then the MRB's responsibility to
accumulate all appropriate information relating to media services in the
logical deployment cluster. The Application Server (or other media
services client) is then able to query the MRB for an appropriate resource (as
identified by (2) in ). Such a query would carry
specific information related to the Media Service required and enable the MRB
to provide an increased accuracy in its response. This particular interface
is discussed in "Media Resource Consumer Interface" in
. The Application Server is then able
to direct control commands (for example create conference) and Media Dialogs
to the appropriate Media Server, as shown by (3) in .
Additionally, with Query MRB, the MRB is not in the signaling path
between the AS and the selected MS resource.As mentioned previously, it is the intention that a tool kit is provided
for MRB functionality within a MediaCtrl architecture. It is expected that in
specific deployment scenarios the role of the MRB might be co-hosted as a hybrid
logical entity with an Application Server, as shown in .
This diagram is identical to that in with the exception
that the MRB is now hosted on the Application Server. The "Media Server
Publish Interface" is still being used to accumulate resource information
at the MRB but as it is co-hosted on the Application Server, the "Media
Server Consumer Interface" has collapsed. It might still exist within the
Application Server/MRB interaction but this is an implementation issue. This
type of deployment suits a single Application Server environment but it should be noted
that a "Media Server Consumer Interface" could then be offered from the
hybrid if required.
In a similar manner, the Media Server could also act as a hybrid for the deployment
cluster, as illustrated in .
This time the MRB has collapsed and is co-hosted by the Media Server. The
"Media Server Consumer Interface" is still available to the Application
Servers (1) to query Media Server resources. This time the "Media
Server Publish Interface" has collapsed onto the Media Server. It might
still exist within the Media Server/MRB interaction but this is an implementation
issue. This type of deployment suits a single Media Server environment but
it should be noted that a "Media Server Publish Interface" could then
be offered from the hybrid if required. A typical use case scenario for such a
topology would be a single MS representing a pool of MSs in a cluster. In that case,
the MRB would actually be handling a cluster of MSs, rather than one.
The "In-line" MRB is architecturally different from the "Query" model
that was discussed in the previous section. The concept of a separate
query disappears. The client of the MRB simply uses the media resource
control and media dialog signalling to involve the MRB. This type of deployment is illustrated
in .The Media Servers still use the 'Media Server Publish Interface' to convey
capabilities and resources to the MRB - as illustrated by (1). The media server
Control (and Media dialogs as well, if required) is sent to the MRB (2) which then selects an
appropriate Media Server (3) and would stay in the signaling path between the AS
and the MS resource for the handled dialogs.In-line MRB can be split into two distinct logical roles which can be applied on a per
request basis. They are:
Allows an MRB to act on behalf of clients requiring
media services who are not aware of an MRB or its operation. In this case the AS does not
provide explicit information on the kind of MS resource it needs
(as in ) and the
MRB is left to deduce it by potentially inspecting other information in the request from
the AS; for example, SDP content, or address of the requesting AS, or additional Request-URI
parameters as per RFC 4240.Allows an MRB to act on behalf of clients requiring
media services who are aware of an MRB and its operation. In particular it allows the AS
to explicitly the convey the same kinds of MS characteristics desired as does the Query MRB
mode (as in ).
In either role, signalling as specified by the Media Control Channel
Framework () would be involved, and the MRB would deduce
that the selected MS resources are no longer needed when the AS
or MS terminates the corresponding dialog. The two modes are discussed in more detail
in .As discussed in previous sections in this document, the intention is to
provide a tool-kit for a variety of deployment architectures where media resource
brokering can take place. As a result, 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. These two
interfaces have extremely differing responsibilities and usages which is
reflected in the choice of solutions.
It is beyond the scope of this document to define exactly how to
construct an MRB. This includes interpreting the data for the Media Service
Consumer interface supplied by the Media Server Publish interface. It
is, however, important that the two interfaces are complimentary so that
development of appropriate MRB functionality is supported.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 fulfil 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 Query and In-line modes of
MRB operation.
As already anticipated in the introduction, the MRB view
of MS resource availability will in practice be approximate - i.e.,
partial and imperfect. The MRB Publish interface does not provide an exhaustive
view of current MS resource consumption, the MS may in some cases
provide a best-effort computed view of resource consumption
parameters conveyed in the Publish interface (e.g., DSP's with a
fixed number of streams versus GPU's with CPU availability), there may be
licensing constraints not factored in (e.g., even if lots of CPU and memory
are available, licensing or other configuration elements may restrict
the number of stream types), and MS resource information may only be
reported periodically over the Publish interface to MRB. Nevertheless,
despite such limitations it is assumed that the provided information
is enough to allow MRB implementers to realize its functionality.It is also worth noting that, while the scope of the MRB is definitely on providing interested Application Servers with
the available resources, the MRB also allows for the retrieval of information about the currently
occupied resources. While this is of course a relevant piece of information (e.g., for monitoring
purposes), such a functionality inevitably raises security considerations, and implementations
should take this into account. See for more details.The MRB Publish interface uses the Media Control Channel
Framework () 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 which are known as control packages.
defines the control package that MUST be implemented by any Media Server wanting to interact
with an MRB entity.Please note that it is out of scope how an MRB knows what MSs should be queried
for publishing information.This section fulfils the mandatory requirement for information that
must be specified during the definition of a Control Framework Package,
as detailed in Section 8 of .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". The MRB publish interface allows a media server to convey available capabilities
and resources to an MRB entity.This package defines XML elements in and provides an XML
Schema in . The XML elements in this package are split into requests, responses
and event notifications.
Requests are carried in CONTROL message bodies; <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 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
) 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 . The Media Control Channel Framework
requires a Control Package definition to
specify if the attributes for media dialog or conference references are required.The Publish interface defined in does import and make use of the
common XML schema defined in the Media Control Channel Framework.The Consumer interface defined in does import and make use of the
common XML schema defined in the Media Control Channel Framework.A valid CONTROL body message MUST conform to the schema defined in and described in
. XML messages appearing in CONTROL messages
MUST contain either a <mrbrequest> or <mrbnotification> element. A valid REPORT body MUST conform to the schema defined in
and described in . XML
messages appearing in REPORT messages MUST contain a <mrbresponse> element.
The 'mrb-publish/1.0' Media Control Channel Framework package does not require any
additional auditing capability.This section defines the XML elements for the Publish interface Media Control Channel package
defined in . The formal XML schema definition for the Publish
interface can be found in .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 .
The MRB Publish interface notification element is detailed in .
MRB Publish interface response element is contained in .The <mrbpublish> element has zero or more of the following attributes:
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, only one of which is allowed
to occur in a request.
<mrbrequest> for sending an MRB request. See .<mrbresponse> for sending an MRB response. See .<mrbnotification> for sending an MRB notification. See .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 zero or more of the following child elements:
<subscription> for initiating a subscription to a Media Server from an MRB. See .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. 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 how long
it wishes to receive updates for 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:
indicates a unique token representing the subscription session between the MRB
and the Media Server. The attribute MUST be present. indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific subscription command.
The first subscription
MUST have 1 as 'seqnumber', and following subscriptions MUST increment by 1 the
previous 'seqnumber' value.
The attribute MUST be present. provides the operation that should be carried out on the subscription:
The value of 'create' instructs the MS to attempt to set-up a new subscription.The value of 'update' instructs the MS to attempt to update an existing subscription.The value of 'remove' instructs the MS to attempt to remove an existing subscription
and consequently stop any ongoing related notification.
The attribute MUST be present.The <subscription> element has zero or more of the following child elements:
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 in case it is still interested in receiving notifications from the MS. The element MAY be present.Provides the minimum frequency in seconds that the MRB wishes to receive notifications
from the MS. The element MAY be present.Provides the maximum frequency in seconds that the MRB wishes to receive notifications
from the MS. The element MAY be present.
Please note that these three optional pieces of
information provided by the MRB only act as a suggestion: the MS MAY change the proposed values if it considers
the suggestions unacceptable (e.g., if the MRB has requested a too high notification frequency). In such case,
the request would not fail, but the updated, acceptable values would be reported in the <mrbresponse> accordingly.
The <mrbnotification> element is included in a request from a Media Server to an MRB to provide the
details relating 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:
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. indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific notification update.
The first notification
MUST have 1 as 'seqnumber', and following notifications MUST increment by 1 the
previous 'seqnumber' value.
The attribute MUST be present.The following subsections provide details of the child elements that are the content of the
<mrbnotification> element.The <media-server-id> element provides a unique system wide identifier for a Media Server
instance. The element MUST be present.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 zero or more of the following child elements:
The <package> element 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0").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.The <active-rtp-sessions> element has zero or more of the following child elements:
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 MIME media type
(which can include parameters per ). 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. The child element, <encoding>, has as content
the decimal number of RTP sessions being encoded using the specified codec.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 zero or more of the following child elements:
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 defined in
. The element MAY be present.The <non-active-rtp-sessions> element provides information detailing the currently available inactive
RTP sessions. The element MAY be present.The <non-active-rtp-sessions> element has no attributes.The <non-active-rtp-sessions> element has zero or more of the following child elements:
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 MIME media type
(which can include parameters per ). The <rtp-codec> element has two child
elements. The child element, <decoding>, has as content the decimal number of
RTP sessions available for decoding using the specified codec. The child element, <encoding>, has as content
the decimal number of RTP sessions available for encoding using the specified codec.The <non-active-mixer-sessions> element provides information detailing the current inactive
mixed RTP sessions. The element MAY be present.The <non-active-rtp-sessions> element has no attributes.The <non-active-mixer-sessions> element has zero of more of the following child element:
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 defined in
. The element MAY be present.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:
Indicating that the Media Server is available for service. Indicating that the Media Server has been withdrawn from service,
and as such requests should not be sent to it before it becomes 'active' again. Indicating 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.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 zero or more of the following child element:
has a single attribute, 'name', which provides the
name of the codec about which this element provides information. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., ). 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"),
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:
'decode', meaning a decoder for this codec is available;'encode', meaning an encoder for this codec is available;'passthrough', meaning the MS is able to pass a stream encoded using that codec through without re-encoding.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 are the same as those in XML (viz., tab, carriage
return, line feed, and the legal characters of Unicode and ISO/IEC
10646 [see http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.The <application-data> element has no attributes.The <application-data> element has no child elements.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:
has a single attribute, 'name', which provides the
type of file format that is supported. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., ). 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.The <max-prepared-duration> element provides the maximum amount of time a media dialog
can be prepared 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 zero or more of the following child elements:
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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the time period applies.The <dtmf-support> element specifies the supported methods to detect 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:
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 either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.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 either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.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 either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.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:
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. It 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"), for which the algorithm support applies. Describes the available video
presentation layouts and the supported functionality for what concerns 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 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 predefined video layouts defined in the XCON
conference information data model, or to non-XCON layouts as well, as long as they are properly 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
the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm
support applies.The <supported-tones> element provides information about which
tones a media server supports. In particular, the support is reported
referring to both country codes support (ISO 3166-1 ) and supported
functionality (ITU-T Recommendation 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:
Describes the supported
country codes with respect to tones. The <supported-country-codes>
element has no attributes. The <supported-country-codes> has one
child element. The child element, <country-code>, reports support
for a specific country code, compliant with the 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 supported. Describes the supported
H.248 codes with respect to tones. The <supported-h248-codes>
element has no attributes. The <supported-h248-codes> 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
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 wild-cards. The <h248-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 specified codes are supported.The <streaming-modes> element allows the Media Server to specify which protocols are supported
for streaming to a Media Server for each Media Control Channel Framework package type. For example, whether the Media Server
supports audio streaming via RTSP, HTTP, NFS, etc protocols. The element MAY be present.The <streaming-modes> element has no attributes.The <streaming-modes> element has zero or more of the following child element:
has two attributes, 'name' and 'package'. The 'name' attribute provides the
type of protocol that can be used for streaming (e.g., "HTTP", "RTSP", etc.).
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 streaming protocol applies.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 are reported by referring to the supported
languages (using ISO-639-1 codes) for what regards 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:
Describes the available languages for ASR. The
<asr-support> element has no attributes. The <asr-support> has one child element.
The child element, <language>, reports the MS supports ASR for a specific language.
The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang'
contains the ISO-639-1 code of the supported language. Describes the available languages for TTS. The
<tts-support> element has no attributes. The <tts-support> has one child element.
The child element, <language>, reports the MS supports tts for a specific language.
The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang'
contains the ISO-639-1 code of the supported language.The <vxml-support> element specifies if the Media Server supports VoiceXML and if it does which
protocols the support is exposed through (e.g., via the control framework, RFC4240 , or RFC5552 ).
The element MAY be present.The <vxml-support> element has no attributes.The <vxml-support> element has zero or more of the following child elements:
has two attributes, 'package' and 'support'. 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 VXML support
applies. The 'support' attribute provides the type of VXML support provided by the
Media Server (RFC5552 , RFC4240 or IVR-Package ).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 the Media Server does not support VXML at all.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. The element MAY be present.The <media-server-location> element has no attributes.The <media-server-location> element has zero or more of the following child elements:
Describes the civic
address location of the media server, whose representation refers to the
Section 4 of RFC 5139.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, and as such is not meant to provide any explicit information associated
with the features of a MS. The element MAY be present.The <label> element has no attributes.The <label> element has no child elements.The <media-server-address> element allows a Media Server to provide
a direct SIP URI address where it can be reached (e.g., the URI AS would
call to in order to set-up a Control Channel and relay call legs).
The element MAY be present.The <media-server-address> element has a single attribute.The <media-server-address> element has no child elements.The <encryption> element allows a Media Server to declare support for encrypting RTP media streams
using RFC 3711. The element has character content 'true' if a Media Server does support
RFC 3711 for RTP, and 'false' if it does not. The element MAY be present.The <encryption> element has no attributes.The <encryption> element has no child elements.Responses to requests are indicated by a <mrbresponse> element. The <mrbresponse> element has the following attributes:
numeric code indicating the response status. The
attribute MUST be present.string specifying a reason for the response status. The
attribute MAY be present.The <mrbresponse> element has zero or more of the following child elements:
<subscription> for providing details related to a subscription a Media Server requested (see below in this section).The following status codes are defined for 'status': codedescription200OK400Syntax error401Unable to create Subscription402Unable to update Subscription403Unable to remove Subscription404Subscription does not exist405Subscription already exists420Unsupported attribute or element
In case a new subscription request made by an MRB (action='create') has been accepted,
the MS MUST reply with a <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 MS.
A subscription request, nevertheless, may fail for several reasons. In such
a case, the status codes defined in
must be used instead. Specifically, if the MS 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 MS MUST reply with a <mrbresponse> with status code 400.
If a syntactically correct request fails because the request also includes any
attribute/element the MS doesn't understand, the MS MUST reply with a <mrbresponse> with status code 420.
If a syntactically correct request fails because the MRB wants to create a new subscription,
but the provided intended id for the subscription already exists, the MS MUST reply
with a <mrbresponse> with status code 405. If a syntactically correct request
fails because the MRB wants to update/remove a subscription that doesn't exist,
the MS MUST reply with a <mrbresponse> with status code 404.
If the MS is unable to accept a request for any other
reason (e.g., the MRB has no more resources to fulfil the request),
the MS MUST reply with a <mrbresponse> with status code 401/402/403,
depending on the action the MRB provided in its request:
action='create' --> 401;action='update' --> 402;action='remove' --> 403;
A response to a subscription request that has a status 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 MS MAY 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 MS
accepted it, and the MS MUST include in the <subscription> element
all of those values that it modified relative to the request, to
inform the MRB about the change.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. The 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 decision and provide the client with an appropriate media server
resource. The MRB Consumer interface includes both 1) In-Line Aware MRB Mode
(IAMM) that uses the Session Initiation Protocol (SIP) and 2) Query mode that uses
the Hypertext Transfer Protocol (HTTP)
. The MRB Consumer interface does not include In-Line Unaware Mode
(IUMM) which is further explained in . The following subsections provide guidance on
using the Consumer interface, as defined by the 'application/mrb-consumer+xml MIME
type in , with HTTP and SIP.An appropriate interface for such a 'query' style interface is
in fact a HTTP usage. Using HTTP and XML combined reduces complexity
and encourages 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 and HTTPS as
transport for a query for media resource and the appropriate response.The media resource query, as defined by the <mediaResourceRequest> element from
, MUST be carried in the body of an HTTP/HTTPS
POST request. The MIME type contained in the HTTP/HTTPS
request/response MUST be 'application/mrb-consumer+xml'. This value MUST
be reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS POST request MUST only contain a <mrbconsumer> root element with only one child
<mediaResourceRequest> element as defined
in .The media resource response to a query, as defined by the <mediaResourceResponse> element from
, MUST be carried in the body of an HTTP/HTTPS
200 response to the original HTTP/HTTPS POST request. The MIME type contained in the HTTP/HTTPS
request/response MUST be 'application/mrb-consumer+xml'. This value MUST
be reflected in the appropriate HTTP headers like 'Content-Type' and
'Accept'. The body of the HTTP/HTTPS 200 response MUST only contain
a <mrbconsumer> root element with only one child
<mediaResourceResponse> element as defined
in .When an application server wants to release previously awarded media resources granted through a
prior request/response exchange with MRB, it will send a new request with an <action> element with value
'remove' as described in about the use of the Consumer interface
lease mechanism.This document provides a complete tool-kit for MRB deployment which 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 as transport for a request for media resources and the appropriate
response when used with IAMM of operation (as discussed in ).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 () or a call leg media session between an application
server and one of the media servers (). Note that in either case the SIP addresses 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 ().The media resource request information, as defined by the <mediaResourceRequest> element from
, MUST be 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 . The following
additional steps MUST be followed when using the Consumer interface:
Include a payload in the SIP INVITE request of type
'multipart/mixed' . 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 . Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and defined in
. The body part MUST be an XML document without prolog and whose
root element is <mediaResourceRequest>. The INVITE request will then be dispatched to the MRB, as defined
by .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:
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.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 . The policy the MRB follows to pikc a specific MS out
of the MSs it selects is implementation specific, and out of scope to this document.The MRB acts as a Back-to-Back UA (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.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 by MRB to a request, as defined by the <mediaResourceResponse> element from
, MUST be carried in the payload of a SIP
2xx class response to the original SIP INVITE request. The 2xx class
response will be constructed as it would have been to connect from a media server, as
defined by the Media Control
Channel Framework . The following
additional steps MUST be followed when using the Consumer interface:
Include a payload in the SIP 2xx class response of type
'multipart/mixed' as per RFC 2046. 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 . Another part of the 'multipart/mixed' payload MUST be of type
'application/mrb-consumer+xml', as specified in this document and defined in
. Only the <mediaResourceResponse> and its child
elements can be included in the payload. The SIP 2xx class response will then be dispatched from the MRB.A SIP ACK to the 2xx class response will then be sent back to the MRB.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 interval expires.This scenario is identical to the description in the prior section for setting up a Control Framework
control channel, except for the difference that the application/sdp payload conveys content appropriate
for setting up the call leg to the media resource, as per RFC 3261, instead of application/sdp payload
for setting up a control channel.The Consumer interface defined in
and allows a client to request an appropriate
media resource based on information included in the request (either a HTTP POST
or SIP INVITE message). In case of success, the response that is returned to the client MUST contain
a <response-session-info> element in either the SIP 2xx class 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 lease mechanism, though, it's worthwhile
to first clarify its role within the context of the Consumer interface. As
explained in , the knowledge the MRB has of the resources
of all the MSs it handles is imperfect. As such, how an MRB actually manages such
resources depends on how it is implemented: one may choose to have the MRB keeping
track and state of the allocated resources, or simply depend on the MSs themselves
to provide the information by means of the publishing interface notifications.
Further information may be inferred by the signalling, in case the MRB is in
the path of call legs.That said, 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:
<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 <session-id>
use later in this section when constructing a subsequent request).<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 in the request (see <seq>
use later in this section when constructing a subsequent request).<expires> provides a value which provides the number of seconds 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 expires timer is due to fire
and the media resources are still required.<media-server-address> provides information representing an assigned MS. More instances
of this element may appear, should the MRB assign more MSs 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:
<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>).<seq> is a numeric value returned to 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 to
and in conjunction with the unique <session-id> allows for unique identification of a request.<action> element 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 at the MRB
with alternate requirements which are contained in the remainder of the request. 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 at 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.
When used with HTTP the <session-info> element MUST be included in a HTTP POST
message (as defined in ).
When used with SIP, instead, the <session-info> element MUST be included in either a SIP INVITE, or a
SIP re-INVITE (as defined in ) or a SIP UPDATE (as defined in) 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 requesting 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 call leg. That BYE contains no Consumer
interface lease information. In no case should an MRB conclude
that the resources are no longer needed once a call leg drops from
the MS, since the associated lease remains valid and the AS might
use the resources for other calls.This section defines the XML elements for the Consumer interface. The formal XML schema definition
for the Consumer interface can be found in .The root element is <mrbconsumer>. All other XML elements (requests, responses) are
contained within it. The MRB Consumer interface request element is detailed in .
MRB Consumer interface response element is contained in .The <mrbconsumer> element has the following attributes:
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 .<mediaResourceResponse> for sending a Consumer response. See .This section provides the element definitions for use in Consumer
interface requests. The requests are carried in the
<mediaResourceRequest> element.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, which 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 the following sub-sections.The <generalInfo> element provides a information for general Consumer request information
that is neither IVR or Mixer specific. This includes session information that can be used for
subsequent requests as part of the leasing mechanism described in .
The following sub-sections describe the elements of the <generalInfo> element,
<session-info> and <packages>.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 . 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:
is 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 . is 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
about its use is provided in . 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 .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 zero or more of the following child element:
child element 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 as specified
in the related IANA registry (e.g., "msc-ivr/1.0")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 <stream-mode>.The <ivr-sessions> element indicates the number of IVR sessions 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 zero or more of the following child element:
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 MIME media type
(which can include parameters per ). The <rtp-codec> element has two child
elements. The child element, <decoding>, has as content the decimal number of
RTP sessions required for decoding using the specified codec. The child element, <encoding>, has as content
the decimal number of RTP sessions required for encoding using the specified codec.The <file-formats> element provides a list of file formats required for the
purpose of playing media. The element MAY be present.The <file-formats> element has no attributes.The <file-formats> element has zero or more of the following child element:
has a single attribute, 'name', which provides the
type of file format that is required. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., ). 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.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:
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 needed, and it can only be either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.Indicates the required 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 needed, and it can only be either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.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 being needed, and it can only be either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.The <tones> element provides requested
tones a media server must support for IVR. In particular, the request refers
to both country codes support (ISO 3166-1 ) and requested
functionality (ITU-T Recommendation 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:
Describes the requested
country codes with respect to tones. The <country-codes>
element has no attributes. The <country-codes> has one
child element. The child element, <country-code>, requests
a specific country code, compliant with the 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. Describes the requested
H.248 codes with respect to tones. The <h248-codes>
element has no attributes. The <h248-codes> has one
child element. The child element, <h248-code>, requests
a specific H.248 code, compliant with the ITU-T Recommendation 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 wild-cards. The <h248-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 specified codes are
requested.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 codes) for what regards both ASR and TTS.
The <asr-tts> element has no attributes.
The <asr-tts> element has zero or more of the following child elements:
Describes the available languages for ASR. The
<asr-support> element has no attributes. The <asr-support> has one child element.
The child element, <language>, requests the MS supports ASR for a specific language.
The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang'
contains the ISO-639-1 code of the supported language. Describes the available languages for TTS. The
<tts-support> element has no attributes. The <tts-support> has one child element.
The child element, <language>, requests the MS supports tts for a specific language.
The <language> element has a single attribute, 'xml:lang'. The attribute 'xml:lang'
contains the ISO-639-1 code of the supported language.The <vxml> element specifies if the Consumer client required VoiceXML and if it does which
protocols the support is exposed through (e.g., via the control framework,
RFC4240 , or RFC5552 ).
The element MAY be present.The <vxml> element has zero or more of the following child elements:
has two attributes, 'package' and 'require'. 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 VXML support
applies. The 'require' attribute specifies the type of VXML support required by the
Consumer client (RFC5552 , RFC4240 or IVR-Package ).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 the Consumer client does not require VXML support.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. The element MAY be present.The <location> element has no attributes.The <location> element has a single child element:
Describes the civic
address location of the requested media server, whose representation refers to
Section 4 of RFC 5139.The <encryption> element allows a Consumer client to request support for encrypting RTP media streams
using RFC 3711. The element has character content 'true' if a Media Server does support
RFC 3711 for RTP, and 'false' if it does not. The element MAY be present. The default value
is 'false'The <encryption> element has no attributes.The <encryption> element has no child elements.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 are the same as those in XML (viz., tab, carriage
return, line feed, and the legal characters of Unicode and ISO/IEC
10646 [see http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.The <application-data> element has no attributes.The <application-data> element has no child elements.The <max-prepared-duration> element provides the amount of time required by the Consumer client
that a media dialog can be prepared 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:
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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the time period applies.The <streaming-modes> element allows the Consumer client to specify which protocols are required
for streaming to a Media Server for each Media Control Channel Framework package type. For example does the Media Server
supports audio streaming via RTSP, HTTP, NFS, etc protocols. The element MAY be present.The <streaming-modes> element has no attributes.The <streaming-modes> element has a single child element:
has two attributes, 'name' and 'package'. The 'name' attribute provides the
type of protocol required for streaming. 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 streaming protocol applies.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-type>, <tones>, <mixing-mode>, <application-data>, <location> and <encryption>.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:
Describes 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 defined in
. The element MAY be present.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:
has a single attribute, 'name', which provides the
type of file format that is supported. A valid value is a MIME media type
which, depending on its definition, can include
additional parameters (e.g., ). The <required-format> element then has
a further 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 the specification in the related IANA registry (e.g., "msc-ivr/1.0"), for which the file format support applies.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:
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 it can only be either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.Indicates the required 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 either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.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 being used, and it can only be either 'RFC4733' or 'Media' (tones as signals in the audio stream).
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 DTMF type applies.The <tones> element provides requested
tones a media server must support for a mix. In particular, the request refers
to both country codes support (ISO 3166-1 ) and requested
functionality (ITU-T Recommendation 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:
Describes the requested
country codes with respect to tones. The <country-codes>
element has no attributes. The <country-codes> has one
child element. The child element, <country-code>, requests
a specific country code, compliant with the 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. Describes the requested
H.248 codes with respect to tones. The <h248-codes>
element has no attributes. The <h248-codes> has one
child element. The child element, <h248-code>, requests
a specific H.248 code, compliant with the ITU-T Recommendation 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 wild-cards. The <h248-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 specified codes are requested.The <mixing-modes> element requests 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:
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 specific requested algorithm. It 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"), for which the algorithm support is requested. 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 predefined video layouts defined in the XCON
conference information data model, or to non-XCON layouts as well, as long as they are properly 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 the specification
in the related IANA registry (e.g., "msc-ivr/1.0"), for which the algorithm
support is requested.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 are the same as those in XML (viz., tab, carriage
return, line feed, and the legal characters of Unicode and ISO/IEC
10646 [see http://www.w3.org/TR/xml/ section 2.2]). The element MAY be present.The <application-data> element has no attributes.The <application-data> element has no child elements.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. The element MAY be present.The contents of a <location> element has no attributes.The contents of a <location> element has a single child element:
Describes the civic
address location of the requested media server, whose representation refers to
Section 4 of RFC 5139.The <encryption> element allows a Consumer client to request support for encrypting mixed RTP media streams
using RFC 3711. The element has character content 'true' if a Media Server does support
RFC 3711 for RTP, and 'false' if it does not. The element MAY be present. The default value
is 'false'The <encryption> element has no attributes.The <application-data> element has no child elements.This section provides the element definitions for use in Consumer interface
responses. The responses are carried in the <mediaResourceResponse>
element.The <mediaResourceResponse> element provides a 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 the client provided
in the 'id' attribute in the <mediaResourceRequest> the response is for. The 'status' attribute
indicates the status code of the operation. The following status codes are defined for 'status': codedescription200OK400Syntax error408Unable to find Resource409Unable to update Resource410Unable to remove Resource420Unsupported attribute or element
In case a new media resource request made by an AS 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
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 the MRB couldn't find any MS able to
fulfil the requirements presented by the AS 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 AS 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 AS,
the MRB MUST reply with a <mediaResourceResponse> with status code 410.
Further details on status codes 409 and 410 are presented in ,
where the leasing mechanism, together with its related scenarios, is described.
The <mediaResourceResponse>
element only 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.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 .
If the request was successful, the <mediaResourceResponse> MUST
have one <response-session-info> child, which describes the media
resource session which was addressed by the request. If the
request was not successful, the <mediaResourceResponse> MUST NOT
have a <response-session-info> child.
The contents of a <response-session-info> element has no attributes.The contents of a <response-session-info> element has zero or more of the following child elements:
is 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 . is 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
its use is provided in . 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 re-claim 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 time-out period could be used.
For example, if the time-out period is 300 seconds, the Server would
refresh the transaction at 240 seconds. More information on its use is provided in . provides information to reach the MS handling the requested media resource. One or
more instances of these element 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> are defined in and
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 MSs are assigned in an IAMM operation, exactly one <media-server-address>
element, the one describing the one that provided the call-leg or CFW response, will have a
<connection-id> element. For more information on the use of the <connection-id> element
for call legs, instead, see .An entity acting as an In-Line MRB can act in one of two roles for a request, as introduced
in . In-Line Unaware
MRB Mode (IUMM) of operation and 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
(Query mode) and (IAMM). Nevertheless, an
MRB is conceived to also
be able to act in a client unaware mode when it is deployed into the network.
This allows any SIP compliant client entity, as defined by RFC 3261 and its
extensions, to send requests to an MRB which 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 that SIP dialog that initiated the request.As with IAMM, in IUMM the SIP INVITE from the application server could convey application/sdp payload to either
set up a call leg or a Control Framework control channel. In either case, in order to permit the AS to associate a call leg
with a control channel to the same media server using the
procedures of section 6, the MRB should be acting as a SIP
proxy (and not a B2BUA) so that the SIP address of the targeted
media server can be transparently passed back to the application
server in the SIP response and so that the SIP dialog is 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 .An MRB entity can potentially act as a SIP Back-2-Back-User-Agent (B2BUA) or a SIP Proxy Server as defined in
RFC 3261. When acting as a B2BUA issues can arise when using Media Control Channel
packages such as the IVR and Mixer
Packages. Specifically the Framework attribute 'connectionid' provided in
the appendix titled 'Appendix: Common Package Components' of Media Control Channel
Framework 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' can not be used as intended due to the SIP dialog
identifiers changing. For this reason when a MRB wishes to act as a SIP B2BUA when handling a request from an AS to set
up a call leg to a MS 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 a HTTP Consumer interface response.It is important to point out that, although more MSs instances may be returned in a Consumer response (i.e., the
MRB has assigned more than one MS to a Consumer request to fulfill the AS requirements), in IAMM the MRB will
only act as a B2BUA with a single MS: in this case, exactly one <media-server-address> element, the one
describing the one that provided the call-leg or CFW response, will have a <connection-id> element, which will
instead be missing in the other <media-server-address> elements.An MRB implementation may operate multi-modally with a collection of application server clients all sharing the same
pool of media resources. I.e., 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 nature of the request:
If the received quest is HTTP Post with application/mrb-consumer+xml content, then MRB processes it in Query mode.If the received request is a SIP INVITE with application/mrb-consumer+xml content and application/sdp content, then
MRB processes it in IAMM.If the received request is a SIP INVITE without application/mrb-consumer+xml content but with application/sdp content
then MRB processes it in IUMM.At a high level, the possible application server MRB interactions can be distinguished among the following basic
types:
Query mode, in which the client is requesting the assignment by MRB of suitable MSs resources;IAMM in which the client is requesting the assignment by MRB of suitable MSs resources and the
establishment of a call leg to one of the MSs;IAMM in which the client is requesting the assignment by MRB of suitable MSs resources and the establishment
of a CFW control channel to one of the MSs;IUMM where the client is requesting the establishment of a call leg to MS resources;IUMM where the client is requesting the establishment of a CFW control channel to MS resources.
Each type of interaction has advantages and disadvantages compared to the others, where such considerations may have to
do with the versatility of what 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 makes a few observations on relative merits, but is not intended to be
exhaustive. Some constraints of a given interaction type may be subtle.
About operation with other types of media control: Any of the types of interactions work with the use
RFC 4240 and RFC 5552 where initial control
instructions are conveyed in the SIP INVITE from the application
server for the call leg to the media server and subsequent instructions may be fetched using HTTP. Query mode
(a), IAMM/call leg (b) and IUMM/call leg (d) work with MSML as per RFC 5705 or
MSCML as per RFC 5022.As stated previously, IUMM has no interface impacts on an application server. On the other hand, with IUMM
the application server does not specify the characteristics of the type of media resource it needs because
the <mediaResourceRequest> element is not passed to the MRB. For IUMM call leg (d) the best the MRB can do to
deduce an appropriate media resource gleaned from examining other information in the SIP INVITE, such as the
SDP information for the call leg, or initial control information in the SIP Request URI as per
RFC 4240. With
IUMM/control channel (e) there is even less information for the MRB to use. If using IUMM/control channel (e), the subsequent sending of the call leg to the media server should not
be done using IUMM/call leg. I.e., the SIP signaling to send the call leg to the selected media server must be
directly between the application server and that media server, and not through the MRB. Otherwise, MRB might
send the call leg to a different media server. Likewise, if using IUMM/call leg (d), the subsequent
establishment of a control channel should not be done with IUMM/control channel (e).Query mode (a) and IAMM/control channel (c) lend themselves to requesting in advance a pool of media
resources (e.g., a number of IVR or conferencing ports) in advance of use and retaining their use over a
period of time, independent of whether there are call legs to those resources at any given moment, whereas
the other types of interactions do not. Likewise for making a subsequent request to increase or decrease
the amount of resources previously awarded.While Query mode (a) and IAMM/control channel (c) are the most versatile interaction types, the former
is completely decoupled from the use or not of a control channel, whereas the latter requires the use of a control
channel.When Media Control Channel Framework control channels are to be used in conjunction with the use of 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 AS has a new
request for MBR for media resources.This section provides examples of both the Publish and Consumer interfaces. For what concerns the
Consumer interface, both Query and Inline modes are addressed.
Note that due to RFC formatting conventions, this section often splits
HTTP, SIP/SDP and CFW across lines whose content would exceed 72 characters.
A backslash character marks where this line folding has taken place. This
backslash and its trailing CRLF and whitespace would not appear in the actual
protocol contents. Besides, also note that the indentation of the XML
content is only provided for readability: actual messages will follow strict
XML syntax, which allows for, but does not require, indentation.
The following example assumes a control channel has been established
and synced as described in the Media Control Channel Framework
().
shows the subscription/notification mechanism
the Publish interface is based on, as defined in .
The MRB subscribes for information at the MS (message A1.), and the MS accepts the subscription (A2).
Notifications are triggered by the MS (A3.) and acknowledged by the MRB (A4.).
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
the subscription (A1), in an <mrbrequest> (CFW CONTROL);the MS accepting the subscription (A2), in an <mrbresponse> (CFW 200);a notification (A3), in a <mrbnotification> (CFW CONTROL event);the ack to the notification (A4), in a framework level 200 message (CFW 200);
As specified in , the Consumer interface
can be involved in two different modes: Query and Inline-aware. When in Query mode,
Consumer messages are transported in HTTP messages: an example of such an
approach is presented in . When in
Inline-aware mode, instead, messages are transported as part of SIP negotiations:
considering that SIP negotiations may be related to either the creation of a
control channel or to a UAC call leg, two separate examples of such an approach are
presented in .
The following example assumes the interested AS already knows the
HTTP URL where an MRB is listening for Consumer messages.
shows the HTTP-based transaction between the AS and
the MRB. The AS sends a consumer request as payload of an HTTP POST message (1.),
and the MRB provides an answer in an HTTP 200 OK message (2.). Specifically,
as it will be shown in the dumps, the AS is interested in 100 IVR ports: the MRB
finds two MSs that can satisfy the request (one providing 60 ports, the other 40 ports)
and reports them to the AS.
The rest of this section includes a full dump of the messages
associated with the previous sequence diagram, specifically:
the Consumer request (1), in a <mediaResourceRequest> (HTTP POST, Content-Type 'application/mrb-consumer+xml');the Consumer response (2), in an <mediaResourceResponse> (HTTP 200 OK, Content-Type 'application/mrb-consumer+xml').As the dumps evince, the request and response are associated by means of the
'id' attribute (id="gh11x23v").
The rest of the scenario is omitted for brevity. After having received
the 'mediaResourceResponse', the AS has the address of two MSs able to
fulfil its media requirements, and can start a Control Dialog with one
or both of them.
As anticipated, two separate examples are presented for the IAMM case: in fact,
IAMM-mode can take advantage of two different approaches with respect to the
SIP dialogs to be exploited to carry consumer messages, i.e.: i) a SIP control
dialog to create a control channel, and, ii) a UAC call leg to attach to a MS.
To make things clearer for the reader, the same consumer request as the one
presented in the Query mode will be sent, in order to clarify how the
behaviour of the involved parties may differ.
The following example assumes the interested AS already knows the
SIP URI where an MRB is listening as an UAS.
shows the first approach, i.e. SIP-based transactions
between the AS, the MRB and one MS that the MRB chooses from the two that are
allocated to fulfill the request. The diagram is more complex than before.
This is basically a scenario envisaging the MRB as a B2BUA. The AS sends a SIP
INVITE (1.), containing both a CFW-related SDP and a Consumer request (multipart body).
The MRB sends a provisional response to the AS (2.) and starts working on the request.
First of all, it makes use of the Consumer request from the AS to determine which MSs
should be exploited. Once the right MSs have been chosen (MS1 and MS2 in the example),
the MRB sends a new SIP INVITE to one of the MSs (MS1 in the example)
by just including the SDP part of the original request (3.). That MS
negotiates this INVITE as specified in
(4., 5., 6.), providing the MRB with its own CFW-related SDP. The MRB replies to the
original AS INVITE preparing a SIP 200 OK with another multipart body (7.): this
multipart body includes the Consumer response used by the MRB to determine the right MSs
and the SDP returned by the MS (MS1) in 5. The AS finally acknowledges the 200 OK (8.), and
can start a CFW connection towards that MS (MS1). Since the MRB provided the AS with two
MSs instances to fulfill its requirements, the AS can use the URI in the <media-server-address>
element in the <mediaResourceResponse> that describes the other MS to establish a CFW
channel with that MS (MS2) as well.
Please note that, to ease the reading of the protocol contents, a simple '=_Part' is
used whenever a boundary for a 'multipart/mixed' payload is provided, instead of
the actual boundary that would be inserted in the SIP messages.
The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP messages
are shown (both the INVITEs and the 200 OKs), and only the relevant headers
are preserved for brevity (Content-Type and multipart-related information).
Specifically:
the original INVITE (1), containing both a CFW-related SDP (COMEDIA information
to negotiate a new Control Channel) and a Consumer <mediaResourceRequest>;the INVITE sent by the MRB to the MS as a B2BUA (3.), containing only the
CFW-related SDP from the original INVITE;.the 200 OK sent by the MS back to the MRB (5.), to complete the CFW-related negotiation (SDP only);the 200 OK sent by the MRB back to the AS in response to the original INVITE (7.),
containing both the CFW-related information sent by the MS and a Consumer
<mediaResourceRequest> documenting the MRB's decision to use that MS.
As the dumps evince, the only difference in the response
the MRB provides the AS with is in the 'connection-id' attribute that
is added to the first allocated MS instance: this allows the AS to
understand the MRB has sent the CFW channel negotiation to that
specific MS, and that the connection-id to be used (should the SIP
control dialog also include media-related SDP later on) is the
one provided. This will be more carefully described in the next section,
for the call leg-based approach.
The continuation of the scenario (the AS connecting to MS1 to start the Control Channel and
the related SYNC message, the AS connecting to MS2 as well later on, all the call legs
being attached to either MS) are omitted for brevity.
The following example assumes the interested AS already knows the
SIP URI where an MRB is listening as an UAS.
shows the second approach, i.e. SIP-based transactions
between a SIP client, the AS, the MRB and the MS that the MRB chooses. The interaction is basically the
same as before (e.g. for what concerns the multipart body) but considering a new
party is involved in the communication, the diagram is slightly more complex than before.
As before, the MRB acts as a B2BUA. A UAC sends a SIP INVITE to a SIP URI handled by the AS,
since it is interested to its services (1.). The AS sends a provisional response (2.) and,
since it doesn't have the resources yet, sends to the MRB a new SIP
INVITE (3.), containing both the UAC media-related SDP and a Consumer request (multipart body).
The MRB sends a provisional response to the AS (4.) and starts working on the request.
First of all, it makes use of the Consumer request from the AS to determine which MSs
should be chosen. Once the right MSs have been chosen, the MRB sends a new SIP INVITE
to one of the MSs by just including the SDP part of the original request (5.). The MS
negotiates this INVITE as specified in
(6., 7., 8.) to allocate the needed media resources to handle the new call leg,
eventually providing the MRB with its own media-related SDP. The MRB replies to the
original AS INVITE preparing a SIP 200 OK with another multipart body (9.): this
multipart body includes the Consumer response from the MRB indicating the chosen MSs
and the SDP returned by the MS in 7. The AS finally acknowledges the 200 OK (10.), and
ends the scenario by eventually providing the UAC with the SDP it needs to set-up
the RTP channels with the chosen MS: a separate direct SIP control dialog may be initiated
by the AS to the same MS in order to set up a control channel to manipulate the call leg media.
As with the IAMM - CFW example in the prior section, this example has
the MRB selecting MS resources across two MS instances. And here again
the convention can be that the MRB sent the SIP INVITE to the first MS
in the list provided to the AS in the Consumer response information. For the sake
of brevity, the considerations about connecting to the other MS as well are omitted,
since they have already been addressed in the previous section.
Please note that, to ease the reading of the protocol contents, a simple '=_Part' is
used whenever a boundary for a 'multipart/mixed' payload is provided, instead of
the actual boundary that would be inserted in the SIP messages.
The rest of this section includes an almost full dump of the messages
associated with the previous sequence diagram. Only the relevant SIP messages
are shown (both the INVITEs and the 200 OKs), and only the relevant headers
are preserved for brevity (Content-Type, From/To and multipart-related information).
Specifically:
the original INVITE (1), containing the media-related SDP sent by a UAC;the original INVITE (3), containing both the media-related SDP and a
Consumer <mediaResourceRequest>;the INVITE sent by the MRB to the MS as a B2BUA (5.), containing only the
media-related SDP from the original INVITE;the 200 OK sent by the MS back to the MRB (7.), to complete the media-related negotiation (SDP only);the 200 OK sent by the MRB back to the AS in response to the original INVITE (9.),
containing both the media-related information sent by the MS and a Consumer
<mediaResourceRequest> documenting the MRB's decision to use that MS;the 200 OK sent by the AS back to the UAC to have it set-up the RTP channel(s) with the MS (11.).
As the dumps evinced, as in the IAMM-CFW example, the MRB provides
the AS with a 'media-server-address' element in the consumer
response: the 'uri' attribute identifies the specific MS to which
the MRB has sent the SDP media negotiation, and the 'connection-id'
enables the AS to identify to the MS the dialog between the MRB and
MS. This attribute is needed, since, according to the framework
specification, the connection-id is built out of the From/To tags
of the dialog between the MRB and MS; since the MRB acts as a B2BUA
in this scenario, without that attribute the AS does not know the
relevant tags, thus preventing the CFW protocol to work as expected.
The continuation of the scenario (the AS connecting to the MS to start the Control Channel, the SYNC message, etc.)
are omitted for brevity.
This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the
"application/mrb-publish+xml" format.This section gives the XML Schema Definition
[W3C.REC-xmlschema-1-20041028], [W3C.REC-xmlschema-2-20041028] of the
"application/mrb-consumer+xml" format.The MRB network entity has two primary interfaces, Publish and Consumer,
that carry sensitive information and must therefore be appropriately protected
and secured.The Publish interface, as defined in and described in ,
uses the Media Control Channel Framework
as a mechanism to connect an MRB to a media server. The appropriate Security
Considerations included in the Media Control Channel Framework specification MUST be
used in conjunction with this specification to protect interactions between an MRB
and a media server.The Consumer interface, as defined in and described in ,
uses either the Hypertext Transfer Protocol (HTTP) or Session
Initiation Protocol (SIP) as the mechanism for clients to connect to an MRB to
request media resources. In the case of the HTTP use, any binding using the Consumer
interface MUST be capable of being transacted over TLS, as described in
RFC 2818.
In the case of the SIP use, the appropriate security
considerations included in the Media Control Channel Framework specification MUST be
used in conjunction with this specification to protect interactions between a client
requesting media resources and an MRB.It is also worth noting that in In-line mode (both IAMM and IUMM) the MRB
may act as a Back-to-Back User Agent (B2BUA). This means that, as a B2BUA, the
MRB may happen to modify SIP bodies: it is the case, for instance, of the IAMM
handling multipart/mixed payloads. This impacts the ability to use any SIP
security feature that protects the body (e.g., RFC4474, s/mime, etc.) unless
the MRB intermediates the security association. This should be taken into
account when implementing an MRB compliant with this specification.Finally, it is worthwhile to also discuss authorization issues related
to the specification. Neither the Publishing nor the Consumer interface
provide an explicit means for implementing authentication, i.e., they
do not envisage protocol messages to make sure, for instance, that
only authorized Application Servers can make use of the services provided
by a MRB. Nevertheless, considering both the interfaces are transported
in well-established protocols (HTTP, SIP, CFW), support for such an
functionality can be expressed by means of the authentication mechanisms
provided by the protocol themselves. Therefore, any
MRB-aware entity (Application Servers, Media Servers, Media Resource
Brokers themselves) MUST support the HTTP and SIP Digest access
authentication. That said, the usage of such Digest access authentications
is recommended and not mandatory, which means MRB-aware entities MAY
exploit it in deployment.There are several IANA considerations associated with this specification.This section registers a new Media Control Channel Framework package,
per the instructions in Section 13.1 of
.ietf-sip-control@iana.orgRegistration of new Media Control Channel Framework packagemrb-publish/1.0RFCXXXX
Person and email address to contact for further information:
IETF, MEDIACTRL working group, (mediactrl@ietf.org),
Chris Boulton (chris@ns-technologies.com).
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]applicationmrb-publish+xmlnoneSame as charset parameter of application/xml as
specified in RFC 3023 .Same as encoding considerations of
application/xml as specified in RFC 3023 .See Section 10 of RFC 3023 and
of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].none. of
RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace XXXX with the RFC
number of this specification.]].This document type has
been used to support a Media Resource Broker (MRB) entity.None.xdf"TEXT"Chris
Boulton, chris@ns-technologies.comThe IETF.applicationmrb-consumer+xmlnoneSame as charset parameter of application/xml as
specified in RFC 3023 .Same as encoding considerations of
application/xml as specified in RFC 3023 .See Section 10 of RFC 3023 and
of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
XXXX with the RFC number of this specification.]].none. of
RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace XXXX with the RFC
number of this specification.]].This document type has
been used to support a Media Resource Broker (MRB) entity.None.xdf"TEXT"Chris
Boulton, chris@ns-technologies.comThe IETF.
Please register the URN name space "urn:ietf:params:xml:ns:mrb-publish", with the ID of "mrb-publish". The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-publish" is .
Please register the URN name space "urn:ietf:params:xml:ns:mrb-consumer", with the ID of "mrb-consumer". The schema of the XML namespace named
urn:ietf:params:xml:ns:mrb-consumer" is in .
Please register the schema for mrb-publish:urn:ietf:params:xml:ns:mrb-publishmrb-publishmrb-publishIETF, MEDIACTRL working group (mediactrl@ietf.org)The XML for the schema is in of this document.Please register the schema for mrb-consumer:urn:ietf:params:xml:ns:mrb-consumermrb-consumermrb-consumerIETF, MEDIACTRL working group (mediactrl@ietf.org)The XML for the schema is in of this document.Note to RFC Editor: Please remove this whole section.Editorial changes as a result of Shepherd review.Added new attribute 'id' to both <mediaResourceRequest> and <mediaResourceResponse> elements in the consumer schema, in order to map a response to a specific request.Renamed 'supported-actions' to 'supported-action' in the Publisher schema.Removed 'support' attribute from both the <vxml-support> element (Publisher schema) and the <vxml> element (Consumer schema): now an empty element means no VXML support is provided/requested.Clarified the scope of the 'application-data' element, and changed its type from xsd:NMTOKEN to xsd:string in the schema.Clarified the use of the <subscription> element in an <mrbresponse.Clarified the meaning of TCP CONNECTION in sequence diagrams.Removed useless backslashes from XML examples.Updated references for Framework and IVR drafts (RFC6230, RFC6231).Language changes as a result of Shepherd review.Fixed Nits.Added range for reporting period - as per mailing list.Corrected some errors in the Consumer schema: a few elements were not declared
optional as they should have been, and some were incorrectly defined as
choices instead of sequences;Corrected examples after validation tests;Fixed a few typos in the text.Clarified language in various places.Added 'Multi-modal MRB Implementations' section.Added 'Relative Merits of Query Mode, IAMM, and IUMM' section.Clarifying text related to IAMM and IUMM.Expanded media-server-address for extra information and to allow multiples.New B2BUA section.Updated Examples.Added the missing <encoding> and <decoding> elements to the <rtp-codec> instances, where needed.Fixed a few typos in the text.Clarifier that video layouts may refer to either XCON-defined layouts or others.Added RFC4240 as an option for VXML support.Fixed a few typos in the text and in the schemas.Corrected some typos and leftovers in both 'session-info' and
'response-session-info' definitions.Clarified that 'response-session-info' is not only included
in reply to updates, but also to new requests; besides, clarified
that it is an optional element, in the sense that it is mandatory
in successful responses (200), while not needed otherwise (any
error).Corrected the Query example flow which included a 'session'info'
in a new request.Addressed comments per the Expert RAI Review by Ben Campbell.Several editorial changes (fixes, typos, nits).Removed the 3xx class responses for the IAMM, per discussion in Anaheim (feature had been added in the -02 version).Clarified that backslashes and XML indentation in the Examples are only provided for readability.Clarified the distinction between 'deactivated' and 'unavailable'.Added text to the status codes in both Publish and Consumer responses, in order to clarify when they are involved.Added some text to better clarify the role of leasing in the Consumer interface.Added additional IANA considerations, that were missing in the previous versions of the document.Added text to the security considerations.Added examples in .Fixed some nits in the schemas (encryption and required mixed=true elements).Completed review nit review comments from Gary Munson.Added description of lease mechanism.Added specific HTTP and SIP usage of Consumer interface.Completed Publish interface schema + associated text.Included Consumer interface schema + associated text.Included supported-packages element.Removed announce-var element from doc.Expanded Abstract.General scrub of text - input from Simon Romano.Added IANA Considerations section.Added Security Considerations section.Included In-line text based on strawman proposal.Included first attempt at publish interface based on design team work.The authors would like to thank the members of the Publish Interface design team who provided valuable
input into this document. The design team consisted of Adnan Saleem, Michael Trank,
Victor Paulsamy, Martin Dolly, and Scott McGlashan. The authors would also like to thank John Dally,
Bob Epley, Simon Romano, Henry Lum, Christian Groves and Jonathan Lennox for input into this specification.Ben Campbell carried out the RAI expert review on this specification
and provided a great deal of invaluable input.Call Bearer Control (CBC) ProtocolInternational Telecommunication Union - Telecommunication Standardization BureauCodes for the representation of names of countries and their subdivisions - Part 1: Country codesInternational Organization for Standardization