idnits 2.17.1 draft-saleem-mediactrl-msml-package-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5707], [RFC6230]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 110: '... 8 of [RFC6230] that MUST be specified in the definition of a new...' RFC 2119 keyword, line 112: '...sequent sections MUST be functionality...' RFC 2119 keyword, line 114: '... and functions of this package MUST be...' RFC 2119 keyword, line 127: '... [RFC5707] had originally started with version 1.0, this package MUST...' RFC 2119 keyword, line 168: '... MUST be supported. This XML schema ...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '6230' on line 134 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Saleem 2 Internet Draft S. Dunn 3 Intended status: Informational Radisys 4 Expires: January 2015 July 4, 2014 6 MSML Package for the Media Control Channel Framework 7 draft-saleem-mediactrl-msml-package-04.txt 9 Abstract 11 The Media Server Markup Language [RFC5707] is used to control and 12 invoke many different types of services on IP media servers. MSML can 13 be used, for example, to control media server conferencing features 14 such as video layout and audio mixing, create sidebar conferences or 15 personal mixes, and set the properties of media streams. As well, 16 clients can use MSML to define media processing dialogs, which may be 17 used as parts of application interactions with users or conferences. 18 This document describes the use of MSML [RFC5707] language used 19 within the context of Media Control Channel Framework [RFC6230]. The 20 use of MSML [RFC5707] is described here as a standalone package for 21 use within and compliant with the Media Control Channel Framework 22 [RFC6230]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute working 31 documents as Internet-Drafts. The list of current Internet-Drafts is 32 at http://datatracker.ietf.org/drafts/current. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2015. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Control Package Definition.....................................3 60 2.1. Control Package Name......................................3 61 2.2. Framework Message Usage...................................3 62 2.3. Common XML Support........................................4 63 2.4. CONTROL Message Body......................................4 64 2.5. REPORT Message Body.......................................5 65 2.6. Audit.....................................................5 66 2.7. Examples..................................................6 67 2.7.1. Audio Conference with Active Speaker Notification....6 68 3. Element Definitions............................................7 69 4. Formal Syntax..................................................7 70 5. Security Considerations........................................8 71 6. IANA Considerations............................................8 72 6.1. Control Package Registration..............................8 73 6.2. URN Sub-Namespace Registration............................8 74 6.3. XML Schema Registration...................................8 75 7. References.....................................................8 76 7.1. Normative References......................................8 77 7.2. Informative References....................................9 78 8. Acknowledgments................................................9 80 1. Introduction 82 The architectural framework for media server control is described in 83 [RFC5567] and forms the basis for Media Control Channel Framework 84 [RFC6230]. In this framework, SIP is used by application servers to 85 both terminate media streams on media servers and to create and 86 manage media server control channels between themselves and media 87 servers. 89 The SIP based control channel framework is described in [RFC6230]. It 90 describes the establishment (via SDP negotiation), use, and 91 termination of a reliable transport (TCP) connection between 92 application server and media server for transport of media server 93 control messages. The "COMEDIA" specification [RFC4145] for setting 94 up and maintaining reliable connections is used as part of the 95 negotiation mechanism. 97 Control packages define a set of request, response, and notification 98 messages that can be sent over a SIP control channel for managing 99 services on a media server. The set of control packages supported by 100 both the application server and the media server is negotiated as 101 part of the control channel set up. 103 This document extends the Media Control Channel Framework [RFC6230] 104 by defining the MSML Package referred to in Section 3.2 of Media 105 Server Markup Language [RFC5707]. 107 2. Control Package Definition 109 This section fulfills the mandatory requirements detailed in Section 110 8 of [RFC6230] that MUST be specified in the definition of a new 111 Control Framework Package. The Control Framework Package described in 112 the subsequent sections MUST be functionality compliant with Media 113 Server Markup Language, as described in detail in [RFC5707]. The XML 114 schema and all features and functions of this package MUST be 115 compliant to [RFC5707]. 117 2.1. Control Package Name 119 The Control Framework requires a Control Package to specify and 120 register a unique name with IANA. 122 The name of this Control Package is "msml/1.1" (Media Server Markup 123 Language [RFC5707], version 1.1). The IANA registration of this 124 package name is specified in section 7. 126 Due to historic legacy versions of MSML IETF drafts leading up to 127 [RFC5707] had originally started with version 1.0, this package MUST 128 be compliant to [RFC5707] which is associated with version 1.1 of the 129 Media Server Markup Language. 131 2.2. Framework Message Usage 133 This section details the Framework messages that can be used over the 134 established Media Control Framework channel as per [6230]. 136 The MSML Package supports the CONTROL method for a Control Client to 137 send a request, response, or event message and the REPORT method for 138 a Control Server to send updates and final responses. 140 The message bodies shall consist of MIME media types. The messages 141 consist of XML encoded elements and attributes for requests, 142 responses, and event notifications as defined in [RFC5707] and are 143 contained within the root element . 145 This package defines a client server interface where the media server 146 acts as the server and typically application servers (or other 147 network elements such as SIP endpoints) act as the clients. The 148 client server interface defined by this package allows for many to 149 one relationship between the clients and the media server. 150 Additionally, this package also allows the media server to act as a 151 client for certain transactions which require unsolicited event 152 notifications, eg: DTMF digits or announcement play complete events, 153 etc, to application servers. 155 The scope of the package is defined in [RFC5707] which covers a wide 156 variety of applications including, multimedia announcements, 157 IVR/IVVR, multimedia conferencing, and numerous other services 158 supported by this package where ever media plane processing is 159 required. 161 All transaction types defined by this package are independent of the 162 transactions of the Media Control Framework itself, and are defined 163 within [RFC5707]. 165 2.3. Common XML Support 167 This package requires that the XML schema as defined in [RFC5707] 168 MUST be supported. This XML schema defines all transactions from 169 Clients to Media Server as well as event notifications from Media 170 Server to Clients. 172 2.4. CONTROL Message Body 174 The Media Control Framework requires a Control Package to define the 175 control body that can be contained within a CONTROL command request 176 and to indicate the location of detailed syntax definitions and 177 semantics for the appropriate body types. 179 This package defines the Control message bodies with the MIME media 180 type with XML encoded root element of , as defined within 181 [RFC5707]. All other XML encoded requests are contained with the 182 root element, such as or etc. 183 The application server can include any child elements of in 184 the CONTROL messages and MUST NOT include or 185 elements. 187 The 200 response to a CONTROL message from the media server MUST 188 include only the element 190 Media servers supporting this package MUST also support event 191 notifications, as defined in [RFC5707], originated by the media 192 server and contained within the CONTROL message. These event 193 notifications are also MIME media type using XML encoding as defined 194 they schema definition in [RFC5707]. 196 The media server MUST only include the child elements in a 197 CONTROL message and the 200 response to a CONTROL message from the 198 application server SHOULD have a zero length empty body. 200 2.5. REPORT Message Body 202 The Media Control Framework requires a Control Package definition to 203 define the REPORT body that MAY be contained within a REPORT command 204 request. 206 This package defines the use of REPORT message which MUST comply with 207 the XML schema defined in [RFC5707]. The REPORT message MUST contain 208 a single element containing child elements as defined by the 209 XML schema. 211 The REPORT messages defined by this package MAY include any valid XML 212 elements that can be in a 200 response to a CONTROL message as 213 described in earlier section. 215 A 200 response to a REPORT message SHOULD have a zero length empty 216 body. 218 2.6. Audit 220 This package MUST support the Audit request carried within the 221 CONTROL message and the associated Audit response carried in the 200 222 response to the CONTROL message. 224 The Audit response alternately MAY be sent or carried within the 225 REPORT message. 227 The Audit requests and responses MUST be XML encoded as specified in 228 [RFC5707]. The element contained within the root 229 element defines the audit request and subsequently the audit response 230 generated by the media server is XML encoded as defined in [RFC5707]. 232 2.7. Examples 234 This section provides examples of using the MSML Control Package. The 235 examples assume a Media Control channel has been established and 236 synced between application server (AS) and media server (MS) as per 237 [RFC6230]. 239 Additional examples of using MSML XML elements for conferencing, 240 media processing dialogs, and auditing are provided in [RFC5707] 242 2.7.1. Audio Conference with Active Speaker Notification 244 An audio conference is created with a request for Active Speaker 245 Notifications (ASN). A caller is joined to the conference. An ASN 246 event is sent to the application server. 248 1. AS -> MS (Control Framework Message): CONTROL. 250 - create conference and join participant 252 CFW i387yeiqyiq CONTROL 253 Control-Package: msml/1.1 254 Content-Type: application/msml+xml 255 Content-Length: 202 257 258 260 262 263 264 265 266 268 269 270 271 272 273 275 2. MS -> AS (Control Framework Message): 200. 277 CFW i387yeiqyiq 200 278 Content-Type: application/msml+xml 279 Content-Length: 60 281 282 283 284 286 3. MS -> AS (Control Framework Message): CONTROL. 288 - Active speaker event 290 CFW abcdefghi CONTROL 291 Control-Package: msml/1.1 292 Content-Type: application/msml+xml 293 Content-Length: 101 295 296 298 speaker 299 conn:10.29.162.235060+1+52030002+12ebfaa0 300 301 303 4. AS -> MS (Control Framework Message): 200. 305 CFW abcdefghi 200 307 3. Element Definitions 309 The XML elements for the MSML Package are described fully in 310 [RFC5707]. 312 4. Formal Syntax 314 The XML Schema for the MSML Package is described in [RFC5707]. 316 5. Security Considerations 318 The security measures employed by the Channel Framework are described 319 in [RFC6230]. 321 Additional security considerations for MSML are described in 322 [RFC5707]. 324 6. IANA Considerations 326 6.1. Control Package Registration 328 This section registers a new Media Control Channel Framework package 329 as per the instructions in section 13.1 of [RFC6230]. 331 Package Name: msml/1.1 333 Published Specification: RFC 5707 335 Internet-Draft: MSML Package for the Media Control Channel 336 Framework [draft-saleem-mediactrl-msml-package-01.txt] 338 Person & email address to contact for further information: 340 Adnan Saleem 342 6.2. URN Sub-Namespace Registration 344 The URN Sub-Namespace Registration for the MSML Package of Media 345 Control Channel is defined in section 18.3 of [RFC5707]. 347 6.3. XML Schema Registration 349 The XML Schema Registration for the MSML Package of Media Control 350 Channel is defined in section 18.4 of [RFC5707]. 352 7. References 354 7.1. Normative References 356 [RFC5707] Saleem, A., Xin, Y., Sharratt, G., "Media Server Markup 357 Language", RFC 5707, February 2010 359 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 360 Control Channel Framework", RFC 6230, May 2011 362 7.2. Informative References 364 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 365 Session Description Protocol (SDP)", RFC 4145, September 366 2005. 368 [RFC5567] Melanchuk, T., "An Architectural Framework for Media Server 369 Control", RFC 5567, June 2009. 371 8. Acknowledgments 373 This document was generated from initial inputs from Media Server 374 Markup Language [RFC5707] and contributors to this RFC. Additional 375 thanks for inputs and ideas on MSML MediaCtrl Package definition from 376 Yong Xin, co-author of [RFC5707]. 378 Authors' Addresses 380 Adnan Saleem 381 Radisys 382 4190 Still Creek Drive, Suite 300 383 Burnaby, BC, V5C 6C6 384 Canada 385 Email : adnan.saleem@radisys.com 387 Steve Dunn 388 Radisys 389 4190 Still Creek Drive, Suite 300 390 Burnaby, BC, V5C 6C6 391 Canada 392 Email : stephen.dunn@radisys.com