draft-ietf-mediactrl-mrb-16.txt   draft-ietf-mediactrl-mrb-17.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: May 4, 2013 Meetecho Expires: August 8, 2013 Meetecho
G. Munson G. Munson
AT&T AT&T
October 31, 2012 February 4, 2013
Media Resource Brokering Media Resource Brokering
draft-ietf-mediactrl-mrb-16 draft-ietf-mediactrl-mrb-17
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 May 4, 2013. This Internet-Draft will expire on August 8, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 28, line 43 skipping to change at page 28, line 43
'package' provides the name of the Media Control Channel Framework 'package' provides the name of the Media Control Channel Framework
package, compliant with the Section 13.1.1 of [RFC6230], in which package, compliant with the Section 13.1.1 of [RFC6230], in which
the specified codes are supported. the specified codes are supported.
5.1.5.15. <file-transfer-modes> 5.1.5.15. <file-transfer-modes>
The <file-transfer-modes> element allows the Media Server to specify The <file-transfer-modes> element allows the Media Server to specify
which scheme names are supported for transferring files to a Media which scheme names are supported for transferring files to a Media
Server for each Media Control Channel Framework package type. For Server for each Media Control Channel Framework package type. For
example, whether the Media Server supports fetching resources via example, whether the Media Server supports fetching resources via
HTTP, HTTS, NFS, RTSP etc protocols. The element MAY be present. HTTP, HTTPS, NFS etc protocols. The element MAY be present.
The <file-transfer-modes> element has no attributes. The <file-transfer-modes> element has no attributes.
The <file-transfer-modes> element has zero or more of the following The <file-transfer-modes> element has zero or more of the following
child element: child element:
<file-transfer-mode>: has two attributes, 'name' and 'package'. <file-transfer-mode>: has two attributes, 'name' and 'package'.
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", "RTSP", etc.): the can be used for file transfer (e.g., "HTTP", "HTTPS", NFS etc.):
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 Package would only mean the 'http' scheme makes sense to the
Media Server within the context of that package. Whether or not the Media Server within the context of that package. Whether or not the
Media Server can make use of HTTP to only fetch resources, or also to Media Server can make use of HTTP to only fetch resources, or also to
skipping to change at page 31, line 37 skipping to change at page 31, line 37
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 a single attribute.
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. MAY be present. If the element is present, then the Media Server
supports DTLS-SRTP [RFC5763].
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has zero or more of the following child The <encryption> element has zero or more of the following child
elements: elements:
<keying-mechanism>: has no attributes. The element provides the <keying-mechanism>: has no attributes. The element provides the
name of a keying mechanism the Media Server supports for name of a keying mechanism the Media Server supports for
encrypting RTP media streams. encrypting RTP media streams.
skipping to change at page 45, line 30 skipping to change at page 45, line 30
The <location> element has a single child element: The <location> element has a single child element:
<civicAddress>: Describes the civic address location of the <civicAddress>: Describes the civic address location of the
requested media server, whose representation refers to Section 4 requested media server, whose representation refers to Section 4
of RFC 5139 [RFC5139]. of RFC 5139 [RFC5139].
5.2.5.1.2.8. <encryption> 5.2.5.1.2.8. <encryption>
The <encryption> element allows a Consumer client to request support The <encryption> element allows a Consumer client to request support
for encrypting RTP media streams using RFC 3711 [RFC3711]. The for encrypting RTP media streams using RFC 3711 [RFC3711]. The
element MAY be present. element MAY be present. If the element is present, then the Media
Server supports DTLS-SRTP [RFC5763].
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has zero or more of the following child The <encryption> element has zero or more of the following child
elements: elements:
<keying-mechanism>: has no attributes. The element provides the <keying-mechanism>: has no attributes. The element provides the
name of a keying mechanism the Client requires for encrypting RTP name of a keying mechanism the Client requires for encrypting RTP
media streams. media streams.
skipping to change at page 46, line 36 skipping to change at page 46, line 37
provides the name of the Media Control Channel Framework package, provides the name of the Media Control Channel Framework package,
compliant with the Section 13.1.1 of [RFC6230], for which the time compliant with the Section 13.1.1 of [RFC6230], for which the time
period applies. period applies.
5.2.5.1.2.11. <file-transfer-modes> 5.2.5.1.2.11. <file-transfer-modes>
The <file-transfer-modes> element allows the Consumer client to The <file-transfer-modes> element allows the Consumer client to
specify which scheme names are required for file transfer to a Media specify which scheme names are required for file transfer to a Media
Server for each Media Control Channel Framework package type. For Server for each Media Control Channel Framework package type. For
example, does the Media Server support fetching media resources via example, does the Media Server support fetching media resources via
RTSP, HTTP, NFS, etc protocols. The element MAY be present. HTTP, HTTPS, NFS, etc protocols. The element MAY be present.
The <file-transfer-modes> element has no attributes. The <file-transfer-modes> element has no attributes.
The <file-transfer-modes> element has a single child element: The <file-transfer-modes> element has a single child element:
<file-transfer-mode>: has two attributes, 'name' and 'package'. <file-transfer-mode>: has two attributes, 'name' and 'package'.
The 'name' attribute provides the scheme name of the protocol The 'name' attribute provides the scheme name of the protocol
required for fetching resources: valid values are case insensitive required for fetching resources: valid values are case insensitive
scheme names (e.g., RTSP, HTTP, HTTPS, NFS, etc.). The 'package' scheme names (e.g. HTTP, HTTPS, NFS, etc.). 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 Section 13.1.1 of [RFC6230], for which package, compliant with the Section 13.1.1 of [RFC6230], for which
the scheme name applies. the scheme name applies.
The same considerations relating to file transfer and live streaming The same considerations relating to file transfer and live streaming
are explained further in Section 5.1.5.15, whcih apply here as well. are explained further in Section 5.1.5.15, whcih apply here as well.
5.2.5.1.3. <mixerInfo> element 5.2.5.1.3. <mixerInfo> element
The <mixerInfo> element provides information for general Consumer The <mixerInfo> element provides information for general Consumer
skipping to change at page 51, line 15 skipping to change at page 51, line 15
The contents of a <location> element has a single child element: The contents of a <location> element has a single child element:
<civicAddress>: Describes the civic address location of the <civicAddress>: Describes the civic address location of the
requested media server, whose representation refers to Section 4 requested media server, whose representation refers to Section 4
of RFC 5139 [RFC5139]. of RFC 5139 [RFC5139].
5.2.5.1.3.8. <encryption> 5.2.5.1.3.8. <encryption>
The <encryption> element allows a Consumer client to request support The <encryption> element allows a Consumer client to request support
for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. The for encrypting mixed RTP media streams using RFC 3711 [RFC3711]. The
element MAY be present. element MAY be present. If the element is present, then the Media
Server supports DTLS-SRTP [RFC5763].
The <encryption> element has no attributes. The <encryption> element has no attributes.
The <encryption> element has zero or more of the following child The <encryption> element has zero or more of the following child
elements: elements:
<keying-mechanism>: has no attributes. The element provides the <keying-mechanism>: has no attributes. The element provides the
name of a keying mechanism the Consumer client requires for name of a keying mechanism the Consumer client requires for
encrypting mixed RTP media streams. encrypting mixed RTP media streams.
skipping to change at page 65, line 25 skipping to change at page 65, line 25
<A6>Via Claudio</A6> <A6>Via Claudio</A6>
<HNO>21</HNO> <HNO>21</HNO>
<LMK>University of Napoli Federico II</LMK> <LMK>University of Napoli Federico II</LMK>
<NAM>Dipartimento di Informatica e Sistemistica</NAM> <NAM>Dipartimento di Informatica e Sistemistica</NAM>
<PC>80210</PC> <PC>80210</PC>
</civicAddress> </civicAddress>
</media-server-location> </media-server-location>
<label>TestbedPrototype-01</label> <label>TestbedPrototype-01</label>
<media-server-address>sip:MS1@ms.example.net</media-server-address> <media-server-address>sip:MS1@ms.example.net</media-server-address>
<encryption> <encryption>
<keying-mechanism>SDES-SRTP</keying-mechanism> <keying-mechanism>DTLS-SRTP</keying-mechanism>
</encryption> </encryption>
</mrbnotification> </mrbnotification>
</mrbpublish> </mrbpublish>
B2. MRB -> MS (200 to CONTROL) B2. MRB -> MS (200 to CONTROL)
------------------------------ ------------------------------
CFW 03fff52e7b7a 200 CFW 03fff52e7b7a 200
9.2. Consumer Example 9.2. Consumer Example
skipping to change at page 141, line 6 skipping to change at page 141, line 6
UPDATE Method", RFC 3311, October 2002. UPDATE Method", RFC 3311, October 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[W3C.CR-wsdl20-20051215] [W3C.CR-wsdl20-20051215]
Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana,
"Web Services Description Language (WSDL) Version 2.0 Part "Web Services Description Language (WSDL) Version 2.0 Part
1: Core Language", W3C CR CR-wsdl20-20051215, 1: Core Language", W3C CR CR-wsdl20-20051215,
December 2005. December 2005.
[W3C.REC-soap12-part1-20030624] [W3C.REC-soap12-part1-20030624]
Gudgin, M., Mendelsohn, N., Moreau, J., Nielsen, H., and Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and
M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework",
World Wide Web Consortium FirstEdition REC-soap12-part1- World Wide Web Consortium FirstEdition REC-soap12-part1-
20030624, June 2003, 20030624, June 2003,
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624>. <http://www.w3.org/TR/2003/REC-soap12-part1-20030624>.
[W3C.REC-soap12-part2-20030624] [W3C.REC-soap12-part2-20030624]
Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H. Hadley, M., Mendelsohn, N., Gudgin, M., Moreau, J., and H.
Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide Nielsen, "SOAP Version 1.2 Part 2: Adjuncts", World Wide
Web Consortium FirstEdition REC-soap12-part2-20030624, Web Consortium FirstEdition REC-soap12-part2-20030624,
June 2003, June 2003,
 End of changes. 15 change blocks. 
15 lines changed or deleted 23 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/