idnits 2.17.1 draft-even-media-server-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 439. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 7, 2006) is 6532 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-04) exists of draft-levin-xcon-cccp-00 == Outdated reference: A later version (-06) exists of draft-melanchuk-sipping-moml-03 == Outdated reference: A later version (-09) exists of draft-vandyke-mscml-05 == Outdated reference: A later version (-07) exists of draft-melanchuk-sipping-msml-03 == Outdated reference: A later version (-11) exists of draft-burger-sipping-netann-10 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON R. Even 3 Internet-Draft Polycom 4 Expires: December 9, 2006 June 7, 2006 6 Requirements for a media server control protocol 7 draft-even-media-server-req-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 9, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document addresses the communication between an application 41 server and media server. The current work in SIPPING and XCON 42 working groups show these logical functions but do not address the 43 physical decomposition and the protocol between the entities. 45 The document presents the architecture and the requirements from the 46 protocol. The document lists current work that is relevant to the 47 problem. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5. Current protocols . . . . . . . . . . . . . . . . . . . . . . 10 56 6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 58 8. Informative References . . . . . . . . . . . . . . . . . . . . 13 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 Intellectual Property and Copyright Statements . . . . . . . . . . 15 62 1. Introduction 64 The IETF SIPPING conferencing framework[CARCH] presents an 65 architecture that is built of several functional entities. The 66 framework document does not specify the protocols between the 67 functional entities since it is considered out of scope. 69 There is an interest to work on a protocol that will enable one 70 physical entity that includes the conference/media policy server, 71 notification server and the focus to interact with one or more 72 physical entities that serves as mixer or media server. 74 The document will present the requirements for such a protocol. It 75 will address all phases and aspects of media handling in a 76 conferencing service including announcements and IVR functionality. 78 2. Terminology 80 The Media Server work uses, when appropriate, and expands on the 81 terminology introduced in the SIPPING conferencing framework[CARCH]. 82 The following additional terms are defined for use within the Media 83 Server work. 85 Application Server (AS) - The application server includes the 86 conference policy server, the focus and the conference notification 87 server as defined in 88 draft-ietf-sipping-conferencing-framework.[CARCH] 90 Media Server (MS) - The media server includes the mixer as defined in 91 draft-ietf-sipping-conferencing-framework[CARCH] The media server 92 source media streams for announcements, it process media streams for 93 functions like DTMF detection and transcoding. The media server may 94 also record media streams for supporting IVR functions like 95 announcing participants. 97 3. Architecture 99 The proposed architecture is composed of an application server (AS) 100 and a media server (MS). 102 This section does not define any specific model for the interaction 103 between the AS and MS. It does assume that every interaction from 104 the participant to the MS will be controlled by the AS. The MS only 105 handles data and may tunnel controls received in the media streams to 106 the AS (e.g. DTMF). 108 The assumption is that the external protocols to these entities will 109 be based on the IETF work. The Conference aware participants will 110 use XCON protocols to the AS. The signaling protocol between the 111 Participants and the AS will be SIP. The media between the 112 Participants and the MS will be RTP based. The solution may work for 113 other signaling protocols like H.323. 115 The MS functionality includes: 117 - Control of the RTP streams. 119 - Mixing of incoming media streams. 121 - Media stream source (for multimedia announcements). 123 - Media stream processing (e.g. transcoding, DTMF detection). 125 - Media stream sink ( Support announcing participants names) 127 The AS functionality includes: 129 - Creation and management of conferences by conference aware 130 participants. 132 - Creation of conference service logic using other mechanism which 133 may be standard or non-standard. Example is to create an IVR based 134 conference service. 136 - Manage the conference flow in the MS from start to finish. 138 The following diagram describes the architecture. The purpose of the 139 work is to address the AS-MS protocol. 141 _____________ 142 XCON Protocol | Application | 143 +---------------------------| Server | 144 | |_____________| 145 | | | 146 | | | 147 | | | 148 _____________ _______ SIP | | 149 | | SIP | |---------+ |AS-MS 150 | Participant |---------| SIP | |Protocol 151 |_____________| | Proxy | | 152 |_______|----------+ | 153 SIP | | 154 | | 155 ________ 156 | | 157 | Media | 158 | Server | 159 |________| 161 4. Requirements 163 This section addresses only the requirements. The requirements will 164 be divided to general protocol requirements and to specific service 165 logic requirements. 167 General protocol 169 1. The Media server control messages shall be sent over a reliable 170 connection. 172 2. The protocol shall enable one AS to work with multiple MS. 174 3. The protocol should enable many AS to work with the same MS 176 4. The AS should be able to find the MS and connect to it. 178 5. The MS shall be able to inform the AS about it status. 180 6. The protocol should be extendable. 182 7. The MS shall be able to tell the AS its capacities. 184 8. The MS shall be able to tell the AS its functionality (Mixing, 185 IVR, Announcements) 187 9. The AS shall be able to request the MS to create, delete, and 188 manipulate a mixing, IVR or announcement session 190 10. The MS shall supply the media addresses (RTP transport address) 191 to be used to the AS. 193 11. The MS should send a summary report when the session is 194 terminated by the AS. 196 12. The AS should be able to request call/session and conference 197 state from the MS. 199 13. The MS should support DTMF detection (in band tones and RFC2833) 201 14. The protocol shall include redundancy procedures. 203 15. The protocol shall include security mechanisms. 205 16. The AS should be able to reserve resources on the MS. The 206 resources models should be simple. (this requirement needs more 207 discussion) 208 17. The MS may support resource reservation and shall report the 209 support in the initial connection to the AS. 211 18. The MS shall inform the AS about any changes in it capacities. 212 The changes may be due to reservation, internal usage or due to some 213 malfunction. 215 19. The AS shall be able to tell the MS which stream parameters to 216 use on incoming and out going streams. Stream parameters may be for 217 example codec parameters (video codec features) or bit rates. This 218 requirement will help the MS to allocate the right resources. 220 20. The AS shall be able to define operations that the MS will 221 perform on streams like mute and gain control. 223 21. The MS shall supply the AS with sufficient information for the 224 event package. 226 Announcements 228 Announcements may include voice, audio, slides or video clips. 230 1. The AS shall be able to instruct the MS to play a specific 231 announcement. 233 2. The MS shall be able to retrieve announcements from an external 234 connection. 236 3. The AS shall be able to tell the MS if the message can be delayed 237 if the MS cannot play it immediately. 239 4. The AS shall be able to instruct the MS to play announcements to 240 a single user or to a conference mix. 242 Media mixing 244 1. The AS shall be able to define a conference mix. 246 2. The AS may be able to define a separate mix for each participant. 248 3. The AS shall be able to define the relationship between two 249 mixes, for example a pair of audio and video for lip-synch or for 250 voice activated video switch 252 4. The AS may be able to define a custom video layout built of 253 rectangular sub windows. 255 5. For video the AS shall be able to map a stream to a specific sub- 256 window or to define to the MS how to decide which stream will go to 257 each sub window. The number of sub-windows will start from one. 259 6. The MS shall be able to inform the AS who is the active speaker. 261 7. The AS may be able to cascade mixers ( side bar with whisper 262 mode) 264 8. The MS shall be able to inform the AS which layouts it supports. 266 IVR 268 1. The AS shall be able to load an IVR script to the MS and receive 269 the result 271 2. The AS shall be able to mange the IVR session by sending 272 announcements and receiving the response (DTMF) 274 3. The AS should be able to instruct the MS to record a short 275 participant stream and play it back to the conference. This is not a 276 recording requirement. 278 5. Current protocols 280 Currently there are a few protocols that try to address this 281 architecture. The IETF drafts and ITU standards include: 283 1. draft-vandyke-mscml-05 [MSCML] 285 2. draft-melanchuk-sipping-msml-03[MSML] 287 3. draft-melanchuk-sipping-moml-03[MOML] 289 4. draft-burger-sipping-netann-10[NETANN] 291 5. draft-levin-xcon-cccp-00[CCCP] 293 6. ITU H.248.19 - Decomposed multipoint control unit, audio, video 294 and data conferencing packages[ITU.H248.19] 296 Note: The list is to the best of my knowledge and the order is 297 meaningless 299 A short overview of the drafts based on my poor understanding is 300 given here please feel free to correct my mistakes. 302 MSML[MSML] 304 Convedia MSML (Media Sessions Mark-up Language)[MSML]. The latest 305 version added support for video. MSML addresses the relationships of 306 media streams MSML defines an XML schema that enables the AS to 307 create sessions on the MS. The draft outlines how to use SIP as a 308 transport for the XML schema by using SIP invite to create a control 309 session between the AS and the MS. Subsequent control messages 310 between the MS and AS will be done using INFO or INVITE. The control 311 connection is only used for the transporting the XML schema. 313 MSML supports several models for client interaction. When clients 314 use 3PCC to establish media sessions on behalf of end users, clients 315 will have a SIP dialog for each media session. MSML may be sent on 316 these dialogs. However the targets of MSML actions are not inferred 317 from the session associated with the SIP dialog. The targets of MSML 318 actions are always explicitly specified using identifiers previously 319 defined. 321 The signaling from the SIP users is going to the AS. The AS is using 322 3pcc (third party call control) procedures to direct the SIP 323 signaling messages to the MS. The SDP is used to open the media 324 channel between the user and the MS while the call control is handled 325 by the AS. This is how the users join a media session on the MS that 326 was established using the MSML schema. Convedia has a second 327 protocol called Media Objects Mark-up Language (MOML)[MOML] that can 328 be used to specify individual user dialog or media control commands. 330 MSCML[MSCML] 332 Brooktrout Technology has suggested MSCML, Media Server Control 333 Mark-up Language. This current version supports only audio. 335 The general functionality is similar to MSML. MSCML is using SIP 336 Invite and Info to send the communication between the AS and MS. 337 Like MSML it opens a control connection for the conference. The 338 difference is that MSCML messages sent in the control connection are 339 for the entire conference while if they are sent over the users 340 dialogs they apply to that user. 342 Netann[NETANN] 344 This protocol provides a simple way to initiate an announcement, IVR 345 or mixing session on the media server using the URI parameters. The 346 AS can create the session bur has less control on what is happening 347 during the session itself. 349 Centralized Conference Control Protocol (CCCP)[CCCP] 351 This document may be of interest since it suggests a transaction 352 protocol that can serve the AS to MS communication. The data schema 353 is based on the conference event package. 355 MEGACO / H.248[ITU.H248.19] 357 The H.248[ITU.H248.19] protocol opens a channel between a controller 358 and a device (these can be AS and MS in our implementations). In 359 this channel it sends command to the MS to create context and to open 360 connections (terminations) for the media channel. The specific 361 functionality is defined by packages that can be extended. The MS 362 connects to it AS when it starts up and notify the AS which packages 363 it supports and its capacities. The H.248 packages include also 364 support for announcement and IVR. 366 6. IANA consideration 368 None. 370 7. Security Considerations 372 The security section will be added later 374 8. Informative References 376 [CARCH] Rosenberg, J., "A Framework for Conferencing with the 377 Session Initiation Protocol", 378 draft-ietf-sipping-conferencing-framework-03 (work in 379 progress), October 2004. 381 [CCCP] Levin, O. and G. Kimchi, "Centralized Conference Control 382 Protocol (CCCP)", draft-levin-xcon-cccp-00 (work in 383 progress), October 2004. 385 [ITU.H248.19] 386 International Telecommunications Union, "Gateway control 387 protocol: Decomposed multipoint control unit, audio, video 388 and data conferencing packages", ITU-T Recommendation 389 H.248.19, March 2004. 391 [MOML] Sharratt, G. and T. Melanchuk, Ed., "Media Objects Markup 392 Language (MOML)", draft-melanchuk-sipping-moml-03 (work in 393 progress), August 2004. 395 [MSCML] Van Dyke, J. and Eric. Burger, Ed., "Media Server Control 396 Markup Language (MSCML) and Protocol", 397 draft-vandyke-mscml-05 (work in progress), October 2004. 399 [MSML] Sharratt, G. and T. Melanchuk, Ed., "Media Server Markup 400 Language (MSML)", draft-melanchuk-sipping-msml-03 (work in 401 progress), August 2004. 403 [NETANN] Van Dyke, J. and Eric. Burger, Ed., "Basic Network Media 404 Services with SIP", draft-burger-sipping-netann-10 (work 405 in progress), October 2004. 407 Author's Address 409 Roni Even 410 Polycom 411 94 Derech Em Hamoshavot 412 Petach Tikva 49130 413 Israel 415 Email: roni.even@polycom.co.il 417 Intellectual Property Statement 419 The IETF takes no position regarding the validity or scope of any 420 Intellectual Property Rights or other rights that might be claimed to 421 pertain to the implementation or use of the technology described in 422 this document or the extent to which any license under such rights 423 might or might not be available; nor does it represent that it has 424 made any independent effort to identify any such rights. Information 425 on the procedures with respect to rights in RFC documents can be 426 found in BCP 78 and BCP 79. 428 Copies of IPR disclosures made to the IETF Secretariat and any 429 assurances of licenses to be made available, or the result of an 430 attempt made to obtain a general license or permission for the use of 431 such proprietary rights by implementers or users of this 432 specification can be obtained from the IETF on-line IPR repository at 433 http://www.ietf.org/ipr. 435 The IETF invites any interested party to bring to its attention any 436 copyrights, patents or patent applications, or other proprietary 437 rights that may cover technology that may be required to implement 438 this standard. Please address the information to the IETF at 439 ietf-ipr@ietf.org. 441 Disclaimer of Validity 443 This document and the information contained herein are provided on an 444 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 445 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 446 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 447 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 448 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 449 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 451 Copyright Statement 453 Copyright (C) The Internet Society (2006). This document is subject 454 to the rights, licenses and restrictions contained in BCP 78, and 455 except as set forth therein, the authors retain all their rights. 457 Acknowledgment 459 Funding for the RFC Editor function is currently provided by the 460 Internet Society.