idnits 2.17.1 draft-mcglashan-mscp-02.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3384. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (July 31, 2006) is 6472 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) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-05) exists of draft-boulton-sip-control-framework-03 -- No information found for draft-ietf-sipping-conferencing-package - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. McGlashan 3 Internet-Draft Hewlett-Packard 4 Intended status: Standards Track R. Auburn 5 Expires: February 1, 2007 Voxeo 6 D. Burke 7 Voxpilot 8 E. Candell 9 Comverse 10 R. Surapaneni 11 Tellme Networks 12 July 31, 2006 14 Media Server Control Protocol (MSCP) 15 draft-mcglashan-mscp-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on February 1, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document specifies MSCP (Media Server Control Protocol), a 49 protocol to control interactive dialog and conferencing functions on 50 a media server. The protocol messages - requests, responses and 51 notifications - are modeled on dialog and conferencing elements 52 defined in CCXML (Voice Browser Call Control), and interactive 53 dialogs can be specified in VoiceXML (Voice Extensible Markup 54 Language). MSCP messages have self-contained XML representation and 55 transaction models, so the protocol is independent of the underlying 56 transport channel. Messages may be transported using SIP or, 57 preferably, using a dedicated transport channel. 59 Comments 61 Comments are solicited and should be addressed to the authors. 63 Comments already received on the -00/-01 versions will be addressed 64 in the next release of this draft and do not need to be resent. 66 Table of Contents 68 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.3.1. Connections, Dialogs and Conferences . . . . . . . . . 8 74 2.3.2. Interaction Model . . . . . . . . . . . . . . . . . . 9 75 2.4. Transport Channel . . . . . . . . . . . . . . . . . . . . 11 76 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 77 3.1. Transaction Models . . . . . . . . . . . . . . . . . . . . 12 78 3.2. XML Format and Container Elements . . . . . . . . . . . . 12 79 3.3. XML Processing and Extensibility . . . . . . . . . . . . . 13 80 4. Interactive Media Functionality . . . . . . . . . . . . . . . 15 81 4.1. Request-Response . . . . . . . . . . . . . 15 82 4.2. Request-Response . . . . . . . . . . . . . . 19 83 4.3. Notification . . . . . . . . . . . . . . 23 84 4.4. Notification . . . . . . . . . . . . . . . . 24 85 4.5. Notification . . . . . . . . . . . . . . . . 25 86 4.6. Notification . . . . . . . . . . . . . . . . 26 87 4.7. Notification . . . . . . . . . . . . . 27 88 4.8. Notification . . . . . . . . . . . . . . 28 89 4.8.1. Blind transfer . . . . . . . . . . . . . . . . . . . . 29 90 4.8.2. Bridge transfer . . . . . . . . . . . . . . . . . . . 30 91 4.9. Notification . . . . . . . . . . 32 92 4.10. Notification . . . . . . . . . . 33 93 5. Conferencing Functionality . . . . . . . . . . . . . . . . . . 34 94 5.1. Request-Response . . . . . . . . . . . 34 95 5.2. Request-Response . . . . . . . . . . . 37 96 5.3. Request-Response . . . . . . . . . . . . . . . . . 38 97 5.4. Request-Response . . . . . . . . . . . . . . . . 41 98 5.5. Notification . . . . . . . . . . . . . . 42 99 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 100 6.1. Interactive Media Dialogs . . . . . . . . . . . . . . . . 44 101 6.2. Basic Audio Conference . . . . . . . . . . . . . . . . . . 48 102 6.3. Manipulating Conference Participants . . . . . . . . . . . 51 103 6.4. Sidebar Conference . . . . . . . . . . . . . . . . . . . . 53 104 7. Transport Channel . . . . . . . . . . . . . . . . . . . . . . 56 105 7.1. SIP Transport Channel . . . . . . . . . . . . . . . . . . 56 106 7.2. TCP Transport Channel . . . . . . . . . . . . . . . . . . 56 107 7.2.1. Establishing the Transport Channel . . . . . . . . . . 57 108 7.2.2. Transport Channel PDU . . . . . . . . . . . . . . . . 58 109 7.2.3. Request . . . . . . . . . . . . . . . . . . . . . . . 59 110 7.2.4. Response . . . . . . . . . . . . . . . . . . . . . . . 59 111 7.2.5. Notification . . . . . . . . . . . . . . . . . . . . . 60 112 7.2.6. Example Exchange . . . . . . . . . . . . . . . . . . . 60 113 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 62 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 74 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 116 11. Change Summary . . . . . . . . . . . . . . . . . . . . . . . . 76 117 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77 118 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 119 13.1. Normative References . . . . . . . . . . . . . . . . . . . 78 120 13.2. Informative References . . . . . . . . . . . . . . . . . . 78 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 122 Intellectual Property and Copyright Statements . . . . . . . . . . 81 124 1. Conventions 126 In examples, "AS:" and "MS:" indicate protocol messages sent by the 127 application server and media server respectively. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. Introduction 135 This document specifies a protocol for an application server (AS) to 136 control interactive media and conferencing functions on a media 137 server (MS). The AS sends requests for functionality to the MS, and 138 the MS responds. Notifications may also be sent from the AS to the 139 MS, and vice versa. 141 The protocol messages are directly modeled on W3C CCXML 1.0 [CCXML10] 142 elements for interactive dialog and conferencing, but adapted for 143 over-the-wire transport. 145 The protocol uses request-response and notification transaction 146 models and the messages themselves are expressed as XML documents. 148 Protocol transactions are described independent of the transport 149 channel. 151 [Editors Note: The next version of MSCP will be synchronized with the 152 SIP Control Framework ([SIPCONTROLFRAMEWORK]). MSCP functionality 153 for IVR and conferencing will be characterized in terms of Framework 154 Control Packages. This is expected to have the following impact: 156 1. The TCP Transport Channel (Section 7.2) will be updated to the 157 dedicated TCP channel in the SIP Control Framework. 159 2. The Interactive Media Functionality (Section 4) will be updated 160 to the Basic IVR package ([BASIC_IVR_PACKAGE]) and VoiceXML IVR 161 package ([VXML_IVR_PACKAGE]). Functionality relating to VoiceXML 162 transfer will be part of a separate package (yet to be defined). 164 3. The Conferencing Functionality (Section 5) will be updated to the 165 Basic Conference Package ([BASIC_CONFERENCE_PACKAGE] and an 166 advanced Conferencing package (in development).] 168 2.1. Scope 170 The scope of the protocol is control of media server functions for 171 interactive media (e.g. play a prompt, interpret DTMF, etc) and 172 conferencing functions (e.g. create a conference, join participants 173 to conference, etc) as well as notifications related to these 174 functions. The protocol defines request-response and notification 175 messages in XML [XML] for these functions. 177 The protocol also provides extensibility mechanisms allowing messages 178 which are defined outside this document to be passed using the MSCP 179 protocol. The extensibility mechanisms MAY be used to pass messages 180 describing other functions; for example, functions such as: 182 o billing and charging 184 o server management 186 o resource availability and reservation 188 o media transcoding (note: this function may be implicit in media 189 server functionality; e.g. the media server may automatically 190 transcode media streams in conference) 192 While not in the scope of this protocol, these functions may be 193 encoded in the protocol using its extensibility mechanisms. The MS 194 is not required to support functions which are not in scope of this 195 protocol. 197 If a requested function is not supported by the MS, it MUST respond 198 with the appropriate error message. 200 ISSUE: A future version of this document may specify how media server 201 capabilities are made available (e.g. whether dialog, conferencing or 202 both are supported, as well as specific conference or dialog 203 capabilities - e.g. VoiceXML 2.1, speech recognition support, video 204 conferencing support, etc). 206 2.2. Terminology 208 Many of the basic concepts of the MSCP protocol are modeled on the 209 concepts described in CCXML, including dialog, connection, and 210 conference. 212 Dialog: A dialog performs media interaction with a user. A dialog 213 is specified by a dialog language, e.g. VoiceXML 2.0 [VXML20], 214 and is identified by a URI. Dialogs typically feature synthesized 215 speech, digitized audio and video, recognition of spoken and DTMF 216 key input, recording of audio and video input, and mixed 217 initiative conversations. 219 Connection: A connection refers to two or more independent 220 unidirectional media streams and its associated network signaling 221 traffic. For the purposes of this specification, a connection 222 consists of a SIP dialog and its associated multimedia session. 224 Conference: A conference is an instance of a multi-party 225 conversation. 227 Application server: A SIP [RFC3261] application server (AS) hosts 228 and executes services such as interactive media and conferencing 229 in an operator's network. An AS influences and impacts the SIP 230 session, in particular by terminating SIP sessions on a media 231 server, which is under its control. 233 Media Server: A media server (MS) processes media streams on behalf 234 of an AS by offering functionality such as interactive media, 235 conferencing, and transcoding to the end user. Interactive media 236 functionality is realized by way of dialogs, which are identified 237 by a URI and initiated by the application server. Conferencing 238 mixing [SIPCONF] functionality is controlled directly by the AS. 240 2.3. Architecture 242 Even though the MSCP protocol is modeled on a subset of CCXML 243 elements, the protocol is agnostic to the implementation of the AS 244 and MS. These may be implemented using CCXML and VoiceXML 245 interpreters, due to ease of authoring applications in XML. For 246 example, the AS is implemented as a CCXML interpreter and the MS is 247 implemented using a VoiceXML interpreter for dialog functions and a 248 conferencing interpreter for conferencing functions. 250 The MSCP protocol can be used between an AS and MS in a variety of 251 architectures; for example, in SIP architectures including IPCC and 252 3GPP IMS. In the IMS architecture, an incoming call arriving at the 253 CSCF is handled by a SIP AS. When media processing is required, the 254 AS interacts with a MRF MS to obtain media services. 256 For conferencing applications, the AS includes the conference focus, 257 conference policy server, and conference notification server 258 [SIPCONF]. The AS MAY support the SIP Event Package for Conference 259 State [SIPEVENTS]. The MS exposes mixer functionality under control 260 of the AS via the MSCP protocol. 262 For a CCXML AS, the conference policy is defined by the executing 263 CCXML application. A conference policy server may be implemented via 264 the CCXML Basic Event I/O Processor. The conference URI, which 265 uniquely identifies the focus of the conference, can be mapped by the 266 AS to a specific CCXML conferencing application. For example, 267 1234@as1.example.com might be mapped to 268 http://www.example.com/confapp01.ccxml. 270 2.3.1. Connections, Dialogs and Conferences 272 Connections, dialogs, and conferences have unique identifiers. Both 273 dialogs and conferences are assigned a unique ID by the MS in 274 response to a or request 275 respectively. 277 Connections, on the other hand, are assigned unique identifiers based 278 on the dialog ID of the SIP connection to the MS [RFC3261]. The MSCP 279 protocol represents the dialog ID as an ordered concatenation of the 280 Call-ID value, the From tag, and the To tag, delimited by a semi- 281 colon. For example, the connection id of a84b4c71@10.0.0.2;1923;1134 282 applies for the following SIP dialog: 284 ACK sip:ms@example.com SIP/2.0 285 Via: SIP/2.0/TCP as.example.com:5060; 286 branch=z9hG4bK776asdhds 287 Max-Forwards: 70 288 To: MS ;tag=1134 289 From: AS ;tag=1923 290 Call-ID: a84b4c71@10.0.0.2 291 CSeq: 314161 INVITE 292 Content-Length: 0 294 2.3.2. Interaction Model 296 The MSCP protocol itself does not require any particular client 297 interaction model except for the assumption that the interactions 298 between the client and the MS are controlled by the AS. 300 The remainder of this section describes a common client interaction 301 model with the AS and MS and may be considered informative. 303 The MSCP control channel is established between the AS and MS (see 304 Section 7). SIP clients typically interact with the MS via the AS. 305 For each connection from the UA being served with interactive media 306 or conferencing, a SIP dialog exist between the client and AS, and AS 307 and MS. 309 +-------------+ 310 | | 311 | Application | 312 | Server | 313 | (AS) | 314 SIP +-------------+ MSCP, SIP 315 / \ 316 +------------+ / \ +-------------+ 317 | |/ \| | 318 | SIP | | Media | 319 | UA | RTP | Server | 320 | |=====================| (MS) | 321 +------------+ +-------------+ 323 The AS employs third party call control (3PCC) procedures [RFC3725] 324 to direct the signaling between a SIP client and MS and to establish 325 media streams between the two. 327 Example 329 In this example, a SIP UA sends an INVITE the AS. The AS accepts the 330 connection (e.g. for a CCXML AS, this equates to executing ). 331 The answer contains "black hole" SDP, with its connection address 332 equal to 0.0.0.0. Some time later, the AS then decides to start a 333 dialog and bridge the SIP UA to it. The AS invokes the MS and client 334 and mediates the SDP offer/answer exchange resulting in an RTP stream 335 between the SIP UA and MS. Finally, the AS starts a VoiceXML dialog 336 via the MSCP protocol; the connectionid indicated in the 337 refers to the dialog ID of the SIP dialog between the 338 AS and MS. 340 SIP UA Application Server (AS) Media Server (MS) 341 | | | 342 |(1) INVITE offer1 | | 343 |--------------------->| | 344 |(2) 200 answer 1 (bh) | (accept connection) | 345 |<---------------------| | 346 |(3) ACK | | 347 |--------------------->| | 348 | | | 349 | (start dialog) |(4) INVITE no SDP | 350 | |--------------------->| 351 | |(5) 200 OK offer2 | 352 | |<---------------------| 353 |(6) INVITE offer2 | | 354 |<---------------------| | 355 |(7) 200 answer2 | | 356 |--------------------->| | 357 | |(8) ACK answer2 | 358 | |--------------------->| 359 |(9) ACK | | 360 |<---------------------| | 361 |(10) RTP | | 362 |.............................................| 363 | | (11) | 364 | |--------------------->| 365 | | (12) | 366 | |<---------------------| 367 | | | 369 2.4. Transport Channel 371 The MSCP protocol employs a self-contained XML representation for its 372 control messages, so it is independent of the underlying transport 373 channel. In principle, MSCP protocol messages could be transported 374 over any mechanism which respects the constraints described in this 375 document. 377 Within SIP-based architecture, SIP is employed for establishing and 378 managing the transport channel for the MSCP protocol. While SIP 379 itself is not an ideal transport channel for a control protocol, MSCP 380 messages MAY be transported over SIP. However, MSCP messages SHOULD 381 be transported over a dedicated transport channel. 383 The transport channel is described in more detail in Section 7. 385 3. Protocol Overview 387 The protocol uses two transaction models: a request-response model 388 and a notification model. Requests, responses and notification 389 messages are encoded as XML documents. 391 3.1. Transaction Models 393 In the request-response transaction model, the AS sends a request 394 message to the MS. The MS MUST send a response message as defined in 395 this document. 397 In the notification transaction model, a notification message can be 398 sent from the AS to the MS or from the MS to the AS. No response 399 message is required. 401 Note that the AS implicitly subscribes to notifications from a 402 dialog/conference when it creates the dialog/conference or joins a 403 connection to the dialog/conference. The AS may explicitly subscribe 404 to additional notifications from the dialog or conference by using 405 the element mechanism described in Section 4 and 406 Section 5. 408 3.2. XML Format and Container Elements 410 All MSCP protocol messages are encoded as XML documents. The content 411 type for MSCP XML documents is "application/mscp+xml". The character 412 encoding MUST be set to UTF-8. 414 The top-level container element in protocol message is which 415 MUST have a version attribute and MUST specify the MSCP namespace. 416 For this version of the protocol, the version attribute is set to the 417 value "1.0". The namespace for the MSCP XML elements is 418 urn:ietf:mscp. 420 For example, 422 423 ... 424 426 The content of the element MUST be exactly one of the 427 following elements: , or . 429 ISSUE: A future version of this document may specify how multiple 430 requests, responses or notifications are passed in a single 431 element. 433 Notification transactions are specified using the 434 element. No attributes are defined for this element. The content of 435 element is a notification element defined within the 436 MSCP namespace, or an element defined in another namespace. 438 Requests in a request-response transaction are specified using a 439 element and its corresponding response as . The 440 content of a is an element describing a request defined 441 within the MSCP namespace, or an element defined in another 442 namespace. Likewise, the content of a is an element 443 describing a response defined within the MSCP namespace, or an 444 element defined in another namespace. 446 An optional id attribute (with an ID value) is defined for both 447 elements. This attribute SHOULD be used with transport channels 448 which do not support correlations ids (see Section 7). For example, 450 451 452 ... 453 454 456 457 458 ... 459 460 462 If used, consecutive requests MUST contain monotonically increasing 463 request id values. If a specifies an id, then its 464 MUST specify an id with the same value. If the request 465 does not specify an id value, its response MUST NOT specify an id. 467 3.3. XML Processing and Extensibility 469 XML messages MUST be checked for well-formedness and SHOULD be 470 validated against the MSCP schema prior to execution; XML errors must 471 be reported in the transport channel protocol (see Section 7). 473 The MSCP protocol can be extended using elements and attributes which 474 MUST be defined in a namespace other than the MSCP namespace. 475 Elements not in the MSCP namespace MAY be specified as the contents 476 of , or elements. For example, 477 479 480 481 ... 482 483 484 486 Attributes which are not in the MSCP namespace MAY be specified as 487 attributes of any element in the MSCP namespace. 489 491 492 ... 493 494 496 A conformant MSCP AS or MS MUST process XML elements within the MSCP 497 namespace as described in this specification. Elements and 498 attributes defined in other namespaces MAY be processed by a 499 conformant MSCP AS or MS. 501 If a MSCP AS or MS encounters an XML document with elements or 502 attributes in a non-MSCP namespace which it does not understand, it 503 MUST ignore these elements and attributes and attempt to process the 504 document as if it contains only elements and attributes within the 505 MSCP namespace. 507 4. Interactive Media Functionality 509 Interactive media covers functionality such as playing a prompt, 510 recording user input, collecting DTMF, TTS, ASR and other media-based 511 processing. These functions are expressed in a dialog script: i.e. a 512 script which describes the media operations and associated dialog 513 processing. VoiceXML 2.0 [VXML20] is capable of expressing these 514 functions. For example, a VoiceXML document is able to express 515 simple interaction like play a prompt, or prompt and collect, as well 516 as more advanced functionality including speech recognition, mixed 517 initiative interaction, video playback and record, and so forth. 518 While VoiceXML 2.0 may not be able to express all the functions 519 described in this specification, they are either on the W3C roadmap 520 (see http://www.w3.org/Voice/") for VoiceXML 3.0 (such as fax and 521 video), or can be provided by vendor-specific extensions of VoiceXML. 523 In order to obtain interactive media functionality, the AS requests 524 the MS to execute a dialog script. The dialog script itself 525 describes the specific functionality. There are two key request 526 elements: 528 : prepare a dialog script for later execution 530 : execute a dialog script (as defined or previously 531 prepared) 533 Once a dialog is active, the MS may send dialog notification events 534 to the AS. These include events indicating that the dialog has ended 535 normally or abnormally, intermediate data or that the dialog script 536 requests disconnection or transfer. 538 The MS MUST support VoiceXML 2.0 dialog scripts and MAY support other 539 dialog script formats. 541 4.1. Request-Response 543 The request is sent from the AS to the MS to request 544 preparation of a dialog. A prepared dialog is executed when the AS 545 sends a request referencing the prepared dialog (see 546 Section 4.2). 548 A element has the following attributes: 550 src: string identifying the URI of the dialog document to prepare. 551 The parameter is optional. Exactly one of the src attribute or 552 the element MUST be specified; otherwise, it is an error. 554 type: string identifying the MIME type of the document. The default 555 value is "application/voicexml+xml". The attribute is optional. 557 connectionid: string identifying the connection for which this 558 dialog will be prepared. If the connectionid is specified, the 559 conferenceid MUST NOT be specified. If neither the connectionid 560 nor the conferenceid is specified, then the dialog can be started 561 on any connection or conference (see Section 4.2). The parameter 562 is optional. 564 conferenceid: string identifying the conference bridge for which 565 this dialog will be prepared. If the conferenceid is specified, 566 the connectionid MUST NOT be specified. If neither the 567 connectionid nor the conferenceid is specified, then the dialog 568 can be started on any connection or conference (see 569 Section 4.2).The parameter is optional. 571 maxage: string defining a time interval according to the max-age 572 parameter in HTTP 1.1 [RFC2616]. The attribute is optional. 574 maxstale: string defining a time interval according to the max-stale 575 parameter in HTTP 1.1. The attribute is optional. 577 enctype: string identifying the encoding type of the submitted 578 document. The default value is "application/ 579 x-www-form-url-encoded". The attribute is optional. 581 method: string indicating the HTTP method to use. Permitted values 582 are "post" or "get". The default value is "get". The attribute 583 is optional. 585 Note that maxage, maxstale, enctype and method attributes are only 586 relevant when the src attribute is defined with the HTTP protocol. 587 In addition, these attributes only apply to the retrieval and caching 588 of the initial dialog document. 590 The element has the following child elements: 592 : contains the dialog script itself; e.g. a VoiceXML document. 593 Exactly one of the src attribute or the element MUST be 594 specified; otherwise, it is an error. The element is optional. 596 : contains a list of one or more elements where 597 each item element has mandatory name and value attributes. These 598 parameters are passed into the dialog script. In VoiceXML, they 599 are exposed via the session level object 600 "connection.ccxml.values.*". The element is optional. 602 : contains a list of one or more elements where 603 each item element has mandatory name and value attributes. The 604 element is optional. The AS uses this element to subscribe to 605 events generated by the MS. Notifications of dialog events are 606 delivered using notifications (see Section 4.6). If 607 the MS does not support a specific event notification to which the 608 AS subscribes, then the MS MUST ignore the individual . 609 This protocol does not require the MS to support any specific 610 event notifications, but the MS MAY support notification events 611 such as "dtmf" (indicating that a DTMF key has been pressed), or 612 "tone" (indicating that a tone has been detected), "audiostart" 613 (audio playback has started), "bargein" (user has barged in), 614 "mark" (a mark has been encountered in the output stream), "goto" 615 (dialog has transitioned to another location), and so forth. 617 : contains a "media" attribute and a "direction" attribute 618 to indicate the type and direction of media flow between dialog 619 and its end point once this dialog is started. The defined values 620 of the "media" attribute are: "audio", "video" and "audiovideo". 621 Defined values of the "direction" attribute are "transmit", 622 "receive" and "both" (transmit and receive media flow). Multiple 623 elements may be specified so that the media type can be 624 specified for specific directions; for example, audio only for 625 transmission, but video only for reception. If no 626 elements are specified, then the default is audio in both 627 directions. 629 For example, a request to prepare a dialog where the dialog script is 630 indicated using the src attribute: 632 633 634 635 636 637 638 639 640 642 Where the namelist parameter "audio" would be available in the 643 VoiceXML script as "connection.ccxml.values.audio" so different 644 prompts can be played using the same dialog script. 646 In the following example, the VoiceXML dialog script is specified 647 inline. 649 650 651 652 653 654
655 656 659
660 661 662 663 664 666 When an MS has received a request, it MUST reply with 667 a , or 668 response element. These elements have 669 following attributes: 671 dialogid: string identifying the dialog. The MS assigns a globally 672 unique identifier for this dialog and reuses it in subsequent 673 references to the dialog; for example, as the prepareddialogid in 674 and in dialog notifications. The attribute is 675 mandatory. 677 connectionid: string identifying the connection for this dialog. If 678 connectionid was specified in the request, this attribute MUST 679 have the same value. The parameter is optional. 681 conferenceid: string identifying the conference bridge for this 682 dialog. If conferenceid was specified in the request, this 683 attribute MUST have the same value. The parameter is optional. 685 The response elements and 686 have the following additional attribute 687 defined: 689 reason: string specifying the reason why dialog preparation failed. 690 The attribute is mandatory. 692 For example, a response when the dialog was prepared successfully: 694 695 696 697 698 700 And a response if dialog preparation failed: 702 703 704 706 707 709 4.2. Request-Response 711 The element is sent by the AS to request execution of a 712 dialog. The dialog may be defined in the dialogstart request itself, 713 or reference a previously prepared dialog. 715 The element has the following attributes: 717 src: string identifying the URI of the dialog document to start. 718 The parameter is optional. If the prepareddialogid is specified, 719 the atribute MUST NOT be specified. 721 type: string identifying the MIME type of the document. The default 722 value is "application/voicexml+xml". The attribute is optional. 723 If the prepareddialogid is specified, the attribute MUST NOT be 724 specified. 726 prepareddialogid: string identifying a dialog previously prepared 727 using a dialogprepare request. The parameter is optional. 729 connectionid: string identifying the connection for this dialog. 730 The parameter is optional. 732 If the prepareddialogid is defined, and the dialogprepare request 733 specified a connnectionid, then if this connectionid is specified, 734 it MUST have the same value; if the connectionid is not specified 735 in this request, but was specified in the dialogprepare request, 736 then the connectionid from the dialogprepare request will be used. 738 If the connectionid is specified, the conferenceid MUST NOT be 739 specified. It is an error if neither the connectionid nor the 740 conferenceid is specified either directly or through inheritance 741 from the dialogprepare request. 743 conferenceid: string identifying the conference bridge for this 744 dialog. The parameter is optional. 746 If the prepareddialogid is defined, and the dialogprepare request 747 specified a conferenceid, then if this conferenceid is specified, 748 it MUST have the same value; if the conferenceid is not specified 749 in this request, but was specified in the dialogprepare request, 750 then the conferenceid from the dialogprepare request will be used. 752 If the conferenceid is specified, the connnectionid MUST NOT be 753 specified. It is an error if neither the connectionid nor the 754 conferenceid is specified either directly or through inheritance 755 from the dialogprepare request. 757 maxage: string defining a time interval according to the max-age 758 parameter in HTTP 1.1. The attribute is optional. If the 759 prepareddialogid is specified, the attribute MUST NOT be 760 specified. 762 maxstale: string defining a time interval according to the max-stale 763 parameter in HTTP 1.1. The attribute is optional. If the 764 prepareddialogid is specified, the attribute MUST NOT be 765 specified. 767 enctype: string identifying the media encoding type of the submitted 768 document. The default value is "application/ 769 x-www-form-url-encoded". The attribute is optional. If the 770 prepareddialogid is specified, the attribute MUST NOT be 771 specified. 773 method: string indicating the HTTP method to use. Permitted values 774 are "post" or "get". The default value is "get". The attribute 775 is optional. If the prepareddialogid is specified, the attribute 776 MUST NOT be specified. 778 Note that maxage, maxstale, enctype and method attributes only 779 relevant when the src attribute is defined with the HTTP protocol. 780 In addition, they only apply to the retrieval and caching of the 781 initial dialog document. 783 The element has the following child elements defined: 785 : contains the dialog script itself; e.g. a VoiceXML document. 786 The element is optional. It is an error to specify both a src 787 attribute and element. If the prepareddialogid is 788 specified, this element MUST NOT be specified. 790 : contains a list of one or more elements where 791 each item element has name and value attributes. These parameters 792 are passed into the dialog script. In VoiceXML, they are exposed 793 via the session level object "connection.ccxml.values.*". The 794 element is optional. If the prepareddialogid is specified, this 795 element MUST NOT be specified. 797 : contains a list of one or more elements where 798 each item element has mandatory name and value attributes. The 799 element is optional. 801 The AS uses this element to subscribe to events generated by the 802 MS. Notifications of dialog events are delivered using 803 notifications (see Section 4.6). If the MS does not 804 support a specific event notification to which the AS subscribes, 805 then the MS MUST ignore the individual . This protocol does 806 not require the MS to support any specific event notifications, 807 but the MS MAY support notification events such as "dtmf" 808 (indicating that a DTMF key has been pressed), or "tone" 809 (indicating that a tone has been detected), "audiostart" (audio 810 playback has started), "bargein" (user has barged in), "mark" (a 811 mark has been encountered in the output stream), "goto" (dialog 812 has transitioned to another location), and so forth. 814 If the prepareddialogid is specified, this element MUST NOT be 815 specified. 817 : contains a "media" attribute and a "direction" attribute 818 to indicate the type and direction of media flow between dialog 819 and its end point once this dialog is started. The defined values 820 of the "media" attribute are: "audio", "video" and "audiovideo". 821 Defined values of the "direction" attribute are "transmit", 822 "receive" and "both" (transmit and receive media flow). Multiple 823 elements may be specified so that the media type can be 824 specified for specific directions; for example, audio only for 825 transmission, but video only for reception. If no 826 elements are specified, then the default is audio in both 827 directions. 829 If the prepareddialogid is specified, this element MUST NOT be 830 specified. 832 For example, a request to start a dialog where the dialog script is 833 indicated using the src attribute: 835 836 837 839 840 841 842 843 844 846 Where the namelist parameter "media" would be available in the 847 VoiceXML script as "connection.ccxml.values.media" so different 848 prompts can be played using the same dialog script. 850 In the following example, the VoiceXML dialog script is specified 851 inline and the media is audiovideo in both directions. 853 854 855 856 857 858 859
860 861 864
865 866 867 868 869 871 In this example, a previously prepared dialog with the dialogid 872 "vxi1" is started. 874 875 876 877 878 880 When an MS has received a request, it MUST reply with a 881 , or 882 response element. These elements have the following attributes: 884 dialogid: string identifying the dialog. If prepareddialogid is 885 specified in the request, then dialogid MUST have the same value. 886 If prepareddialogid is not specified, then the MS assigns a 887 globally unique identifier for this dialog and reuses it in 888 subsequent references to the dialog; for example, in dialog 889 notifications. The attribute is mandatory. 891 connectionid: string identifying the connection for this dialog. 892 The parameter is optional. Exactly one of the connectionid or 893 conferenceid MUST be specified. 895 conferenceid: string identifying the conference bridge for this 896 dialog. The parameter is optional. Exactly one of the 897 connectionid or conferenceid MUST be specified. 899 The response elements and 900 have the following additional attribute 901 defined. 903 reason: string specifying the reason why dialog execution failed. 904 The attribute is mandatory. 906 For example, a response when the dialog was started successfully. 908 909 910 911 912 914 Response if dialog execution failed: 916 917 918 921 922 924 4.3. Notification 926 A dialog that has been prepared or has been started can be terminated 927 by a notification element from the AS. 929 The element has the following attributes: 931 dialogid: string identifying the dialog. The attribute is 932 mandatory. 934 immediate: string with the values "true" or "false". The default is 935 "false". The parameter is optional. 937 For example, assuming a dialog with the dialogid "vxi1" has been 938 started, it can be terminated immediately with the following request: 940 941 942 943 944 946 The notification causes execution of the dialog to 947 be terminated. 949 If the notification is for immediate termination, then the MS MUST 950 NOT send any further notification events for this dialog. 952 If the request is for non-immediate termination, then the MS MAY send 953 a notification event for this dialog as described below. 955 4.4. Notification 957 When an active dialog terminates normally (or after a non-immediate 958 dialogterminate request), the MS MUST send a 959 notification. 961 The element has the following attributes: 963 dialogid: string identifying the dialog. The attribute is 964 mandatory. 966 connectionid: string identifying the connection for this dialog. 967 The parameter is optional. Only one of the connectionid or 968 conferenceid attributes MAY be specified; it is an error to 969 specify both. 971 conferenceid: string identifying the conference bridge for this 972 dialog. The parameter is optional. Only one of the connectionid 973 or conferenceid attributes MAY be specified; it is an error to 974 specify both. 976 The element has the following child element: 978 : contains a list of one or more elements where 979 each item element has name and value attributes. The element is 980 optional. 982 For example, the dialog exits without data being returned: 984 985 986 987 988 990 The dialog exits with data being returned: 992 993 994 995 996 997 998 999 1000 1001 1003 4.5. Notification 1005 When an active dialog terminates abnormally, the MS MUST send an 1006 notification. 1008 The element has the following attributes: 1010 dialogid: string identifying the dialog. The attribute is 1011 mandatory. 1013 connectionid: string identifying the connection for this dialog. 1014 The parameter is optional. Only one of the connectionid or 1015 conferenceid attribute MAY be specified; it is an error to specify 1016 both. 1018 conferenceid: string identifying the conference bridge for this 1019 dialog. The parameter is optional. Only one of the connectionid 1020 or conferenceid attribute MAY be specified; it is an error to 1021 specify both. 1023 reason: string specifying the reason why dialog execution failed. 1024 The attribute is mandatory. 1026 For example, the dialog execution fails: 1028 1029 1030 1032 1033 1035 4.6. Notification 1037 During execution of a dialog, notifications can be sent 1038 from the MS to the AS or from the AS to the MS. 1040 The element has the following attributes: 1042 name: string indicating the name of event. The string is restricted 1043 to a sequence of alphanumeric or "." characters. The attribute is 1044 mandatory. 1046 dialogid: string identifying the dialog. The attribute is 1047 mandatory. 1049 connectionid: string identifying the connection for this dialog. 1050 The parameter is optional. Only one of the connectionid or 1051 conferenceid attribute MAY be specified; it is an error to specify 1052 both. 1054 conferenceid: string identifying the conference bridge for this 1055 dialog. The parameter is optional. Only one of the connectionid 1056 or conferenceid attribute MAY be specified; it is an error to 1057 specify both. 1059 A element has the following child element: 1061 : contains a list of one or more elements where 1062 each item element has name and value attributes. The element is 1063 optional. 1065 For example, the MS sends the AS a midcall update on data collected 1066 so far: 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1079 The AS sends the MS information which may be announced to the user: 1081 1082 1083 1084 1085 1086 1087 1088 1089 1091 4.7. Notification 1093 An MS can request disconnection of a call by sending a 1094 notification. The AS subsequently sends a 1095 notification to the MS (for a VoiceXML dialog, this 1096 will result in the connection.disconnect.hangup being thrown and the 1097 final processing state being entered). 1099 The element has the following attributes: 1101 dialogid: string identifying the dialog. The attribute is 1102 mandatory. 1104 connectionid: string identifying the connection for this dialog. 1105 The parameter is optional. Only one of the connectionid or 1106 conferenceid attributes MAY be specified; it is an error to 1107 specify both. 1109 conferenceid: string identifying the conference bridge for this 1110 dialog. The parameter is optional. Only one of the connectionid 1111 or conferenceid attributes MAY be specified; it is an error to 1112 specify both. 1114 The element has the following child element: 1116 : contains a list of one or more elements where 1117 each item element has name and value attributes. The element is 1118 optional. 1120 For example, the MS sends a dialogdisconnect notification to the AS: 1122 1123 1124 1125 1126 1128 and the AS responds by sending a notification: 1130 1131 1132 1133 1134 1136 4.8. Notification 1138 An MS can request transfer of the call by sending a 1139 notification to the AS. 1141 The element has the following attributes: 1143 dialogid: string identifying the dialog. The attribute is 1144 mandatory. 1146 type: a string specifying the transfer type (see below). The 1147 parameter is mandatory. 1149 connectionid: string identifying the connection for this dialog. 1150 The parameter is optional. Only one of the connectionid or 1151 conferenceid attributes MAY be specified; it is an error to 1152 specify both. 1154 conferenceid: string identifying the conference bridge for this 1155 dialog. The parameter is optional. Only one of the connectionid 1156 or conferenceid attributes MAY be specified; it is an error to 1157 specify both. 1159 uri: a valid uri identifying the destination to which the call is to 1160 be transferred. The attribute is mandatory. 1162 maxtime: string in CSS2 time format indicating the maximum amount of 1163 time the transfer can be stayed connected. The value "0s" 1164 indicates unlimited connection time. The attribute is mandatory. 1166 connecttimeout: string in CSS2 time format indicating the maximum 1167 amount of time to elapse attempting to connect the call. The 1168 attribute is mandatory. 1170 aai: string of application-to-application information to be passed 1171 to the destination when establishing the transfer. The attribute 1172 is optional. 1174 The element has the following child element: 1176 : contains a list of one or more elements where 1177 each item element has name and value attributes. The element is 1178 optional. 1180 Two transfer types, blind and bridged, MUST be supported; other types 1181 MAY be supported. 1183 For a blind transfer, the AS typically redirects the SIP dialog 1184 between the UA and AS by issuing a SIP REFER. The dialog running on 1185 the MS is terminated. 1187 For a bridge transfer, the AS creates a new SIP dialog to the callee 1188 and a new SIP dialog between the AS and MS on behalf of the callee. 1189 The original caller's and the callee's media streams are bridged by 1190 the MS. During the bridge transfer, the dialog may listen on the 1191 original caller's leg for commands to terminate the transfer. If the 1192 callee terminates the call or the dialog terminates the call (e.g. if 1193 the maxtime elapses or a command to terminate the transfer is 1194 recognized), the dialog is resumed with the original caller. 1196 4.8.1. Blind transfer 1198 The MS sends a notification to the AS requesting a blind transfer: 1200 MS -> AS 1201 1202 1203 1206 1207 1209 The AS issues a REFER to the UA and sends a notification to the MS to 1210 terminate the dialog (for a VoiceXML dialog, this will result in the 1211 event connection.disconnect.transfer being raised): 1213 AS -> MS 1214 1215 1216 1217 1218 1220 4.8.2. Bridge transfer 1222 The MS sends a notification to the AS for a bridge transfer: 1224 MS -> AS 1225 1226 1227 1230 1231 1233 The AS creates a new SIP dialog with the callee and creates a SIP 1234 dialog between the AS and MS on behalf of the callee (identified 1235 below by "conn2"). In the event of an error in creating a SIP dialog 1236 with the callee, a notification is sent to 1237 the MS, otherwise the AS instructs the MS to bridge the two calls via 1238 : 1240 AS -> MS 1241 1242 1243 1244 1245 1247 MS -> AS 1248 1249 1250 1251 1252 1254 As a result, the original caller is bridged full duplex with the 1255 callee, and the dialog is "listening" to the caller. The transfer 1256 can terminate for several reasons: 1258 1. the caller terminates the call 1260 2. the AS terminates the transfer 1262 3. the callee terminates the transfer 1264 4. the dialog terminates the transfer 1266 For scenario 1, the AS terminates the dialog with . 1267 The SIP dialogs for the caller and callee between the AS and MS are 1268 subsequently terminated. 1270 For scenario 2, the AS terminates the transfer (e.g. because maxtime 1271 has elapsed) by sending a notification: 1273 AS -> MS 1274 1275 1276 1278 1279 1281 For scenario 3, the AS terminates the SIP dialog for the callee 1282 between the AS and MS (for a VoiceXML dialog this will result in the 1283 transfer ending with a far_end_disconnect). The AS then rejoins the 1284 dialog full duplex with the caller via : 1286 AS -> MS 1287 1288 1289 1290 1291 1293 MS -> AS 1294 1295 1296 1297 1298 1300 For scenario 4, the MS sends the 1301 notification to the AS (e.g. because a command to terminate the 1302 transfer is recognized). The AS rejoins the dialog full duplex with 1303 the caller via : 1305 MS -> AS 1306 1307 1308 1310 1311 1313 AS -> MS 1314 1315 1316 1317 1318 1320 MS -> AS 1321 1322 1323 1324 1325 1327 4.9. Notification 1329 An MS can request termination of bridge transfer by sending a 1330 notification to the AS. 1332 The element has the following attributes: 1334 dialogid: string identifying the dialog. The attribute is 1335 mandatory. 1337 connectionid: string identifying the connection for this dialog. 1338 The parameter is optional. Only one of the connectionid or 1339 conferenceid attributes MAY be specified; it is an error to 1340 specify both. 1342 conferenceid: string identifying the conference bridge for this 1343 dialog. The parameter is optional. Only one of the connectionid 1344 or conferenceid attributes MAY be specified; it is an error to 1345 specify both. 1347 reason: a string indicating the reason transfer is to be terminated. 1348 Allowed values are near_end_disconnect. The attribute is 1349 mandatory. 1351 4.10. Notification 1353 An AS sends a notification to the MS when a 1354 transfer completes due to an error condition or maxtime expiry. 1356 The element has the following attributes: 1358 dialogid: string identifying the dialog. The attribute is 1359 mandatory. 1361 connectionid: string identifying the connection for this dialog. 1362 The parameter is optional. Only one of the connectionid or 1363 conferenceid attributes MAY be specified; it is an error to 1364 specify both. 1366 conferenceid: string identifying the conference bridge for this 1367 dialog. The parameter is optional. Only one of the connectionid 1368 or conferenceid attributes MAY be specified; it is an error to 1369 specify both. 1371 reason: a string indicating the reason the transfer completed. 1372 Allowed values are maxtime_disconnect (if the maxtime elapsed), 1373 busy (if the callee returned a 486 response to the SIP INVITE), 1374 network_busy (if the callee returned a 6xx response to the SIP 1375 INVITE), or noanswer (if connecttimeout elapsed before a final 1376 response was received from the callee to the SIP INVITE). The 1377 attribute is mandatory. 1379 5. Conferencing Functionality 1381 MSCP supports many conferencing models including a distributed, 1382 centralized controller model where signaling and media are directed 1383 to a central location, the conference focus, controlled, or 1384 implemented, by the AS (as defined by the IETF XCON Working Group). 1386 ISSUE: A future version of this document will further clarify the 1387 conference models for MSCP. 1389 In order obtain conferencing functionality, the AS makes a request to 1390 the MS. There are 4 key requests: 1392 : create a conference 1394 : destroys a previously created conference 1396 : add a participant to a conference 1398 : remove a participant from a conference 1400 Note that the join and unjoin requests can also be used to (un)join 1401 connections and dialogs. 1403 Once a conference is active, the MS may send conference notification 1404 events to the AS; for example, active talkers. The AS may also send 1405 notification events to the MS; for example, explicit floor control 1406 notifications. 1408 5.1. Request-Response 1410 An AS can request an MS to create a conference by sending a 1411 request. 1413 The element has the following attributes: 1415 reservedtalkers: number of guaranteed speaker slots to be reserved 1416 for the conference. The attribute is optional. 1418 reservedlisteners: number of guaranteed listeners slots to be 1419 reserved for the conference. The attribute is optional. 1421 reservedmedia: string specifying the type of media resources which 1422 are to be reserved. Defined values are: "audio", "video", 1423 "audiovideo". The default value is "audio". The attribute is 1424 optional. 1426 audiomixingpolicy: a string indicating the audio stream mixing 1427 policy. Defined values are: "nbest" (see audiomixingnbest below) 1428 and "manual" (audio stream is selected manually by the AS via an 1429 external floor control event). The default value is "nbest". The 1430 attribute is optional. 1432 If the conference media is "video" or "audiovideo" and the 1433 audiomixingpolicy is specified as "manual", then the 1434 videomixingpolicy MUST also be set to "manual", otherwise it is an 1435 error. 1437 audiomixingnbest: non-negative integer specifying the maximum number 1438 of participants generating output to be included in the audio mix 1439 based on greatest energy. A value of 0 indicates that all 1440 participants generating output are to be included in the audio 1441 mix. The default value is 0. The attribute is optional. 1443 videomixingpolicy: a string indicating the video stream mixing 1444 policy. Defined values are: "vas" (video stream of loudest active 1445 speaker is selected), "manual" (video stream is selected manually 1446 by the AS via an external floor control event) or "userdefined" 1447 (see ISSUES note below). The attribute is optional. 1449 If the conference media is "video" or "audiovideo", then a value 1450 for audiomixingpolicy MUST also be specified, otherwise it is an 1451 error. 1453 If the conference media is "video" or "audiovideo" and the 1454 videomixingpolicy is specified as "manual", then the 1455 audiomixingpolicy MUST also be set to "manual", otherwise it is an 1456 error. 1458 videomixingvas: a positive integer specifying the minimum amount 1459 time in seconds which MUST elapse before a change in video stream 1460 selection. The default value is 3. The attribute is optional. 1462 The element has the following child element: 1464 : contains a list of one or more elements where 1465 each item element has mandatory name and value attributes. The 1466 element is optional. 1468 The AS uses this element to subscribe to events generated by the MS. 1469 Notifications of conference events are delivered using 1470 notifications (see Section 5.5). If the MS does not 1471 support a specific event notification to which the AS subscribes, 1472 then the MS MUST ignore the individual . 1474 This protocol does not require the MS to support any specific event 1475 notifications, but it does define an active speaker pattern to notify 1476 the AS of active speakers. If an MS supports active speaker 1477 notifications, then it MUST use this pattern. The AS subscribes 1478 using an where the name is "activespeaker" and the value is a 1479 positive integer specifying the minimum amount time in seconds which 1480 MUST elapse before a change in active speaker is notified to the AS. 1481 A value of '0' indicates that active speaker notification is 1482 disabled. The MS notifies the AS of active speakers using a 1483 notification where the event is "activespeaker", and 1484 its namelist includes one or more s with the name set to 1485 "speaker" and the value set to the connectionid of the active 1486 speaker's connection. 1488 ISSUES: 1490 1. A future version of this specification may address how conference 1491 resourcing, mixing policies, etc can be changed once a conference 1492 has been created. One potential solution is for the AS to send 1493 conference updates as notifications to the MS; e.g. a 1494 notification to change the audio mixing policy. Another solution 1495 is to introduce an explicit request element. 1497 2. More investigation is required for "userdefined" video mixing. 1498 For example, making use of (a subset of) SMIL to specify video 1499 layout, regions, titles, switching within regions, etc. 1501 3. Further investigation is also required on the addition of an 1502 automatic conference termination parameter with values: nomedia 1503 (last participant gone), nocontrol (SIP session on which 1504 conference is created gone). 1506 For example, to create a new audio conference: 1508 1509 1510 1511 1512 1514 When an MS has received a request, it MUST respond 1515 with a or response 1516 element. These elements have the following attribute: 1518 conferenceid: string specifying the id of the conference. The MS 1519 assigns a globally unique identifier for this conference and 1520 reuses it in subsequent references to the conference; for example, 1521 in conference notifications. The attribute is mandatory. 1523 In addition, the element has the following 1524 attribute defined. 1526 reason: string specifying the reason why conference was not created. 1527 The attribute is mandatory. 1529 For example, the conference has been created successfully. 1531 1532 1533 1534 1535 1537 An error occurred preventing conference creation. 1539 1540 1541 1543 1544 1546 5.2. Request-Response 1548 A conference is terminated by the AS sending a 1549 request. 1551 The element has the following attribute: 1553 conferenceid: string indicating the conference id. The attribute is 1554 mandatory. 1556 For example: 1558 1559 1560 1561 1562 1564 When an MS has received a request, it MUST reply 1565 with a or response 1566 element. These elements have the following attribute: 1568 conferenceid: a string identifying the conference. The attribute is 1569 mandatory. 1571 The also has the following attribute: 1573 reason: string specifying the reason why conference was not 1574 destroyed. The attribute is mandatory. 1576 For example, the conference "conf1" has been successfully destroyed: 1578 1579 1580 1581 1582 1584 The conference "conf2" has not been destoyed: 1586 1587 1588 1590 1591 1593 5.3. Request-Response 1595 The AS can join a participant to a conference using the join request. 1596 The participant can be a dialog, a connection or another conference. 1598 This request can also be used to modify how a previously connected 1599 participant is joined to the conference. 1601 The element has the following attributes: 1603 id1: string indicating a connection, dialog or conference. The 1604 parameter is mandatory. 1606 id2: string indicating the connection, dialog or conference to join 1607 to id1. The parameter is mandatory. 1609 mediapreferred: string indicating whether the participant is always 1610 allowed to contribute to the audio mix event if they are not 1611 eligible in terms of loudness. Defined values are "true" (always 1612 mixed) and "false" (must be eligible in terms of loudness). The 1613 default value is "false". The attribute is optional. The 1614 attribute is ignored if the conference audio mixing policy is not 1615 "nbest". 1617 entertone: string with the values 'true','false' or URI (custom 1618 audio) indicating whether a tone is to be played when another 1619 participant joins the conference. The default value is 'true'. 1620 The parameter is optional. 1622 exittone: string with the values 'true','false' or URI (custom 1623 audio) indicating whether a tone is to be played when another 1624 participant leaves the conference. The default value is 'true'. 1625 The parameter is optional. 1627 autoinputgain: string with values 'true' or 'false' indicating 1628 whether AGC is to be used on the participant's input to the 1629 conference. The default is 'true'. The parameter is optional. 1630 The parameter is ignored if AGC is not supported. 1632 autooutputgain: string with values 'true' or 'false' indicating 1633 whether AGC is to be used on the participant's output from the 1634 conference. The default is 'true'. The parameter is optional. 1635 The parameter is ignored if AGC is not supported. 1637 dtmfclamp: string with values 'true' or 'false' indicating whether 1638 DTMF is to be removed from the participant's input to the 1639 conference. The default is 'true'. The parameter is optional. 1640 The parameter is ignored if this behavior is not supported. 1642 toneclamp: string with values 'true' or 'false' indicating whether 1643 loud single frequency tones from are to be removed from the 1644 participant's input to the conference. The default is 'true'. 1645 The parameter is optional. The parameter is ignored if this 1646 behavior is not supported. 1648 The element has the following child element: 1650 : contains a "media" attribute and a "direction" attribute 1651 to indicate the type and direction of media flow between id1 and 1652 id2. The defined values of the "media" attribute are: "audio", 1653 "video" and "audiovideo". Defined values of the "direction" 1654 attribute are "transmit" (media flow from id2 to id1 only), 1655 "receive" (media flow from id1 to id2 only) and "both" (media flow 1656 in both directions). Multiple elements may be specified 1657 so that the media type can be specified for different directions; 1658 for example, audio only for transmission, but video only for 1659 reception. If no elements are specified, then the 1660 default is audio in both directions. 1662 For example, to join a participant's connection "connection1" with 1663 full duplex audio to the conference "conf1": 1665 1666 1667 1668 1669 1671 The semantics of follow the bridging model in CCXML 1.0, 1672 Section 10.4. In particular follows three invariant topology 1673 rules: 1675 1. The media stream relationship specified is established between 1676 two connections/conferences/dialogs referenced by id1 and id2 1677 attributes in the element. Any existing stream 1678 relationship between these connections/conferences/dialogs is 1679 torn down automatically if it conflicts with the specified 1680 relationship. 1682 2. If the relationship specified in the element requires a 1683 connection/dialog to listen and the connection is listening to a 1684 different source, this existing stream relationship is torn down 1685 automatically. 1687 3. Any existing stream relationship that does not present a conflict 1688 according to invariant #1 or #2 is preserved. 1690 When an MS has received a join request, it MUST reply with a 1691 or response elements. These 1692 elements have following attributes: 1694 id1: string indicating a connection, dialog or conference. This 1695 MUST have the same value as id1 in the request. The 1696 parameter is mandatory. 1698 id2: string indicating a connection, dialog or conference. This 1699 MUST have the same value as id2 in the request. The 1700 parameter is mandatory. 1702 The element also has the following attribute: 1704 reason: string specifying the reason why the join did not occur. 1705 The attribute is mandatory. 1707 For example, the connection "connection1" is successfully joined to 1708 conference "conf1": 1710 1711 1712 1713 1714 1716 or if this join was unsuccessful: 1718 1719 1720 1722 1723 1725 5.4. Request-Response 1727 A participant can be removed from a conference by sending an 1728 request. The participant can be a dialog, connection or another 1729 conference. 1731 The element has the following attributes: 1733 id1: string indicating a connection, dialog or conference. The 1734 parameter is mandatory. 1736 id2: string indicating the connection, dialog or conference to 1737 unjoin from id1. The parameter is mandatory. 1739 For example, to unjoin a connection "connection1" from the conference 1740 "conf1": 1742 1743 1744 1745 1746 1748 When an MS has received an request, it MUST reply a 1749 or response elements. 1750 These elements have the following attributes: 1752 id1: string indicating a connection, dialog or conference. This 1753 MUST have the same value as id1 in the request. The 1754 parameter is mandatory. 1756 id2: string indicating a connection, dialog or conference. This 1757 MUST have the same value as id2 in the request. The 1758 parameter is mandatory. 1760 The element also has the following attribute: 1762 reason: string specifying the reason why the unjoin did not occur. 1763 The attribute is mandatory. 1765 For example, connection "connection1" has successfully been unjoined 1766 from the conference "conf1": 1768 1769 1770 1771 1772 1774 or the unjoin was unsuccessful: 1776 1777 1778 1780 1781 1783 5.5. Notification 1785 During a conference, notifications can be sent from 1786 the MS to the AS or from the AS to the MS. No response is required. 1788 Notifications from the MS to the AS may include active talker 1789 notifications and resource assignment notifications. 1791 Notifications from the AS to the MS may include floor control. 1793 The element has the following attributes: 1795 name: string indicating the name of event. The string is restricted 1796 to a sequence of alphanumeric or "." characters. The attribute is 1797 mandatory. 1799 conferenceid: string identifying the conference. The parameter is 1800 mandatory. 1802 A element has the following child element defined: 1804 : contains a list of one or more elements where 1805 each item element has name and value attributes. The element is 1806 optional. 1808 For example, the MS sends the AS a midconference update on conference 1809 attendance data so far: 1811 1812 1813 1814 1815 1816 1817 1818 1819 1821 The AS sends the MS floor control information: 1823 1824 1825 1826 1827 1828 1829 1830 1831 1833 6. Examples 1835 The following examples show how the protocol is used to create 1836 interactive media and conferencing sessions. 1838 For the sake of brevity, examples assume that the AS uses SIP 3PCC to 1839 setup media connection between incoming call from UE and MS, and that 1840 the ids of connections are based on the SIP dialog ID (see 1841 Section 2.3.1). 1843 6.1. Interactive Media Dialogs 1845 This example shows how the AS requests the MS to play a simple audio 1846 prompt to the user. 1848 AS -> MS 1849 1850 1851 1854 1855 1857 AS <- MS 1858 1859 1860 1862 1863 1865 Comment: the audio dialog has started 1867 AS <- MS 1868 1869 1870 1872 1873 1875 Comment: the dialog has completed. 1877 The second example shows how the AS requests the MS to prepare and 1878 play an inline VoiceXML dialog which collects 4 digits from the user. 1880 AS -> MS 1881 1882 1883 1884 1885 1887
1888 1889 Please type in your pin number. 1890 1891 1892 1893 1894
1895 1896 1897 1898 1899 1901 AS <- MS 1902 1903 1904 1905 1906 1908 Comment: the dialog has been prepared for any connection but not 1909 started. 1911 AS -> MS 1912 1913 1914 1916 1917 1919 Comment: the prepared dialog is started on the connection 1920 identified as a1e8ad50029@15.124.40.73. 1922 AS <- MS 1923 1924 1925 1927 1929 1931 Comment: the prompt and collect digits dialog has started. 1933 AS <- MS 1934 1935 1936 1938 1939 1940 1941 1942 1943 1945 Comment: the dialog has completed and returns the digit string 1946 ('1234') which the user entered. 1948 In this final example, a VoiceXML dialog is started which plays a 1949 video prompt, records a video from the user and uploads to a server. 1951 AS -> MS 1952 1953 1954 1955 1956 1957 1959
1960 1961 1968
1969 1970 1971 1972 1973 1975 AS <- MS 1976 1977 1978 1980 1981 1983 Comment: audiovideo dialog started successfully. 1985 AS <- MS 1987 1988 1989 1991 1992 1994 Comment: dialog complete and recording uploaded to record store. 1996 6.2. Basic Audio Conference 1998 This example create a conferences, participant dials in, prompts to 1999 record their name, joins them to conference and announces their name. 2001 AS -> MS 2002 2003 2004 2005 2006 2008 AS <- MS 2009 2010 2011 2012 2013 2015 Comment: AS requests conference to be created. The MS replies that 2016 this request has been successful and returns the conference id 2017 "conf1". 2019 [AS receives INVITE from UE] 2021 AS -> MS 2022 SIP: INVITE (UE SDP) 2024 AS <- MS 2025 SIP: 200 (MS SDP) 2027 AS -> MS 2028 ACK 2030 [AS sends 200 to UE; receives ACK] 2032 Comment: AS uses SIP 3PCC to setup media connection between incoming 2033 call from UE and MS. The dialog ID of the UE SIP call is 2034 "a1e8ad50029@15.124.40.73;2134;1423". 2036 AS -> MS 2038 2039 2040 2042 2043 2044 Comment: The AS requests that a dialog is played on the connection 2045 identified by the SIP dialog ID. The dialog prompts the user for the 2046 conference code and password, and then records their name. 2048 AS <- MS 2050 2051 2052 2054 2055 2057 Comment: MS responses that the dialog started successfully. 2059 AS <- MS 2061 2062 2063 2065 2066 2068 2069 2070 2071 2073 Comment: The MS notifies the AS that dialog has completed and also 2074 provides the uri of the username recording. 2076 AS -> MS 2078 2079 2080 2081 2082 2084 AS <- MS 2086 2087 2088 2090 2091 2092 Comment: The AS requests that MS to join the participant to the 2093 conference created earlier using the default bidirectional audio 2094 stream setup. The MS responds that the join was successful. 2096 AS -> MS 2097 2098 2099 2101 2102 2104 2105 2106 2107 2109 Comment: The AS requests the MS to play a dialog to the conference 2110 announcing the new participant. 2112 AS <- MS 2113 2114 2115 2116 2117 2119 Comment: The MS responds that the dialog has started. 2121 AS <- MS 2122 2123 2124 2125 2126 2128 Comment: The MS notifies that the dialog has finished. Above steps 2129 are repeated as each participant joins (the dialog and connections 2130 ids would be different). 2132 AS -> MS 2133 2134 2135 2136 2137 2139 AS <- MS 2140 2141 2142 2144 2145 2147 Comment: The participant leaves the conference. This step is repeated 2148 as each participant leaves the conference. 2150 AS -> MS 2151 2152 2153 2154 2155 2157 AS <- MS 2158 2159 2160 2161 2162 2164 Comment: Once all participants have left the conference, the 2165 conference is destroyed. 2167 6.3. Manipulating Conference Participants 2169 The following example shows how a conference participant's mute/ 2170 unmute setting can be controlled by attaching a dialog to a 2171 participant's connection. The example assumes that the conference 2172 has already been created. 2174 AS -> MS 2175 2176 2177 2179 2180 2181 2182 2183 2184 2185 2186 Comment: The AS requests the MS starts a dialog on the connection. 2187 The dialog is a VoiceXML script which listens for digits; when it 2188 receives a digit, it will notify the AS and continue listening for 2189 digits. 2191 AS <- MS 2192 2193 2194 2196 2197 2199 Comment: The MS responds that the dialog has started. 2201 AS -> MS 2202 2203 2204 2205 2206 2208 AS <- MS 2209 2210 2211 2213 2214 2216 Comment: The participant is now joined to the conference in 2217 bi-directional audio mode. Note that audio output from the 2218 participant is streamed to both the dialog and conference. 2220 AS <- MS 2221 2222 2223 2224 2225 2226 2227 2228 2229 2231 Comment: MS notifies the AS that the user has pressed 1. 2233 AS -> MS 2234 2235 2236 2237 2238 2239 2240 2242 Comment: AS instructs the MS to (re)join the participant to the 2243 conference without the participant's input: i.e. they are on mute. 2244 Note that the participant's input is still streamed to the dialog, 2245 so their DTMF commands can be interpreted. 2247 AS <- MS 2248 2249 2250 2252 2253 2255 6.4. Sidebar Conference 2257 In this example, a sidebar conference is setup and some participants 2258 are moved into the sidebar conference so they can chat privately. 2259 They are still able to hear the main conference. The example assumes 2260 that the participants are currently joined to the main conference and 2261 that a sidebar conference with the name 'conf2' has already been 2262 created. 2264 AS -> MS 2265 2266 2267 2268 2269 2270 2271 2273 AS <- MS 2274 2275 2276 2277 2278 2280 Comment: AS instructs MS to join the sidebar conference to the main 2281 conference so the sidebar conference can hear the main conference but 2282 not vice versa. 2284 AS -> MS 2285 2286 2287 2289 2290 2292 AS <- MS 2293 2294 2295 2297 2298 2300 Comment: participant on connection a1e8ad50029@15.124.40.73;2139;1429 2301 is unjoined from the main conference. 2303 AS -> MS 2304 2305 2306 2307 2308 2310 AS <- MS 2311 2312 2313 2315 2316 2318 Comment: participant on connection a1e8ad50029@15.124.40.73;2139;1429 2319 is joined to the sidebar conference. 2321 AS -> MS 2322 2323 2324 2325 2326 2328 AS <- MS 2329 2330 2331 2333 2334 2336 Comment: participant on connection a1e8999999@15.124.40.73;2134;1423 2337 is unjoined from the main conference. 2339 AS -> MS 2340 2341 2342 2343 2344 2346 AS <- MS 2347 2348 2349 2351 2352 2354 Comment: participant on connection a1e8999999@15.124.40.73;2134;1423 2355 is joined to the sidebar conference. The participants on connections 2356 a1e8ad50029@15.124.40.73;2139;1429 and 2357 a1e8999999@15.124.40.73;2134;1423 can now chat to each other 2358 privately while still hearing the main conference. 2360 7. Transport Channel 2362 By employing a self-contained XML representation for the MSCP 2363 messages, the protocol is independent of the underlying transport 2364 channel. 2366 While SIP itself is not an ideal transport channel for a control 2367 protocol, the MSCP protocol MAY be transported in SIP INFO messages. 2368 However, protocol messages SHOULD be transported over a dedicated 2369 transport channel as described in Section 7.2. This has several 2370 advantages: it fits neatly within the architecture and goals of SIP, 2371 it avoids problems with MTU limits and sequencing when using SIP over 2372 UDP, it circumvents timing issues, and it avoids putting unnecessary 2373 burdens on SIP network elements such as proxy servers. 2375 ISSUES: 2377 1. A future version of this document will further clarify the 2378 relationship between the SIP channel and individual connections 2379 for conferencing. 2381 2. A future version may also specify how SOAP can be used as a 2382 dedicated transport channel. 2384 7.1. SIP Transport Channel 2386 MSCP messages can be transported with SIP INFO messages. Requests, 2387 responses, and notification messages are carried in the body of 2388 separate SIP INFO messages. 2390 To use this mechanism, the AS SHOULD initiate a media-less SIP dialog 2391 with the MS. Alternatively, protocol messages MAY be transported on 2392 the SIP dialogs managing individual participants sessions between the 2393 AS and MS. The SIP dialog used to send a response MUST be the same 2394 SIP session on which the request was sent. Note that in this case, 2395 there is no connection between the target of request messages / 2396 notifications and the particular SIP dialog. 2398 Support for multipart mime payloads in the body of SIP messages may 2399 be necessary, but is not required by this protocol. 2401 7.2. TCP Transport Channel 2403 This transport channel requires the use of a connection-oriented 2404 transport layer such as TCP or SCTP to provide guaranteed delivery 2405 and sequencing of messages between the AS and MS. If security is 2406 required, TLS may be employed. 2408 A simple transaction model is employed. The AS can send requests to 2409 the MS. A response message must be sent from the MS to the AS in 2410 reply to each request message. Notification messages may be sent at 2411 any time from the AS to the MS or from the MS to the AS. 2413 7.2.1. Establishing the Transport Channel 2415 The AS can locate the MS in the SIP network using standard SIP 2416 mechanisms [RFC3263]. The transport channel is established via the 2417 SDP offer/answer model [RFC3264] and the mechanism described in 2418 [TCPSDP]. The transport channel is identified in the SDP offer and 2419 answer with an m-line of type "application". The port number in the 2420 offer is fixed at 9. The corresponding m-line in the answer 2421 specifies the MS port number for which the AS must connect to. The 2422 a=setup attribute MUST be "active" for the offer from the AS and MUST 2423 be "passive" for the answer from the MS. 2425 The transport channel persists for the duration of the associated SIP 2426 dialog. If an endpoint determines that the TCP connection has been 2427 closed and it should be reestablished, it SHOULD perform a new offer/ 2428 answer exchange using a connection value of 'new' for this m-line. 2430 Example: 2432 AS->MS: 2433 INVITE sip:ms@example.com SIP/2.0 2434 Via: SIP/2.0/TCP as.example.com:5060; 2435 branch=z9hG4bK776asdhds 2436 Max-Forwards: 70 2437 To: MS 2438 From: AS ;tag=1928301774 2439 Call-ID: a84b4c76e66710 2440 CSeq: 314161 INVITE 2441 Contact: 2442 Content-Type: application/sdp 2443 Content-Length: ... 2445 v=0 2446 o=as 53655765 53655765 IN IP4 192.168.1.1 2447 s=Example 2448 c=IN 192.168.1.1 2449 m=application 9 TCP/MS 2450 a=setup:active 2451 a=connection:new 2453 MS->AS: 2454 SIP/2.0 200 OK 2455 Via: SIP/2.0/TCP as.example.com:5060; 2456 branch=z9hG4bK776asdhds 2457 To: MS ;tag=19 2458 From: AS ;tag=1928301774 2459 Call-ID: a84b4c76e66710 2460 CSeq: 314161 INVITE 2461 Contact: 2462 Content-Type: application/sdp 2463 Content-Length: ... 2465 v=0 2466 o=ms 1435262 1435262 IN IP4 192.168.1.2 2467 s=Example 2468 c=IN IP4 192.168.1.2 2469 m=application 32416 TCP/MS 2470 a=setup:passive 2471 a=connection:new 2473 AS->MS: 2474 ACK sip:ms@example.com SIP/2.0 2475 Via: SIP/2.0/TCP as.example.com:5060; 2476 branch=z9hG4bK776asdhds 2477 Max-Forwards: 70 2478 To: MS ;tag=19 2479 From: AS ;tag=1928301774 2480 Call-ID: a84b4c76e66710 2481 CSeq: 314161 INVITE 2482 Content-Length: 0 2484 7.2.2. Transport Channel PDU 2486 The TCP transport channel PDU contains a textual header part in the 2487 ASCII character subset of UTF-8 and a binary body part. 2489 The PDU header consists of a start-line, message-header fields (also 2490 known as "headers") delimited by CRLF, an empty line (i.e. a line 2491 with nothing preceding the CRLF) indicating the end of the header 2492 fields and a body containing a MIME entity. 2494 The body is used for carrying the XML message payload but MAY contain 2495 additional messages by exploiting multipart MIME. All PDUs include 2496 the Content-Type and Content-Length headers and a body. 2498 generic-message = start-line 2499 message-header 2500 CRLF 2501 message-body 2503 start-line = (request-line | response-line | 2504 notification-line) CRLF 2506 message-header = content-length 2507 content-type 2509 message-body = *OCTET 2511 content-length = "Content-Length" ":" 1*DIGIT CRLF 2513 content-type = "Content-Type" ":" media-type CRLF 2515 7.2.3. Request 2517 The request message is from the AS to the MS. The transport channel 2518 request consists of the request-line followed by message-header 2519 fields. 2521 request-line = "REQ" SP version SP 2522 SP request-id CRLF 2524 The version field contains the protocol version, is included in 2525 request, response, notification messages, and takes the format: 2527 version = "MSCP" "/" 1*DIGIT "." 1*DIGIT 2529 This document specifies MSCP/1.0. 2531 The request-id is used to correlate responses to specific requests. 2532 The initial value of the request-id is arbitrary. Consecutive 2533 requests MUST contain monotonically increasing request-id values. 2534 The MS MUST include the same request-id in its response. 2536 request-id = 1*DIGIT 2538 7.2.4. Response 2540 The response message is from the MS to the AS. Each request to the 2541 MS MUST be followed by a response with a matching request-id. 2543 The transport channel response consists of the response-line followed 2544 by message-header fields. 2546 response-line = version SP status-code SP reason-phrase 2547 SP request-id CRLF 2549 The status-code element is a 3-digit integer result code of the 2550 attempt to understand the request and is explained below. 2552 status-code = "200" ; OK 2553 | "400" ; Bad Request 2554 | "500" ; Internal Error 2556 reason-phrase = "OK" 2557 | "Bad Request" 2558 | "Internal Error" 2560 A status-code / reason-phrase of 200 OK implies the request was 2561 received and processed. The response is contained in the body. 2563 A status-code / reason-phrase of 400 Bad Request implies the request 2564 had an error in it and could not be processed (for example, malformed 2565 XML). The error response is contained in the body. 2567 A status-code / reason-phrase of 500 Internal Error implies the MS 2568 encountered an error when receiving and attempting to dispatch the 2569 request for processing. The error response is contained in the body. 2571 7.2.5. Notification 2573 The notification message is from the AS to the MS or from the MS to 2574 the AS. The transport channel event consists of the notification- 2575 line followed by message-header fields. 2577 notification-line = "NOTIF" SP version CRLF 2579 The notification is contained in the body. 2581 7.2.6. Example Exchange 2583 The following illustrates an example of the TCP transport channel for 2584 an AS that starts a dialog which plays a prompt to the user and 2585 collects DTMF digits. When the dialog terminates, a notification is 2586 sent to the AS to indicate termination of the dialog and includes the 2587 collected digits for processing by the AS. 2589 AS->MS: 2591 REQ MSCP/1.0 21091 2592 Content-Type: application/mscp+xml 2593 Content-Length: nnnn 2595 2596 2597 2599 2600 2602 MS->AS: 2604 MSCP/1.0 200 OK 21091 2605 Content-Type: application/mscp+xml 2606 Content-Length: nnnn 2608 2609 2610 2611 2612 2614 MS->AS: 2616 NOTIF MSCP/1.0 2617 Content-Type: application/mscp+xml 2618 Content-Length: nnnn 2620 2621 2622 2623 2624 2625 2626 2627 2628 2630 8. Formal Syntax 2632 The XML schema for MSCP messages is specified below. 2634 2635 2638 2639 MSCP 1.0 schema (20050708) 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2771 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2819 2820 2821 2822 2823 2825 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2868 2869 2870 2871 2872 2873 2875 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2905 2907 2909 2911 2913 2915 2917 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2973 2975 2977 2979 2981 2983 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3069 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3162 9. Security Considerations 3164 The MSCP protocol may carry sensitive application information such as 3165 usernames, passwords, confidential or private information, etc. For 3166 this reason, the AS and MS endpoints must have the option of secure 3167 communication for MSCP messages they send and receive. This can be 3168 achieved by using a transport channel which can be properly secured 3169 as described in Section 7. 3171 10. IANA Considerations 3173 The MSCP media type "application/mscp+xml" and the MSCP XML namespace 3174 "urn:ietf:mscp" may need to be registered with IANA. 3176 11. Change Summary 3178 The following are the changes between the -02 of the draft and the 3179 -01 version. 3181 o Corrected parameter "wtoneclamp" to "toneclamp" 3183 o Add Editor's Note in Section 2 describing how the next version of 3184 MSCP will be aligned with SIP Control Framework as well as its 3185 related IVR and conferencing packages. 3187 The following are the primary changes between the -01 of the draft 3188 and the -00 version. 3190 o Miscellaneous typos corrected 3192 o Changed to in 3193 4.8.2 "Bridge transfer" in scenario 2 example code 3195 12. Contributors 3197 The editors gratefully acknowledge the following individuals and 3198 their companies who contributed to MSCP: 3200 R. J. Auburn (Voxeo) 3202 Hans Bjurstrom (Hewlett-Packard) 3204 Dave Burke (Voxpilot) 3206 Emily Candell (Comverse) 3208 Jeff Haynie (Vocalocity) 3210 Scott McGlashan (Hewlett-Packard) 3212 Ken Rehor (Vocalocity) 3214 Dave Renshaw (IBM) 3216 Rao Surapaneni (Tellme Networks) 3218 13. References 3220 13.1. Normative References 3222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3223 Requirement Levels", BCP 14, RFC 2119, March 1997. 3225 13.2. Informative References 3227 [BASIC_CONFERENCE_PACKAGE] 3228 Boulton, C., Melanchuk, T., McGlashan, S., and A. 3229 Shiratzky, "A Conference Control Package for the Session 3230 Initiation Protocol (SIP)", 3231 draft-boulton-conference-control-package-00 (work in 3232 progress), March 2006. 3234 [BASIC_IVR_PACKAGE] 3235 Boulton, C., Melanchuk, T., McGlashan, S., and A. 3236 Shiratzky, "A Basic Interactive Voice Response (IVR) 3237 Control Package for the Session Initiation Protocol 3238 (SIP)", draft-boulton-ivr-control-package-01 (work in 3239 progress), March 2006. 3241 [CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML Version 3242 1.0", W3C Working Draft (work in progress), June 2005. 3244 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3245 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3246 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3248 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3249 A., Peterson, J., Sparks, R., Handley, M., and E. 3250 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3251 June 2002. 3253 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 3254 Protocol (SIP): Locating SIP Servers", RFC 3263, 3255 June 2002. 3257 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3258 with Session Description Protocol (SDP)", RFC 3264, 3259 June 2002. 3261 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 3262 Camarillo, "Best Current Practices for Third Party Call 3263 Control (3pcc) in the Session Initiation Protocol (SIP)", 3264 BCP 85, RFC 3725, April 2004. 3266 [SIPCONF] Rosenberg, J., "A Framework for Conferencing with the 3267 Session Initiation Protocol", 3268 draft-ietf-sipping-conferencing-framework-05 (work in 3269 progress), May 2005. 3271 [SIPCONTROLFRAMEWORK] 3272 Boulton, C., Melanchuk, T., McGlashan, S., and A. 3273 Shiratzky, "A Control Framework for the Session Initiation 3274 Protocol (SIP)", draft-boulton-sip-control-framework-03 3275 (work in progress), June 2006. 3277 [SIPEVENTS] 3278 Rosenberg, J., Schulzrinne, H., and O. Levin, "Session 3279 Initiation Protocol (SIP) Event Package for Conference 3280 State", draft-ietf-sipping-conferencing-package-11 (work 3281 in progress), June 2005. 3283 [TCPSDP] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 3284 the Session Description Protocol (SDP)", 3285 draft-ietf-mmusic-sdp-comedia-10 (work in progress), 3286 November 2004. 3288 [VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P., 3289 Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K., 3290 and S. Tryphonas, "Voice Extensible Markup Language 3291 (VoiceXML) Version 2.0", W3C Recommendation, March 2004. 3293 [VXML_IVR_PACKAGE] 3294 Boulton, C., Melanchuk, T., McGlashan, S., and A. 3295 Shiratzky, "A VoiceXML Interactive Voice Response (IVR) 3296 Control Package for the Session Initiation Protocol 3297 (SIP)", draft-boulton-ivr-vxml-control-package-00 (work in 3298 progress), March 2006. 3300 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C M., Maler, E., 3301 and F. Yergeau, "Extensible Markup Language (XML) 1.0 3302 (Third Edition)", W3C Recommendation, February 2004. 3304 Authors' Addresses 3306 Scott McGlashan 3307 Hewlett-Packard 3308 Gustav III:s boulevard 36 3309 SE-16985 Stockholm 3310 Sweden 3312 Email: Scott.McGlashan@hp.com 3314 R. J. Auburn 3315 Voxeo 3316 100 East Pine Street #600 3317 Orlando, FL 32801 3318 USA 3320 Email: rj@voxeo.com 3322 Dave Burke 3323 Voxpilot 3324 6 - 9 Trinity Street 3325 Dublin 2 3326 Ireland 3328 Email: david.burke@voxpilot.com 3330 Emily Candell 3331 Comverse 3332 100 Quannapowitt Parkway 3333 Wakefield, MA 01880 3334 USA 3336 Email: Emily.Candell@comverse.com 3338 Rao Surapaneni 3339 Tellme Networks 3340 1310 Villa Street 3341 Mountain View, CA 94041 3342 USA 3344 Email: rao@tellme.com 3346 Full Copyright Statement 3348 Copyright (C) The Internet Society (2006). 3350 This document is subject to the rights, licenses and restrictions 3351 contained in BCP 78, and except as set forth therein, the authors 3352 retain all their rights. 3354 This document and the information contained herein are provided on an 3355 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3356 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3357 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3358 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3359 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3360 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3362 Intellectual Property 3364 The IETF takes no position regarding the validity or scope of any 3365 Intellectual Property Rights or other rights that might be claimed to 3366 pertain to the implementation or use of the technology described in 3367 this document or the extent to which any license under such rights 3368 might or might not be available; nor does it represent that it has 3369 made any independent effort to identify any such rights. Information 3370 on the procedures with respect to rights in RFC documents can be 3371 found in BCP 78 and BCP 79. 3373 Copies of IPR disclosures made to the IETF Secretariat and any 3374 assurances of licenses to be made available, or the result of an 3375 attempt made to obtain a general license or permission for the use of 3376 such proprietary rights by implementers or users of this 3377 specification can be obtained from the IETF on-line IPR repository at 3378 http://www.ietf.org/ipr. 3380 The IETF invites any interested party to bring to its attention any 3381 copyrights, patents or patent applications, or other proprietary 3382 rights that may cover technology that may be required to implement 3383 this standard. Please address the information to the IETF at 3384 ietf-ipr@ietf.org. 3386 Acknowledgment 3388 Funding for the RFC Editor function is provided by the IETF 3389 Administrative Support Activity (IASA).