draft-ietf-mediactrl-mrb-18.txt   draft-ietf-mediactrl-mrb-19.txt 
Network Working Group C. Boulton Network Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: Standards Track L. Miniero Intended status: Standards Track L. Miniero
Expires: August 9, 2013 Meetecho Expires: August 22, 2013 Meetecho
G. Munson G. Munson
AT&T AT&T
February 5, 2013 February 18, 2013
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-18 draft-ietf-mediactrl-mrb-19
Abstract Abstract
The MediaCtrl work group in the IETF has proposed an architecture for The MediaCtrl work group in the IETF has proposed an architecture for
controlling media services. The Session Initiation Protocol (SIP) is controlling media services. The Session Initiation Protocol (SIP) is
used as the signalling protocol which provides many inherent used as the signalling protocol which provides many inherent
capabilities for message routing. In addition to such signalling capabilities for message routing. In addition to such signalling
properties, a need exists for intelligent, application level media properties, a need exists for intelligent, application level media
service selection based on non-static signalling properties. This is service selection based on non-static signalling properties. This is
especially true when considered in conjunction with deployment especially true when considered in conjunction with deployment
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 9, 2013. This Internet-Draft will expire on August 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 16, line 50 skipping to change at page 16, line 50
Control Channel package defined in Section 5.1. The formal XML Control Channel package defined in Section 5.1. The formal XML
schema definition for the Publish interface can be found in schema definition for the Publish interface can be found in
Section 10. Section 10.
The root element is <mrbpublish>. All other XML elements (requests, The root element is <mrbpublish>. All other XML elements (requests,
responses, notifications) are contained within it. The MRB Publish responses, notifications) are contained within it. The MRB Publish
interface request element is detailed in Section 5.1.3. The MRB interface request element is detailed in Section 5.1.3. The MRB
Publish interface notification element is detailed in Section 5.1.5. Publish interface notification element is detailed in Section 5.1.5.
MRB Publish interface response element is contained in Section 5.1.4. MRB Publish interface response element is contained in Section 5.1.4.
The <mrbpublish> element has zero or more of the following The <mrbpublish> element has the following attributes:
attributes:
version: a token specifying the mrb-publish package version. The version: a token specifying the mrb-publish package version. The
value is fixed as '1.0' for this version of the package. The value is fixed as '1.0' for this version of the package. The
attribute MUST be present. attribute MUST be present.
The <mrbpublish> element has the following child elements, only one The <mrbpublish> element has the following child elements, and there
of which is allowed to occur in a request. MUST NOT be more than one such child element in any <mrbpublish>
message:
<mrbrequest> for sending an MRB request. See Section 5.1.3. <mrbrequest> for sending an MRB request. See Section 5.1.3.
<mrbresponse> for sending an MRB response. See Section 5.1.4. <mrbresponse> for sending an MRB response. See Section 5.1.4.
<mrbnotification> for sending an MRB notification. See <mrbnotification> for sending an MRB notification. See
Section 5.1.5. Section 5.1.5.
5.1.3. <mrbrequest> 5.1.3. <mrbrequest>
This section defines the <mrbrequest> element used to initiate This section defines the <mrbrequest> element used to initiate
requests from an MRB to a Media Server. The element describes requests from an MRB to a Media Server. The element describes
information relevant for the interrogation of a media server. information relevant for the interrogation of a media server.
The <mrbrequest> element has no defined attributes. The <mrbrequest> element has no defined attributes.
The <mrbrequest> element has zero or more of the following child The <mrbrequest> element has the following child elements:
elements:
<subscription> for initiating a subscription to a Media Server <subscription> for initiating a subscription to a Media Server
from an MRB. See Section 5.1.3.1. from an MRB. See Section 5.1.3.1.
5.1.3.1. <subscription> 5.1.3.1. <subscription>
The <subscription> element is included in a request from an MRB to a The <subscription> element is included in a request from an MRB to a
Media Server to provide the details relating to the configuration of Media Server to provide the details relating to the configuration of
updates. This element can be used either to request a new updates (known as a subscription session). This element can be used
subscription or to update an existing one (e.g., to change the either to request a new subscription or to update an existing one
frequency of the updates), and to remove ongoing subscriptions as (e.g., to change the frequency of the updates), and to remove ongoing
well (e.g., to stop an indefinite update). The MRB will inform the subscriptions as well (e.g., to stop an indefinite update). The MRB
Media Server how long it wishes to receive updates for and the will inform the Media Server how long it wishes to receive updates
frequency that updates should be sent. Updates related to the for and the frequency that updates should be sent. Updates related
subscription are sent using the <mrbnotification> element. to the subscription are sent using the <mrbnotification> element.
The <subscription> element has the following attributes: The <subscription> element has the following attributes:
id: indicates a unique token representing the subscription session id: indicates a unique token representing the subscription session
between the MRB and the Media Server. The attribute MUST be between the MRB and the Media Server. The attribute MUST be
present. present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session id to identify a specific
subscription command. The first subscription MUST have 1 as subscription command. The first subscription MUST contain a non-
'seqnumber', and following subscriptions MUST increment by 1 the zero number 'seqnumber', and following subscriptions MUST contain
previous 'seqnumber' value. The attribute MUST be present. a higher number that the previous 'seqnumber' value. If a
subsequent 'seqnumber' is not higher, a 405 response code is
generated as per section Section 5.1.4. The attribute MUST be
present.
action: provides the operation that should be carried out on the action: provides the operation that should be carried out on the
subscription: subscription:
* The value of 'create' instructs the Media Server to attempt to * The value of 'create' instructs the Media Server to attempt to
set-up a new subscription. set-up a new subscription.
* The value of 'update' instructs the Media Server to attempt to * The value of 'update' instructs the Media Server to attempt to
update an existing subscription. update an existing subscription.
skipping to change at page 19, line 40 skipping to change at page 19, line 40
| 400 | Syntax error | | 400 | Syntax error |
| | | | | |
| 401 | Unable to create Subscription | | 401 | Unable to create Subscription |
| | | | | |
| 402 | Unable to update Subscription | | 402 | Unable to update Subscription |
| | | | | |
| 403 | Unable to remove Subscription | | 403 | Unable to remove Subscription |
| | | | | |
| 404 | Subscription does not exist | | 404 | Subscription does not exist |
| | | | | |
| 405 | Subscription already exists | | 405 | Wrong sequence number |
| | |
| 406 | Subscription already exists |
| | | | | |
| 420 | Unsupported attribute or element | | 420 | Unsupported attribute or element |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Table 1: <mrbresponse> status codes Table 1: <mrbresponse> status codes
In case a new subscription request made by an MRB (action='create') In case a new subscription request made by an MRB (action='create')
has been accepted, the Media Server MUST reply with a <mrbresponse> has been accepted, the Media Server MUST reply with a <mrbresponse>
with status code 200. The same rule applies whenever a request to with status code 200. The same rule applies whenever a request to
update (action='update') or remove (action='remove') an existing update (action='update') or remove (action='remove') an existing
skipping to change at page 20, line 17 skipping to change at page 20, line 18
instead. Specifically, if the Media Server fails to handle a request instead. Specifically, if the Media Server fails to handle a request
due to a syntax error in the request itself (e.g., incorrect XML, 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 violation of the schema constraints or invalid values in any of the
attributes/elements) the Media Server MUST reply with a <mrbresponse> attributes/elements) the Media Server MUST reply with a <mrbresponse>
with status code 400. If a syntactically correct request fails with status code 400. If a syntactically correct request fails
because the request also includes any attribute/element the Media because the request also includes any attribute/element the Media
Server doesn't understand, the Media Server MUST reply with a Server doesn't understand, the Media Server MUST reply with a
<mrbresponse> with status code 420. If a syntactically correct <mrbresponse> with status code 420. If a syntactically correct
request fails because the MRB wants to create a new subscription, but request fails because the MRB wants to create a new subscription, but
the provided unique 'id' for the subscription already exists, the the provided unique 'id' for the subscription already exists, the
Media Server MUST reply with a <mrbresponse> with status code 405. Media Server MUST reply with a <mrbresponse> with status code 406.
If a syntactically correct request fails because the MRB wants to If a syntactically correct request fails because the MRB wants to
update/remove a subscription that doesn't exist, the Media Server update/remove a subscription that doesn't exist, the Media Server
MUST reply with a <mrbresponse> with status code 404. If the Media MUST reply with a <mrbresponse> with status code 404. If the Media
Server is unable to accept a request for any other reason (e.g., the Server is unable to accept a request for any other reason (e.g., the
MRB has no more resources to fulfil the request), the Media Server MRB has no more resources to fulfil the request), the Media Server
MUST reply with a <mrbresponse> with status code 401/402/403, MUST reply with a <mrbresponse> with status code 401/402/403,
depending on the action the MRB provided in its request: depending on the action the MRB provided in its request:
o action='create' --> 401; o action='create' --> 401;
o action='update' --> 402; o action='update' --> 402;
o action='remove' --> 403; o action='remove' --> 403;
A response to a subscription request that has a status of "200" A response to a subscription request that has a status of "200"
indicates that the request is successful. The response MAY also indicates that the request is successful. The response MAY also
contain a <subscription> child that describes the subscription. The contain a <subscription> child that describes the subscription. The
<subscription> child MAY contain 'expires', 'minfrequency' and <subscription> child MAY contain 'expires', 'minfrequency' and
'maxfrequency' values even if they were not contained in the request. 'maxfrequency' values even if they were not contained in the request.
The Media Server MAY change the suggested 'expires', 'minfrequency' The Media Server can choose to change the suggested 'expires',
and 'maxfrequency' values provided by the MRB in its <mrbrequest>, if 'minfrequency' and 'maxfrequency' values provided by the MRB in its
it considers them unacceptable (e.g., the requested frequency range <mrbrequest>, if it considers them unacceptable (e.g., the requested
is too high). In such a case, the response MUST contain a frequency range is too high). In such a case, the response MUST
<subscription> element describing the subscription as the Media contain a <subscription> element describing the subscription as the
Server accepted it, and the Media Server MUST include in the Media Server accepted it, and the Media Server MUST include in the
<subscription> element all of those values that it modified relative <subscription> element all of those values that it modified relative
to the request, to inform the MRB about the change. to the request, to inform the MRB about the change.
5.1.5. <mrbnotification> 5.1.5. <mrbnotification>
The <mrbnotification> element is included in a request from a Media The <mrbnotification> element is included in a request from a Media
Server to an MRB to provide the details relating current status. The 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 Media Server will inform the MRB of its current status as defined by
the information in the <subscription> element. Updates are sent the information in the <subscription> element. Updates are sent
using the <mrbnotification> element. using the <mrbnotification> element.
The <mrbnotification> element has the following attributes: The <mrbnotification> element has the following attributes:
id: indicates a unique token representing the session between the id: indicates a unique token representing the session between the
MRB and the Media Server and is the same as the one appearing in MRB and the Media Server and is the same as the one appearing in
the <subscription> element. The attribute MUST be present. the <subscription> element. The attribute MUST be present.
seqnumber: indicates a sequence number to be used in conjunction seqnumber: indicates a sequence number to be used in conjunction
with the subscription session id to identify a specific with the subscription session id to identify a specific
notification update. The first notification MUST have 1 as notification update. The first notification update MUST contain a
'seqnumber', and following notifications MUST increment by 1 the non-zero number 'seqnumber', and following notification updates
previous 'seqnumber' value. The attribute MUST be present. MUST contain a higher number that the previous 'seqnumber' value.
If a subsequent 'seqnumber' is not higher the situation should be
considered an error by the entity receiving the notification
update. It is implementation specific how the receiving entity
deals with this situation. The attribute MUST be present.
It's important to point out that the 'seqnumber' that appears in a It's important to point out that the 'seqnumber' that appears in a
<mrbnotification> is not related to the 'seqnumber' appearing in a <mrbnotification> is not related to the 'seqnumber' appearing in a
<mrbsubscription>. In fact, the latter is associated with <mrbsubscription>. In fact, the latter is associated with
subscriptions and would increase at every command issued by the MRB, subscriptions and would increase at every command issued by the MRB,
while the former is associated with the asynchronous notifications while the former is associated with the asynchronous notifications
the Media Server would trigger according to the subscription, and as the Media Server would trigger according to the subscription, and as
such would increase at every notification message to enable the MRB such would increase at every notification message to enable the MRB
keep track of them. keep track of them.
skipping to change at page 29, line 16 skipping to change at page 29, line 19
The 'name' attribute provides the scheme name of the protocol that The 'name' attribute provides the scheme name of the protocol that
can be used for file transfer (e.g., "HTTP", "HTTPS", NFS etc.): can be used for file transfer (e.g., "HTTP", "HTTPS", NFS etc.):
the value of the attribute is case insensitive. The 'package' the value of the attribute is case insensitive. The 'package'
attribute provides the name of the Media Control Channel Framework attribute provides the name of the Media Control Channel Framework
package, compliant with the specification in the related IANA package, compliant with the specification in the related IANA
registry (e.g., "msc-ivr/1.0"), for which the scheme name applies. registry (e.g., "msc-ivr/1.0"), for which the scheme name applies.
It is important to point out that this element provides no It is important to point out that this element provides no
information about whether or not the Media Server supports any information about whether or not the Media Server supports any
flavour of live streaming: for instance, a value of "HTTP" for the flavour of live streaming: for instance, a value of "HTTP" for the
IVR Package would only mean the 'http' scheme makes sense to the IVR (Interactive Voice Response) Package would only mean the 'http'
Media Server within the context of that package. Whether or not the scheme makes sense to the Media Server within the context of that
Media Server can make use of HTTP to only fetch resources, or also to package. Whether or not the Media Server can make use of HTTP to
attach an HTTP live stream to a call, is to be considered only fetch resources, or also to attach an HTTP live stream to a
implementation specific to the Media Server and irrelevant to the call, is to be considered implementation specific to the Media Server
Application Server and/or MRB. Besides, the Media Server supporting and irrelevant to the Application Server and/or MRB. Besides, the
a scheme does not imply it also supports the related secure versions: Media Server supporting a scheme does not imply it also supports the
for instance, if the Media Server supports both "HTTP" and "HTTPS", related secure versions: for instance, if the Media Server supports
both the schemes will appear in the element. A lack of the "HTTPS" both "HTTP" and "HTTPS", both the schemes will appear in the element.
value would need to be interpreted as a lack of support for the A lack of the "HTTPS" value would need to be interpreted as a lack of
'https' scheme. support for the 'https' scheme.
5.1.5.16. <asr-tts-support> 5.1.5.16. <asr-tts-support>
The <asr-tts-support> element provides information about the support The <asr-tts-support> element provides information about the support
for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS) for Automatic Speech Recognition (ASR) and Text-to-Speech (TTS)
functionality in a media server. The functionality are reported by functionality in a media server. The functionality are reported by
referring to the supported languages (using ISO-639-1 [ISO.639.1988] referring to the supported languages (using ISO-639-1 [ISO.639.1988]
codes) for what regards both ASR and TTS. The element MAY be codes) for what regards both ASR and TTS. The element MAY be
present. present.
skipping to change at page 31, line 29 skipping to change at page 31, line 29
The <label> element has no child elements. The <label> element has no child elements.
5.1.5.20. <media-server-address> 5.1.5.20. <media-server-address>
The <media-server-address> element allows a Media Server to provide a The <media-server-address> element allows a Media Server to provide a
direct SIP URI where it can be reached (e.g., the URI Application direct SIP URI where it can be reached (e.g., the URI Application
Server would call to in order to set-up a Control Channel and relay Server would call to in order to set-up a Control Channel and relay
SIP media dialogs). The element MAY be present. SIP media dialogs). The element MAY be present.
The <media-server-address> element has a single attribute. The <media-server-address> element has no attributes.
The <media-server-address> element has no child elements. The <media-server-address> element has no child elements.
5.1.5.21. <encryption> 5.1.5.21. <encryption>
The <encryption> element allows a Media Server to declare support for The <encryption> element allows a Media Server to declare support for
encrypting RTP media streams using RFC 3711 [RFC3711]. The element encrypting RTP media streams using RFC 3711 [RFC3711]. The element
MAY be present. If the element is present, then the Media Server MAY be present. If the element is present, then the Media Server
supports DTLS-SRTP [RFC5763]. supports DTLS-SRTP [RFC5763].
skipping to change at page 35, line 38 skipping to change at page 35, line 38
transactions may result in failure, the IAMM relies on a successful transactions may result in failure, the IAMM relies on a successful
INVITE transaction to address the previously discussed sequence INVITE transaction to address the previously discussed sequence
(using 'seq' XML element) increment mechanism. This means that, if (using 'seq' XML element) increment mechanism. This means that, if
the INVITE is unsuccessful for any reason, the Application Server the INVITE is unsuccessful for any reason, the Application Server
MUST use the same 'seq' value as previously used for the next MUST use the same 'seq' value as previously used for the next
Consumer request it may want to send to the MRB for the same session. Consumer request it may want to send to the MRB for the same session.
An MRB implementation may be programmed to conclude that the An MRB implementation may be programmed to conclude that the
requested resources are no longer needed when it receives a SIP BYE requested resources are no longer needed when it receives a SIP BYE
from the Application Server or Media Server that concludes the SIP from the Application Server or Media Server that concludes the SIP
dialog that initiated the request, or when the lease interval dialog that initiated the request, or when the lease(Section 5.2.3)
expires. interval expires.
5.2.2.2. IAMM and Setting up a Media Dialog 5.2.2.2. IAMM and Setting up a Media Dialog
This scenario is identical to the description in the previous section This scenario is identical to the description in the previous section
for setting up a Control Framework control channel with the exception for setting up a Control Framework control channel with the exception
that the application/sdp payload conveys content appropriate for that the application/sdp payload conveys content appropriate for
setting up the media dialog to the media resource, as per RFC 3261 setting up the media dialog to the media resource, as per RFC 3261
[RFC3261], instead of application/sdp payload for setting up a [RFC3261], instead of application/sdp payload for setting up a
control channel. control channel.
 End of changes. 16 change blocks. 
45 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/