view Side-By-Side changes
SIPPING J. Van Dyke Internet-Draft E. Burger, Ed. Expires:June 25, 2005September 1, 2006 A. Spitzer Brooktrout Technology, Inc.December 25, 2004February 28, 2006 Media Server Control Markup Language (MSCML) and Protocoldraft-vandyke-mscml-06draft-vandyke-mscml-07 Status of this MemoThis document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667.By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or shebecomebecomes aware will be disclosed, in accordance withRFC 3668.Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents asInternet-Drafts.Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onJune 25, 2005.September 1, 2006. Copyright Notice Copyright (C) The Internet Society(2004).(2006). Abstract Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-levelmodel for conference control,control model, as opposed to device-levelconferencecontrol models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page 1] Internet-Draft MSCMLDecember 2004February 2006 Intellectual Property Rights Brooktrout Technology, Inc. is making their intellectual property right interest in MSCML available on a royalty-free basis, per the terms described in the online IETF list of claimed rights at http://www.ietf.org/ietf/IPR/SNOWSHORE-draft-vandyke-mscml.txt. Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.Van Dyke, et al. Expires June 25, 2005 [Page 2] Internet-Draft MSCML December 2004Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. MSCML Approach . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use of SIP Request Methods . . . . . . . . . . . . . . . . . . 5 4. MSCML Design . . . . . . . . . . . . . . . . . . . . . . . . . 74.14.1. Transaction Model . . . . . . . . . . . . . . . . . . . . 74.24.2. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. MSCML Time Values . . . . . . . . . . . . . . . . . . 9 5. Advanced Conferencing . . . . . . . . . . . . . . . . . . . . 95.15.1. Conference Model . . . . . . . . . . . . . . . . . . . . . 95.25.2. Configure ConferenceTag .Request <configure_conference> . . . 11 5.3. Configure Leg Request <configure_leg> . . . . . . . . . . 13 5.4. Terminating a Conference . . .10 5.2.1 Conference Leg Attributes. . . . . . . . . . . . . .11 5.3 Terminating a14 5.5. Conference Manipulation . . . . . . . . . . . . . . . . .12 5.4 Conference Manipulation15 5.6. Video Conferencing . . . . . . . . . . . . . . . . .13 6. Interactive Voice Response (IVR). . . 17 5.7. Conference Events . . . . . . . . . . . .15 6.1 Play Audio <play>. . . . . . . . 17 5.8. Conferencing With Personalized Mixes . . . . . . . . . . . 18 5.8.1. MSCML Elements and Attributes for Personalized Mixes . . .17 6.2 Collect Digits <playcollect>. . . . . . . . . . . . . . .17 6.3 Recording Audio <playrecord>. . . . . . 19 5.8.2. Example Usage of Personalized Mixes . . . . . . . . . 206.4 Stop Request <stop>6. Interactive Voice Response (IVR) . . . . . . . . . . . . . . . 25 6.1. Specifying Prompt Content . . . .22 6.5 Prompt Block <prompt>. . . . . . . . . . . . 26 6.1.1. Use of the Prompt Element . . . . . .22 7. Fax Processing. . . . . . . . 26 6.2. Multimedia Processing for IVR . . . . . . . . . . . . . . 33 6.3. Playing Announcements <play> . .23 7.1 Recording Fax <faxrecord>. . . . . . . . . . . . . 34 6.4. Prompt and Collect <playcollect> . . .23 7.2 Sending Fax <faxplay>. . . . . . . . . . 36 6.4.1. Control of Digit Buffering and Barge-in . . . . . . . 36 6.4.2. Mapping DTMF Keys to Special Functions .25 8. Response Attributes and Return Codes. . . . . . . 37 6.4.3. Collection Timers . . . . . .27 8.1 Mechanism. . . . . . . . . . . . 39 6.4.4. Logging Caller DTMF Input . . . . . . . . . . . .27 8.2 <response> Attributes. . 42 6.4.5. Specifying DTMF Grammars . . . . . . . . . . . . . . . 42 6.4.6. Playcollect Response .28 9. Formal Syntax. . . . . . . . . . . . . . . . 44 6.4.7. Playcollect Examples . . . . . . . .29 9.1 Schema. . . . . . . . . 44 Van Dyke, et al. Expires September 1, 2006 [Page 2] Internet-Draft MSCML February 2006 6.5. Prompt and Record <playrecord> . . . . . . . . . . . . . . 46 6.5.1. Prompt Phase . . .29 10. IANA Considerations. . . . . . . . . . . . . . . . . . 46 6.5.2. Record Phase . .37 10.1 IANA Registration of MIME media type application/mediaservercontrol+xml. . . . . . . . . . . .37 11. Security Considerations. . . . . . . 48 6.5.3. Playrecord Response . . . . . . . . . . .37 12. References. . . . . . 50 6.5.4. Playrecord Examples . . . . . . . . . . . . . . . . . 50 6.6. Stop Request <stop> . .38 12.1 Normative References. . . . . . . . . . . . . . . . . 51 7. Call Leg Events . . .38 12.2 Informative References. . . . . . . . . . . . . . . . . . .38 Authors' Addresses. 52 7.1. Keypress Events . . . . . . . . . . . . . . . . . . . . .40 A. Contributors53 7.1.1. Keypress Subscription Examples . . . . . . . . . . . . 55 7.1.2. Keypress Notification Examples . . . . . . . . . . . . 57 7.2. Signal Events .40 B. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 59 7.2.1. Signal Event Examples . .40 Intellectual Property and Copyright Statements. . . . . . . .42. . . . . . 60 8. Managing Content <managecontent> . . . . . . . . . . . . . . . 62 8.1. Managecontent Attributes . . . . . . . . . . . . . . . . . 62 8.2. Managecontent Example . . . . . . . . . . . . . . . . . . 64 9. Fax Processing . . . . . . . . . . . . . . . . . . . . . . . . 65 9.1. Recording a Fax <faxrecord> . . . . . . . . . . . . . . . 65 9.2. Sending a Fax <faxplay> . . . . . . . . . . . . . . . . . 68 10. MSCML Response Attributes and Elements . . . . . . . . . . . . 70 10.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 70 10.2. Base <response> Attributes . . . . . . . . . . . . . . . . 70 10.3. Response Attributes and Elements for <configure_leg> . . . 71 10.4. Response Attributes and Elements for <play> . . . . . . . 72 10.4.1. Reporting Content Retrieval Errors . . . . . . . . . . 73 10.5. Response Attributes and Elements for <playcollect> . . . . 74 10.6. Response Attributes and Elements for <playrecord> . . . . 75 10.7. Response Attributes and Elements for <managecontent> . . . 77 10.8. Response Attributes and Elements for <faxplay> and <faxrecord> . . . . . . . . . . . . . . . . . . . . . . . 77 11. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 79 11.1. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 90 12.1. IANA Registration of MIME media type application/mediaservercontrol+xml . . . . . . . . . . . . 90 13. Security Considerations . . . . . . . . . . . . . . . . . . . 91 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92 14.1. Normative References . . . . . . . . . . . . . . . . . . . 92 14.2. Informative References . . . . . . . . . . . . . . . . . . 93 Appendix A. Regex Grammar Syntax . . . . . . . . . . . . . . . . 94 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 95 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 Intellectual Property and Copyright Statements . . . . . . . . . . 98 Van Dyke, et al. Expires September 1, 2006 [Page 3] Internet-Draft MSCML February 2006 1. Introduction This document describes the Media Server Control Markup Language (MSCML) and its usage. It describes payloads that one can send to a Media Server using standard SIP INVITE and INFO methods and the capabilities these payloads implement. RFC 4240 [2] describes Media Server SIP URI formats. Prior to MSCML, there was not a standard way to deliver SIP-based enhanced conferencing. Basic SIP constructs, such as described in RFC 4240 [2], serves simple n-way conferencing well. The SIP URI provides a natural mechanism for identifying a specific SIP conference, while INVITE and BYE methods elegantly implement conference join and leave semantics. However, enhanced conferencing applications also require features such as sizing and resizing, in- conference IVR operations (e.g., recording and playing participant names to the full conference) and conference event reporting. MSCML payloads within standard SIP methods realize these features. The structure and approach of MSCML satisfy the requirements set out in conferencing-framework [10]. In particular, MSCML serves as the interface between the conference factory and a centralized conference mixer. In this case, a media server has the role of the conference mixer. There are two broad classes of MSCML functionality. The first class includes primitives for advanced conferencing such as conference configuration, participant leg manipulation, and conference event reporting. The second class comprises primitives for interactive voice response (IVR). These include collecting DTMF digits and playing and recording multimedia content. MSCML fills the need for IVR and conference control with requests and responses over a SIP transport. VoiceXML [11] fills the need for IVR with requests and responses over a HTTP transport. This enables developers to use whatever model fits their needs best. In general, a Media Server offers services to SIP UAC's such as Application Servers, Feature Servers, and Media Gateway Controllers. See the IPCC Reference Architecture [12] for definitions of these terms. It is unlikely, but not prohibited, for end user SIP UAC's to have a direct signaling relationship with a media server. The term "client" is used in this document to generically refer to an entity that interacts with the Media Server using SIP and MSCML. The Media Server fulfills the role of the Media Resource Function (MRF) in the IP Multimedia Subsystem (IMS) [13] as described by 3GPP. MSCML and RFC 4240 [2], upon which MSCML builds, are specifically Van Dyke, et al. Expires September 1, 2006 [Page 4] Internet-Draft MSCML February 2006 focused on the Mr interface which supports interactions between application logic and the MRF. This document describes a working framework and protocol with which there is considerable implementation experience. Application developers and service providers have created several MSCML-based services since the availability of the initial version in 2001. This experience is highly relevant to the ongoing work of the IETF, particularly the SIP [24], SIPPING [25], MMUSIC [26], and XCON [27] work groups, the IMS [28] work in 3GPP and the CCXML work in the Voice Browser Work Group of the W3C. 2. MSCML Approach It is critically important to emphasize that the goal of MSCML is to provide an application interface that follows the SIP, HTTP, and XML development paradigm to foster easier and more rapid application deployment. This goal is reflected in MSCML in two ways. First, the programming model is that of peer to peer rather than master-slave. Importantly, this allows the media server to be used simultaneously for multiple applications rather than being tied to a single point of control. It also enables standard SIP mechanisms to be used for media server location and load-balancing. Second, MSCML defines constructs and primitives that are meaningful at the application level to ensure that programmers are not distracted by unnecessary complexity. For example, the mixing resource operates on constructs such as conferences and call participants rather than directly on individual media streams. The MSCML paradigm is important to the developer community, in that developers and operators conceptually write applications about calls, conferences, and call legs. For the majority of developers and applications this approach significantly simplifies and speeds development. 3. Use of SIP Request Methods As mentioned above, MSCML payloads may be carried in either SIP INVITE or INFO requests. The initial INVITE, which creates an enhanced conference, MAY include an MSCML payload. A subsequent INVITE to the same Request-URI joins a participant leg to the conference. This INVITE MAY include an MSCML payload. The initial INVITE which establishes an IVR session MUST not include an MSCML payload. The client sends all mid-call MSCML payloads for Van Dyke, et al. Expires September 1, 2006 [Page 5] Internet-Draft MSCML February 2006 conferencing and IVR via SIP INFO requests. The media server transports MSCML responses in the final response to the SIP INVITE containing the matching MSCML request or in a SIP INFO message. The only allowable final response to a SIP INFO containing a message body is a 200 OK, per RFC 2976 [3]. Therefore, if the client sends the MSCML request via SIP INFO, the media server responds with the MSCML response in a separate INFO request. In general, these responses are asynchronous in nature and require a separate transaction due to timing considerations. There has been considerable debate on the use of the SIP INFO method for any purpose. Our experience is that MSCML would not have been possible without it. At the time the first MSCML specification was published, the first SIP Event Notification draft had just been submitted as an individual submission. At that time, there was no mechanism to link SUBSCRIBE/NOTIFY to an existing dialog. This prevented its use in MSCML since all events occurred in an INVITE established dialog. And while SUBSCRIBE/NOTIFY was well suited for reporting conference events its semantics seemed inappropriate for modifying a participant leg or conference setting where the only "event" was the success or failure of the request. Lastly, since SIP INFO was an established RFC, most SIP stack implementations supported it at that time. We had few if any interoperability issues as a result. As it turns out, using NOTIFY is not appropriate, as the NOTIFY would be in response to an implicit subscription. The SIP and SIPPING lists have discussed the dangers of implicit subscription. Using SUBSCRIBE is not appropriate for two reasons. The first is semantic. The purpose of SUBSCRIBE is to register interest in User Agent state. However, using SUBSCRIBE for MSCML results in the SUBSCRIBE modifying the User Agent state. The second reason SUBSCRIBE is not appropriate is because MSCML is inherently call- based. The association of a SIP dialog with a call leg means MSCML can be incredibly straightforward. For example, if one used SUBSCRIBE or other SIP method to send commands about some context, one must identify that context somehow. Relating commands to the SIP dialog they arrive on defines the context for free. Moreover, it is conceptually easy for the developer. In order to guarantee interoperability with this specification, as well as with SIP User Agents that are unaware of MSCML, SIP UACs that wish to use MSCML services MUST specify a service indicator which supports MSCML in the initial INVITE. RFC 4240 [2] defines the service indicator "conf" which MUST be used for MSCML conferencing applications. The service indicator "ivr" MUST be used for MSCML Van Dyke, et al. Expires September 1, 2006 [Page 6] Internet-Draft MSCML February 2006 applications that do not require mixing services. The media server MUST support moving the call between services through sending the media server a BYE on the existing dialog and establishing a new dialog with an INVITE to the desired service. Media servers SHOULD support moving between services without requiring modification of the previously established SDP parameters. This is achieved by sending a re-INVITE on the existing dialog with the Request-URI modified to specify the new service desired by the client. This eliminates the need for the client to send an INVITE to the caller or gateway to establish new SDP parameters. The media server, as a SIP UAS, MUST respond appropriately to an INVITE which contains an MSCML body. If MSCML is not supported the media server MUST generate a 415 final response and include a list of the supported content types in the response per RFC 3261 [4]. The media server MUST also advertise its support of MSCML in responses to OPTIONS requests, by including "application/mediaservercontrol+xml" as a supported content type in an Accept header. This alleviates the major issues with using INFO for the transport of application data, namely the User Agent's proper interpretation of what is, by design, an opaque message request. 4. MSCML Design 4.1. Transaction Model To avoid undue complexity MSCML establishes two rules regarding MSCML usage. The first is that only one MSCML body may be present in a SIP request. The second is that each MSCML body may contain only one request or response. This greatly simplifies transaction management. MSCML syntax does provide for the unique identification of multiple requests in a single body part. However, this is not supported in this specification. Per the guidelines of RFC 3470 [14], MSCML bodies MUST be well formed and valid. MSCML is a direct request-response protocol. There are no provisional responses, only final responses. A request may, however, result in multiple notifications. For example, a request for active talker reports will result in a notification for each speaker set. This maps to the three major element trees for MSCML: <request>, <response>, and <notification>. Figure 1 shows a request body. Depending on the command, one can send the request in an INVITE or an INFO. Figure 2 shows a response Van Dyke, et al. Expires September 1, 2006 [Page 7] Internet-Draft MSCML February 2006 body. The SIP INFO method transports response bodies. Figure 3 shows a notification body. The SIP INFO method transports notifications. <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> ... request body ... </request> </MediaServerControl> Figure 1: MSCML Request Format <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <response> ... request body ... </response> </MediaServerControl> Figure 2: MSCML Response Format <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <notification> ... notification body ... </notification> </MediaServerControl> Figure 3: MSCML Notification Format MSCML requests MAY include a client defined ID attribute for the purposes of matching requests and responses. The values used for these IDs need only be unique within the scope of the dialog in which the requests are issued. 4.2. XML Usage In the philosophy of XML as a text-based description language, and not a programming language, MSCML makes the choice of many attribute values for readability by a human. Thus many attributes that would often be "boolean" instead take "yes" or "no" values. For example, what does 'report="false"' or 'report="1"' mean? However, 'report="yes"' is clearer: I want a report. Some programmers prefer the precision of a boolean. To satisfy both styles, MSCML defines an XML type, "yesnoType", that takes on the values "yes" and "no" as Van Dyke, et al. Expires September 1, 2006 [Page 8] Internet-Draft MSCML February 2006 well as "true", "false", "1", and "0". Many attributes in the MSCML schema have default values. In order to limit demands on the XML parser, MSCML applies these values at the protocol, not XML, level. The MSCML schema documents these defaults as XML annotations to the appropriate attribute. 4.2.1. MSCML Time Values For clarity, time values in MSCML are based on the time designations described in Cascading Style Sheets, level 2 (CSS2) Specification [15]. Their format consists of a number immediately followed by an optional time unit identifier of the form: ms: milliseconds (default) s: seconds If no time unit identifier is present the value MUST be interpreted to be in milliseconds. As extensions to [15] MSCML allows the string values "immediate" and "infinite" which have special meaning for certain timers. 5. Advanced Conferencing 5.1. Conference Model The advanced conferencing model is a star controller model, with both signaling and media directed to a central location. Figure 4 depicts a typical signaling relationship between end users' UAC's, a conference application server, and a media server. The document cc-conferencing [10] makes use of this model. The application server is an instantiation of the conference focus. The Media Server is an instantiation of the media mixer. Note that user- level constructs, such as event notifications, are in the purview of the application server. This is why, for example, the Media Server sends active talker reports using MSCML notifications, while the application server would instead use the conference package [16] for individual notifications to SIP user agents. Note that we do not recommend the use of the conference package for media server to application server notifications because none of the filtering and membership information is available at the media server. Van Dyke, et al. Expires September 1, 2006 [Page 9] Internet-Draft MSCML February 2006 +-------+ | UAC 1 |---\ Public URI +-------------+ +-------+ \ _____________| Application | / / | Server | Not shown: +-------+ / / +-------------+ RTP flows directly | UAC 2 |---/ / | Private between UAC's and +-------+ / | URI Media Server . / +--------------+ : / | | +-------+ / | Media Server | | UAC n |---/ | | +-------+ +--------------+ Figure 4: Conference Model Each UAC sends an INVITE to a Public Conference URI. Presumably, the client publishes this URI, or it is an ad hoc URI. In any event, the client generates a Private URI, following the rules specified by RFC 4240 [2]. That is, the URI is of the form: sip:conf=UniqueID@ms.example.net Where UniqueID is a unique conference identifier and ms.example.net is the host name or IP address of the media server. There is nothing to prevent the UAC's from contacting the media server directly. However, one would expect the owner of the media server to restrict who can use its resources. As for basic conferencing, described by RFC 4240 [2], the first INVITE to the media server with a UniqueID creates a conference. However, in advanced conferencing, the first INVITE MAY include a MSCML <configure_conference> payload rather than the SDP of a conference participant. The <configure_conference> payload conveys extended session parameters (e.g., number of participants) that SDP does not readily express but the media server must know to allocate the appropriate resources. When the conference is created by sending an INVITE containing a MSCML <configure_conference> payload the resulting SIP dialog is termed the "Conference Control Leg." This leg has several useful properties. The lifetime of the conference is the same as that of its control leg. This ensures that the conference remains in existence even if all participant legs leave or have not yet arrived. In addition, when the client terminates the Conference Control Leg the Media Server automatically terminates all participant legs. The Conference Control Leg is also used for for play or record operations to/from the entire conference and for active talker notifications. Full conference media operations and active talker report subscriptions MUST be performed on the Conference Control Leg. Van Dyke, et al. Expires September 1, 2006 [Page 10] Internet-Draft MSCML February 2006 Creation of a Conference Control Leg is RECOMMENDED because full advanced conferencing capabilities are not available without it. Clients MUST establish the Conference Control Leg in the initial INVITE that creates the conference; it cannot be created later. Once the client has created the conference with or without the Conference Control Leg, participants can be joined to the conference. This is achieved by the client directing an INVITE to the Private Conference URI for each participant. Using the example conference URI given above, this would be sip:conf=UniqueID@ms.example.net . 5.2. Configure Conference Request <configure_conference> The <configure_conference> request has two attributes that control the resources the Media Server sets aside for the conference. These attributes are described in Table 1. NOTE: In the attribute tables the column labeled "R/O" indicates whether the attribute is required (R) or optional (O). If the attribute is only required under certain conditions the value (O*) is placed in the column. In that case there will be a note in the description preceded by an asterisk that explains the cases where it is required. +------------------+---------+-----+--------------------------------+ | Attribute | Default | R/O | Description | +------------------+---------+-----+--------------------------------+ | reservedtalkers | | O* | The maximum number of talker | | | | | legs allocated for the | | | | | conference. *Required when | | | | | establishing the Conference | | | | | Control Leg but optional in | | | | | subsequent | | | | | <configure_conference> | | | | | requests. | | reserveconfmedia | yes | O | Controls allocation of | | | | | resources to enable playing or | | | | | recording to or from the | | | | | entire conference | +------------------+---------+-----+--------------------------------+ Table 1: Conference Attributes When the reservedtalkers+1st INVITE arrives at the media server, the media server MUST generate a 486 Busy Here response. NOTE: It would be symmetric to have a reservedlisteners parameter. However, the practical limitation on the Media Server is the number of talkers for a mixer to monitor. In either case, the Van Dyke, et al. Expires September 1, 2006 [Page 11] Internet-Draft MSCML February 2006 client regulates who gets in to the conference by either proxying the INVITEs from the user agent clients or metering to whom it gives the conference URI. For example, to create a conference with up to 120 active talkers and the ability to play audio into the conference or record portions or all of the conference full mix, the application server specifies both attributes, as shown in Figure 6. <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_conference reservedtalkers="120" reserveconfmedia="yes"/> </request> </MediaServerControl> Figure 6: 120 Speaker MSCML Example Figure 7 shows a conference with up to five active speakers without the capability to play or record audio into the conference. <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_conference reservedtalkers="5" reserveconfmedia="no"/> </request> </MediaServerControl> Figure 7: 5 Speaker MSCML Example In addition to these attributes a <configure_conference> request MAY contain a child <subscribe> element. The <subscribe> element is used to request notifications for conference wide active talker events. Detailed information regarding active talker events is contained in Section 5.7. The client MUST include a <configure_conference> request in the initial INVITE which establishes the conference when creating the Conference Control Leg. The client server MUST issue asynchronous commands, such as <play>, separately (i.e., in INFO messages) to avoid ambiguous responses. Media operations on the Conference Control leg are performed internally, with no need for external RTP streams. Accordingly, the Media Server does not expect RTP on the Conference Control Leg. Therefore, the client MUST send either no SDP or hold SDP in the INVITE request containing a <configure_conference> payload. The Van Dyke, et al. Expires September 1, 2006 [Page 12] Internet-Draft MSCML February 2006 Media Server MUST treat SDP with all media lines set to "inactive" or with connection addresses set to 0.0.0.0 (for backwards compatibility) as hold SDP. The Media Server sends a response when it has finished processing the <configure_conference> request. The format of the <configure_conference> response is detailed in Section 10.2. 5.3. Configure Leg Request <configure_leg> Conference legs have a number of properties the client server can modify. These are set using the <configure_leg> request. This request has the attributes and defaults shown in Table 2. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | type | talker | O | Consider this leg's audio for | | | | | inclusion in the output mix. | | | | | Alternative is "listener". | | dtmfclamp | yes | O | Remove detected DTMF digit from the | | | | | input audio. | | toneclamp | yes | O | Remove tones from the input audio. | | | | | Tones include call progress tones and | | | | | the like. | | mixmode | full | O | Be a candidate for the full mix. | | | | | Alternatives are "mute" to not allow | | | | | audio in the mix, "parked" to remove | | | | | any media streams from the leg, | | | | | "preferred" to give this stream | | | | | preferential selection in the mix | | | | | (i.e., even if not loudest talker, | | | | | include media, if present, from this | | | | | leg in the mix) and "private" which | | | | | enables personalized mixes. | +-----------+---------+-----+---------------------------------------+ Table 2: Conference Leg Attributes In addition to these attributes, there are four child elements defined for <configure_leg>. These are <inputgain>, <outputgain>, <configure_team> and <subscribe>. The first two, <inputgain> and <outputgain>, modify the gain applied to the input and output audio streams respectively. These may contain <auto>, to use automatic gain control (AGC) or <fixed>. The <auto> element has the attributes "startlevel", "targetlevel", and "silencethreshold". All of the parameters are in dB. The <fixed> Van Dyke, et al. Expires September 1, 2006 [Page 13] Internet-Draft MSCML February 2006 element has the attribute "level", which is in dB. The default for both <inputgain> and <outputgain> is <fixed>. The Media Server MAY silently cap or ignore <inputgain> or <outputgain> requests which exceed the gain limits imposed by the platform. The <configure_team> element is used to create and manipulate groups for personalized mixes. Details of personalized mixes are discussed in Section 5.8. The <subscribe> element is used to request notifications for call leg related events such as asynchronous DTMF digit reports. Detailed information regarding call leg events is discussed in Section 7. If the default parameters are acceptable for the leg the client wishes to enter into the conference, then a normal SIP INVITE, with no MSCML body, is sufficient. However, if the client wishes to modify one or more of the parameters, the client can include a MSCML body in addition to the SDP body. The client can modify the conference leg parameters during the conference by issuing a SIP INFO on the dialog representing the conference leg. Of course, the client cannot modify SDP in an INFO message. The Media Server sends a response when it has finished processing the <configure_leg> request. The format of the <configure_leg> response is detailed in Section 10.3. 5.4. Terminating a Conference To remove a leg from the conference, the client issues a SIP BYE request on the selected dialog representing the conference leg. The client can terminate all legs in a conference by issuing a SIP BYE request on the Conference Control Leg. If one or more participants are still in the conference when the media server receives a SIP BYE request on the Conference Control Leg, the media server issues SIP BYE requests on all of the remaining conference legs to ensure clean up of the legs. The media server returns a 200 OK to the SIP BYE request as it sends BYE requests to the other legs. This is because we cannot issue a provisional response to a non-INVITE request, yet the teardown of the other legs may exceed the retransmission timer limits of the original request. While the conference is being cleaned up the Media Server MUST reject any new INVITEs to the terminated conference with a 486 Busy Here response. This response indicates that the specified conference cannot accept new participants. Van Dyke, et al. Expires September 1, 2006 [Page 14] Internet-Draft MSCML February 2006 5.5. Conference Manipulation Once the conference has begun, the client can manipulate the conference as a whole or a particular participant leg by issuing commands on the associated SIP dialog. For example, by sending MSCML requests on the Conference Control Leg the client can request the media server to record the conference, play a prompt to the conference or request reports on active talker events. Similarly, the client may mute a participant leg, configure a personalized mix or request reports for call leg events such as DTMF keypresses. Figure 8 and Figure 9 show two sample commands. The first plays a prompt into the conference. The second records the entire conference to the URL specified by the 'recurl' attribute. This "file://" URL scheme happens to do the write over NFS, per configuration at the media server. NOTE: The provisioning of NFS mount points and their mapping to the "file://" schema is purely a local matter at the media server. <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <play> <prompt> <audio url="http://prompts.example.net/en_US/welcome.au"/> </prompt> </play> </request> </MediaServerControl> Figure 8: Full Conference Audio Command - Play <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <playrecord recurl="file://archive.example.net/archives/011208.au" beep="no" initsilence="infinite" endsilence="infinite" duration="infinite"/> </request> </MediaServerControl> Figure 9: Full Conference Audio Command - Record The response to this last request will be similar to the one shown in Figure 10. Van Dyke, et al. Expires September 1, 2006 [Page 15] Internet-Draft MSCML February 2006 <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <response request="playrecord" code="200" text="OK" playduration="0" playoffset="0" reclength="1420374" recduration="177540"/> </MediaServerControl> Figure 10: Sample Change Command Response A client can modify a leg by issuing an INFO on the dialog associated with the participant leg. For example, Figure 11 mutes a conference leg. <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_leg mixmode="mute"/> </request> </MediaServerControl> Figure 11: Sample Change Leg Command In Figure 8, we saw a request to play a prompt to the entire conference. The client can also request to play a prompt to an individual call leg. In that case, the MSCML request is issued within the SIP dialog of the desired conference participant. Section 6 describes the interactive voice response (IVR) services offered by MSCML. If an IVR command arrives on the control channel, it takes effect on the whole conference. This is a mechanism for playing prompts to the entire conference (e.g., announcing new participants). If an IVR command arrives on an individual leg, it only affects that leg. This is a mechanism for interacting with users, such as the creation of "waiting rooms", allowing a user to mute themselves using key presses, allowing a moderator to out-dial, etc. A participant leg MUST be configured with mixmode="parked" prior to the issuance of any IVR commands with prompt content ('prompturl' attribute or <prompt> element). Parking the leg isolates the participant's input and output media from the conference and allows use of those streams for playing and recording purposes. However, the mixmode has no effect if just digit collection or recording is desired. <playcollect> and <playrecord> requests without prompt content MAY be sent on participant legs without setting mixmode="parked". Van Dyke, et al. Expires September 1, 2006 [Page 16] Internet-Draft MSCML February 2006 5.6. Video Conferencing MSCML controlled advanced conferences as well as RFC 4240 [2] controlled basic conferences implicitly support video conferencing in the form of video switching. In video switching the video stream of the loudest talker (with some hysteresis) is sent to all participants other than that talker. The loudest talker receives the video stream from the immediately prior loudest talker. Media Servers MUST ensure that participants receive video media compatible with their session. For example, a participant who has established an H.263 video stream will not receive video from another participant employing H.264 media. Media Servers SHOULD implement video transcoding to minimize media incompatibilities between participants. The Media Server MUST switch video streams only when it receives a refresh video frame. A refresh frame contains all of the video information required to decode that frame (i.e. there is no dependency on data from previous video frames). Refresh frames are large and generally sent infrequently to conserve network bandwidth. The Media Server MUST implement standard mechanisms to request that the new loudest talker's video encoder transmits a refresh frame to ensure video can be switched quickly. 5.7. Conference Events A client can subscribe for periodic active talker event reports which indicate which participants are included in the conference mix. As these are conference level events the subscription and notifications are sent on the Conference Control Leg. Media Servers MAY impose limits on the minimum interval for active talker reports for performance reasons. If the client request is below the imposed minimum the Media Server SHOULD set the interval to the minimum value supported. To limit unnecessary notification traffic the Media Server SHOULD NOT send a report if the active talker information for the conference has not changed during the reporting interval. A request for an active talker report is in Figure 12. The active talker report enumerates the current call legs in the mix. Van Dyke, et al. Expires September 1, 2006 [Page 17] Internet-Draft MSCML February 2006 <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_conference> <subscribe> <events> <activetalkers report="yes" interval="60s"/> </events> </subscribe> </configure_conference> </request> </MediaServerControl> Figure 12: Active Talker Request Event notifications are sent in SIP INFO messages. Figure 13 shows an example report. <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <notification> <conference uniqueid="ab34h76z" numtalkers="47"> <activetalkers> <talker callid="myhost4sn123"/> <talker callid="myhost2sn456"/> <talker callid="myhost12sn78"/> </activetalkers> </conference> </notification> </MediaServerControl> Figure 13: Active Talker Event Example The value of the "callid" attribute in the <talker> element corresponds to the value of the SIP Call-ID header of the associated dialog. This enables the client to associate the active talker with a specific participant leg. 5.8. Conferencing With Personalized Mixes MSCML enables clients to create personalized mixes through the <configure_team> element for scenarios where the standard mixmode settings do not provide sufficient control. The <configure_team> element is a child of <configure_leg>. To create personalized mixes the client has to identify the relationships among the participants. This is accomplished by manipulating two MSCML objects. These objects are: Van Dyke, et al. Expires September 1, 2006 [Page 18] Internet-Draft MSCML February 2006 o The list of team members (<teammate> elements) set using <configure_team> o The mixmode attribute set through <configure_leg> The media server uses the values of these objects to determine which audio inputs to combine for output to the participant. In a normal conference, each participant hears the conference mix minus their own input if they are part of the mixed output. The team list enables the client to specify other participants that the leg can hear in addition to the normal mixed output. Note that personalized mix settings apply only to audio media and do not affect video switching. Team relationships are implicitly symmetric. If the client sets participant A as a team member of participant B, then the media server automatically sets participant B as a team member for A. The id attribute set through <configure_leg> is used to identify the various participants. A unique ID MUST be assigned to each participant included in a personalized mix. The ID's used MUST be unique within the scope of the conference in which they appear. By itself, the team list only defines those participants that the leg can hear. The mixmode attribute of each team member determines whether to include their audio input in the personalized mix. If the client sets the teammate's mixmode to private, then it is part of the mix. If the mixmode is set to any other value, it is not. 5.8.1. MSCML Elements and Attributes for Personalized Mixes Control of personalized mixes rely on two major MSCML elements. o <configure_leg> using the mixmode attribute, mixmode="private" o <configure_team> The <configure_team> element allows the user to make the participants members of a team within a specific conference. It is a child of the <configure_leg> parent element. The client sends the <configure_team> element in a <configure_leg> request in either a SIP INVITE or SIP INFO. o In an INVITE to join a participant whose properties differ from the properties established for the conference as a whole. o In an INFO to change the properties for an existing leg. The two attributes of the configure_team element are "id" and "action". The id attribute MUST contain the unique ID of the leg being modified, as set in the original <configure_leg> request. The action attribute can take on the values "add", "delete", "query", and "set". The default value is "query". This attribute allows the user Van Dyke, et al. Expires September 1, 2006 [Page 19] Internet-Draft MSCML February 2006 to modify the team list. Table 3 describes the actions that can be performed on the team list. +--------+----------------------------------------------------------+ | Action | Description | +--------+----------------------------------------------------------+ | add | Adds a teammate to the mix. | | delete | Deletes a teammate from the mix. | | query | Returns the teammate list to the requestor. This is the | | | default value. | | set | Creates a team list when followed by <teammate id="n"> | | | and also removes all the teammates from the team list | | | for example, when the creator (originator) of the team | | | list on that specific conference leg wants to remove all | | | of the teammates from the team. If the set operation | | | removes all teammates from a participant, that | | | participant hears the full conference mix. | +--------+----------------------------------------------------------+ Table 3: Configure Team Actions 5.8.2. Example Usage of Personalized Mixes A common use of personalized mixing is to support coaching of one participant by another. The coaching scenario includes three participants: o Coach (supervisor) who coaches the agent o Agent who interacts with the client o Client (customer) who receives advice from the agent Table 4 illustrates the details of the coached conference topology. +-------------+------------+------------+---------+-----------------+ | Participant | ID | Team | Mixmode | Hears | | | | Members | | | +-------------+------------+------------+---------+-----------------+ | Supervisor | supervisor | Agent | Private | customer + | | | | | | agent | | Agent | agent | Supervisor | Full | customer + | | | | | | supervisor | | Customer | customer | none | Full | agent | +-------------+------------+------------+---------+-----------------+ Table 4: Coached Conference Example To create this topology, the client performs the followng actions: Van Dyke, et al. Expires September 1, 2006 [Page 20] Internet-Draft MSCML February 2006 1. Join each leg to the conference, being certain to include a unique ID in the <configure_leg> request. The leg ID needs to be unique only within the scope of the conference to which it belongs. 2. Configure the teammate list and mixmode of each participant as required. Both actions (step 1 and 2) may be combined in a single MSCML request. The following sections detail these actions and their corresponding MSCML payloads. 5.8.2.1. Create the Conference Before joining any participants, the client must create the conference by sending a SIP INVITE which contains an MSCML <configure_conference> request with a unique conference identifier. 5.8.2.2. Joining and Configuring the Coach Join the coach leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to supervisor and its mixmode to private. The corresponding MSCML request is as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg id="supervisor" mixmode="private"/> </request> </MediaServerControl> Figure 14: Join Coach Request The media server responds as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="configure_leg" code="200" text="OK"/> </MediaServerControl> Figure 15: Join Coach Response Table 5 depicts the conference configuration after the coach has been joined. Van Dyke, et al. Expires September 1, 2006 [Page 21] Internet-Draft MSCML February 2006 +-------------+------------+--------------+---------+---------+ | Participant | ID | Team Members | Mixmode | Hears | +-------------+------------+--------------+---------+---------+ | Supervisor | supervisor | none | Private | Silence | +-------------+------------+--------------+---------+---------+ Table 5: Conference After Joining the Coach Note that the client cannot configure the teammate list for the coach yet because there are no other participants in the conference. One must join a participant to the conference before one can add it as a teammate for another leg. 5.8.2.3. Joining and Configuring the Agent Join the agent leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element sets the leg's unique ID to "agent" and sets the supervisor as a team member of the agent. Because team member relationships are symmetric, this action also adds the agent as a team member for the coach. The corresponding MSCML request is as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg id="agent"> <configure_team action="set"> <teammate id="supervisor"/> </configure_team> </configure_leg> </request> </MediaServerControl> Figure 16: Join Agent Request Because the desired mixmode for this leg is full, which is the default value, there is no need to set it explicitly. The media server responds as follows. Van Dyke, et al. Expires September 1, 2006 [Page 22] Internet-Draft MSCML February 2006 <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="configure_leg" code="200" text="OK"> <team id="agent" numteam="1"> <teammate id="supervisor"/> </team> </response> </MediaServerControl> Figure 17: Join Agent Response Table 6 shows the conference configuration after the agent has been joined. +-------------+------------+--------------+---------+------------+ | Participant | ID | Team Members | Mixmode | Hears | +-------------+------------+--------------+---------+------------+ | Supervisor | supervisor | agent | Private | agent | | Agent | agent | supervisor | Full | supervisor | +-------------+------------+--------------+---------+------------+ Table 6: Conference After Joining Agent 5.8.2.4. Joining and Configuring the Client Join the client leg to the conference and configure its desired properties by sending a SIP INVITE containing a <configure_leg> request. The <configure_leg> element simply sets the leg's unique ID to "customer." The media server does not need further configuration because the desired mixmode, full, is the default and the customer has no team members. The corresponding MSCML request is as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg id="customer"/> </request> </MediaServerControl> Figure 18: Join Client Request Strictly speaking, it is not a requirement that the client give the customer leg a unique ID because it will not be a team member. However, when using coached conferencing, we RECOMMEND one assign a unique ID to each leg in the initial INVITE request. Assigning a unique ID eliminates the need to set it later by sending a SIP INFO if one later desires personalized mixing for the customer leg. Van Dyke, et al. Expires September 1, 2006 [Page 23] Internet-Draft MSCML February 2006 After receiving the previous MSCML request, the media server responds as follows. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="configure_leg" code="200" text="OK"/> </MediaServerControl> Figure 19: Join Client Response Table 7 illustrates the final conference configuration. +-------------+------------+------------+---------+-----------------+ | Participant | ID | Team | Mixmode | Hears | | | | Members | | | +-------------+------------+------------+---------+-----------------+ | Supervisor | supervisor | agent | Private | customer + | | | | | | agent | | Agent | agent | supervisor | Full | customer + | | | | | | supervisor | | Customer | customer | none | Full | agent | +-------------+------------+------------+---------+-----------------+ Table 7: Final Coached Conference Configuration 5.8.2.5. Response to Configure Team With Query Action If the action attribute of <configure_team> has the value "query" the media server responds with the current list of team members and their number. The numteam attribute in the response indicates how many members are on the team. The following example shows that there is one team member, identified as "agent", on the team for the participant identified as "super." <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="configure_leg" code="200" text="OK"> <team id="supervisor" numteam="1"> <teammate id="agent"/> </team> </response> </MediaServerControl> Figure 20: Number of Team Members If the MSCML <configure_team> specifies an invalid ID, the media server MUST ignore the invalid ID and treat the request as a query. Van Dyke, et al. Expires September 1, 2006 [Page 24] Internet-Draft MSCML February 2006 5.8.2.6. Exiting the Conference When the agent hangs up, the client removes the agent's leg from the supervisor's team list and from the entire conference. This process works exactly like the BYE method; the media server does not send a message to other members of the conference. The media server does not keep track of old team lists or names of old team lists. Former team members must re-join using the MSCML <configure_team> element as previously described. 6. Interactive Voice Response (IVR) In the IVR model, the Media Server acts as a media processing proxy for the UAC. This is particularly useful when the UAC is a media gateway or other device with limited media processing capability. The typical use case for MSCML is when there is an application server that is the MSCML client. The client can use the SIP Service URI concept (RFC 3087) to initiate a service. The client then uses RFC 4240 [2] to initiate a MSCML session on a media server. These relationships are shown in Figure 21. SIP +--------------+ Service URI | Application | /---------------| Server | /(e.g., RFC3087) +--------------+ / | MSCML / SIP | Session / +--------------+ +-----+/ RTP | | | UAC |=====================| Media Server | +-----+ | | +--------------+ Figure 21: IVR Model The IVR service supports basic Interactive Voice Response functions, playing announcements, collecting DTMF digits, and recording, based on Media Server Control Markup Language (MSCML) directives added to the message body of a SIP request. The major MSCML IVR requests are <play>, <playcollect> and <playrecord>. Multifunction media servers MUST use the URI conventions described in RFC 4240 [2]. The service indicator for MSCML IVR MUST be set to "ivr" as shown in the following example. sip:ivr@ms.example.net Van Dyke, et al. Expires September 1, 2006 [Page 25] Internet-Draft MSCML February 2006 The VoiceXML IVR service indicator is "dialog". This service indicator MUST not be used for any other interactive voice response control mechanism. The Media Server MUST accept MSCML IVR payloads in INFO requests and MUST NOT accept MSCML IVR payloads in the initial or subsequent INVITEs. The INFO method reduces certain timing issues that occur with INVITEs and requires less processing on both the client and Media Server. The Media Server notifies the client that the command has completed through a <response> message containing final status information and associated data such as collected DTMF digits. The Media Server does not queue IVR requests. If the Media Server receives a new IVR request while another is in progress, the media server stops the first operation and it carries out the new request. The Media Server generates a <response> message for the first request and returns any data collected up to that point. If a client wishes to stop a request in progress but does not wish to initiate another operation, it issues a <stop> request. This also causes the Media Server to generate a <response> message. The Media Server treats a SIP re-INVITE which modifies the established SDP parameters as an implicit <stop> request. Examples of such SDP modifications are receiving hold SDP or removing an audio or video stream. When this occurs the Media Server immediately terminates the running <play>, <playcollect> or <playrecord> request, and sends a <response>, indicating "reason=stopped". 6.1. Specifying Prompt Content The MSCML IVR requests support two methods of specifying content to be delivered to the user. These are the <prompt> element and the prompturl attribute. Clients MUST NOT utilize both methods in a single IVR request. Clients SHOULD use the more flexible <prompt> mechanism. Use of the prompturl attribute is deprecated and may not be supported in future MSCML versions. 6.1.1. Use of the Prompt Element The <prompt> element MAY be included in the body of a <play>, <playcollect>, or <playrecord> request to specify a prompt sequence to be delivered to the caller. The prompt sequence consists of one or more references to physical content files, spoken variables or dynamic URLs which return a sub-sequence of files or variables. Figure 23 shows a sample prompt block. Van Dyke, et al. Expires September 1, 2006 [Page 26] Internet-Draft MSCML February 2006 <prompt stoponerror="yes" baseurl="file:////var/mediaserver/prompts/" locale="en_US" offset="0" gain="0" rate="0" delay="0" duration="infinite" repeat="1"> <audio url="num_dialed.raw" encoding="ulaw"/> <variable type="dig" subtype="ndn" value="3014170700"/> <audio url="num_invalid.wav"/> <audio url="please_check.wav"/> </prompt> Figure 23: Prompt Block Example Table 8 describes the attributes of the <prompt> element and their uses. +-------------+----------+-----+------------------------------------+ | Attribute | Default | R/O | Description | +-------------+----------+-----+------------------------------------+ | baseurl | | O | For notational convenience as well | | | | | as reducing the MSCML payload | | | | | size, the "baseurl" attribute is | | | | | used to specify a base URL which | | | | | is prepended to any other URLs in | | | | | the sequence which are not fully | | | | | qualified. | | delay | 0 | O | The "delay" attribute to the | | | | | prompt element specifies the time | | | | | to pause between repetitions of | | | | | the <prompt> sequence. It has no | | | | | effect on the first iteration of | | | | | the sequence. Expressed as a time | | | | | value (Section 4.2.1) from 0 | | | | | onwards. | | duration | infinite | O | The "duration" attribute to the | | | | | prompt element controls the | | | | | maximum amount of time which may | | | | | elapse while media server repeats | | | | | the sequence. This allows the | | | | | client to set an upper bound on | | | | | the length of play. Expressed as a | | | | | time value (Section 4.2.1) from 1 | | | | | onwards or the strings "immediate" | | | | | and "infinite". "Infinite" directs | | | | | the Media Server to end play | | | | | immediately whereas "infinite" | | | | | indicates that the Media Server | | | | | imposes no limit. | Van Dyke, et al. Expires September 1, 2006 [Page 27] Internet-Draft MSCML February 2006 | gain | 0 | O | Sets the absolute gain to be | | | | | applied to the content contained | | | | | in <prompt>. The value of this | | | | | attribute is specified in units of | | | | | dB. The level reverts back to its | | | | | original value when playback of | | | | | the content contained in <prompt> | | | | | has completed. | | gaindelta | 0 | O | Sets the relative gain to be | | | | | applied to the content contained | | | | | in <prompt>. The value of this | | | | | attribute is specified in units of | | | | | dB. The level reverts back to its | | | | | original value when playback of | | | | | the content contained in <prompt> | | | | | has completed. | | rate | 0 | O | Specifies the absolute playback | | | | | rate of the content relative to | | | | | normal as either a positive | | | | | percentage (faster) or negative | | | | | percentage (slower). Any value | | | | | that attempts to set the rate | | | | | above the maximum allowed or below | | | | | the minimum allowed silently sets | | | | | the rate to the maximum or | | | | | minimum. The rate reverts back to | | | | | its original value when playback | | | | | of the content contained in | | | | | <prompt> has completed. | | ratedelta | 0 | O | Specifies the playback rate of the | | | | | content relative to it's current | | | | | rate as either a positive | | | | | percentage (faster) or negative | | | | | percentage (slower). Any value | | | | | that attempts to set the rate | | | | | above the maximum allowed or below | | | | | the minimum allowed silently sets | | | | | the rate to the maximum or | | | | | minimum. The rate reverts back to | | | | | its original value when playback | | | | | of the content contained in | | | | | <prompt> has completed. | Van Dyke, et al. Expires September 1, 2006 [Page 28] Internet-Draft MSCML February 2006 | locale | | O | Specifies the language and country | | | | | variant used when resolving spoken | | | | | variables. The language is defined | | | | | as a two-letter code per ISO 639. | | | | | The country variant is also | | | | | defined as a two-letter code per | | | | | ISO 3166. These codes are | | | | | concatenated with a single | | | | | underscore (%x5F) character. | | offset | 0 | O | A time value (Section 4.2.1) which | | | | | specifies the time from the | | | | | beginning of the sequence at which | | | | | play is to begin. Offset only | | | | | applies to the first repetition; | | | | | subsequent repetitions begin play | | | | | at offset 0. Allowable values are | | | | | positive time values from 0 | | | | | onwards. When the sequence | | | | | consists of multiple content files | | | | | the offset may select any point in | | | | | the sequence. If the offset value | | | | | is greater than the total time of | | | | | the sequence it will "wrap" to the | | | | | beginning and continue from there | | | | | until the media server reaches the | | | | | specified offset. | | repeat | 1 | O | The "repeat" attribute to the | | | | | prompt element controls the number | | | | | of times the media server plays | | | | | the sequence in the <prompt> | | | | | element. Allowable values are | | | | | integers from 0 on and the string | | | | | "infinite" which indicates | | | | | repetition should occur | | | | | indefinitely. For example, | | | | | "repeat=2" means the sequence will | | | | | be played twice and "repeat=0", | | | | | which is allowed, means the | | | | | sequence is not played. | Van Dyke, et al. Expires September 1, 2006 [Page 29] Internet-Draft MSCML February 2006 | stoponerror | no | O | Controls media server handling and | | | | | reporting of errors encountered | | | | | when retrieving remote content. If | | | | | set to "yes" content play will end | | | | | if a fetch error occurs and the | | | | | response will contain details | | | | | regarding the failure. If set to | | | | | "no" the media server will | | | | | silently move on to the next URL | | | | | in the sequence if a fetch failure | | | | | occurs. | +-------------+----------+-----+------------------------------------+ Table 8: Prompt Attributes Clients MUST NOT include both 'gain' and 'gaindelta' attributes within a single <prompt> element. Media server's SHOULD support rate controls for content. However, media servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <prompt> element. 6.1.1.1. <audio> and <variable> Elements Clients compose prompt sequences using the the <audio> and <variable> elements. An <audio> element MAY refer to content which contains audio, video or both; the generic name is preserved for backwards compatibility. The <audio> element has four attributes as described in Table 9. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | url | | R | The URL of the content to be | | | | | retrieved and played. The target may | | | | | be a local or remote (NFS) "file://" | | | | | scheme URL or an "http://" or | | | | | "https://" scheme URL. If the URL is | | | | | not fully qualified and a "baseurl" | | | | | attribute was set the value of the | | | | | "baseurl" attribute will be prepended | | | | | to this value to generate the target | | | | | URL. | Van Dyke, et al. Expires September 1, 2006 [Page 30] Internet-Draft MSCML February 2006 | encoding | ulaw | O | Specifies the content encoding for | | | | | file formats that are not | | | | | self-describing (e.g. .WAV). | | | | | Allowable values are "ulaw", "alaw" | | | | | and "msgsm". This attribute only | | | | | affects "file://" scheme URLs. | | gain | 0 | O | Sets the absolute gain to be applied | | | | | to the content URL. The value of this | | | | | attribute is specified in units of | | | | | dB. The level reverts back to its | | | | | original value when playback of the | | | | | content URL has completed. | | gaindelta | 0 | O | Sets the relative gain to be applied | | | | | to the content URL. The value of this | | | | | attribute is specified in units of | | | | | dB. The level reverts back to its | | | | | original value when playback of the | | | | | content URL has completed. | | rate | 0 | O | Specifies the absolute playback rate | | | | | of the content relative to normal as | | | | | either a positive percentage (faster) | | | | | or negative percentage (slower). Any | | | | | value that attempts to set the rate | | | | | above the maximum allowed or below | | | | | the minimum allowed silently sets the | | | | | rate to the maximum or minimum. The | | | | | rate reverts back to its original | | | | | value when playback of the content | | | | | URL has completed. | | ratedelta | 0 | O | Specifies the playback rate of the | | | | | content relative to it's current rate | | | | | as either a positive percentage | | | | | (faster) or negative percentage | | | | | (slower). Any value that attempts to | | | | | set the rate above the maximum | | | | | allowed or below the minimum allowed | | | | | silently sets the rate to the maximum | | | | | or minimum. The rate reverts back to | | | | | its original value when playback of | | | | | the content URL has completed. | +-----------+---------+-----+---------------------------------------+ Table 9: Attributes of the Audio Element Clients MUST NOT include both gain and gaindelta attributes within a single <audio> element. Media server's SHOULD support rate controls for content. However, Van Dyke, et al. Expires September 1, 2006 [Page 31] Internet-Draft MSCML February 2006 Media Servers MAY silently ignore rate change requests if content limitations do not allow the request to be honored. Clients MUST NOT include both 'rate' and 'ratedelta' attributes within a single <audio> element. Media Server's MUST support local and remote (NFS) "file://" scheme URLs and "http://" and "https://" scheme URLs for content retrieval. NOTE: The provisioning of NFS mount points and their mapping to the "file://" schema is purely a local matter at the media server. MSCML also supports "http://" and "https://" scheme URLS that return a list of physical URLs using the "text/uri-list" MIME type. This facility provides flexibility for applications to dynamically generate prompt sequences at execution time and enables separation of this function from the client and Media Server. Spoken variables are specified using the <variable> element. This element has the attributes described in Table 10. MSCML's spoken variables are based on those described in Audio Server Protocol [17]. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | type | | R | Specifies the major type format of | | | | | the spoken variable to be played. | | | | | Allowable values are "dat" (date), | | | | | "dig" (digit), "dur" (duration), | | | | | "mth" (month), "mny" (money), "num" | | | | | (number), "sil" (silence), "str" | | | | | (string), "tme" (time) and "wkd" | | | | | (weekday). | | subtype | | O | Specifies the minor type format of | | | | | the spoken variable to be played. | | | | | Allowable values depend on the value | | | | | of the corresponding "type" | | | | | attribute. Possible values are "mdy", | | | | | "ymd" and "dmy" for dates, "t12" and | | | | | "t24" for times, "gen", "ndn", "crd" | | | | | and "ord" for digits and "USD" for | | | | | money. | | value | | R | A string that will be interpreted | | | | | based on the formatting information | | | | | specified in the "type" and "subtype" | | | | | attributes and the "locale" attribute | | | | | of the parent <prompt> element to | | | | | render the spoken variable. | +-----------+---------+-----+---------------------------------------+ Van Dyke, et al. Expires September 1, 2006 [Page 32] Internet-Draft MSCML February 2006 Table 10: Attributes of the Variable Element If the "locale" attribute was not specified in <prompt> the Media Server SHOULD make a selection based on platform configuration. If the precise "locale" requested cannot be honored the Media Server SHOULD select the closest match based on the available content. IVR applications normally require specialized prompt content which is authored by the application provider. To deliver a quality user interaction the specialized prompts and spoken variables must be generated by the same speaker. Since the Media Server inherently supports multiple simultaneous applications it is extremely difficult to provision all the necessary application prompts and matching spoken variable content locally on the Media Server. Therefore we STRONGLY RECOMMEND that clients employ the dynamic URL mechanism described earlier to generate spoken variables using an external web server that returns "text/uri-list" content. 6.2. Multimedia Processing for IVR MSCML IVR requests implicitly support multimedia content. Multimedia capabilities are controlled by the audio and video media negotiated for the dialog and the content specified by the client for play and record operations. If the content specified for delivery contains both audio and video tracks and the dialog has audio and video streams, both tracks are streamed to the caller. Likewise, if the dialog has both audio and video streams and the content format specified supports both (e.g. .3gp files) the Media Server records both streams to the file. If there is a mismatch between the real time media and specified content the Media Server MUST play or record the appropriate content tracks rather than failing the request. For example, if the client has requested playback of content with audio and video tracks but only audio media has been established for the dialog the Media Server should play the audio track. If the dialog has both audio and video media but the content is audio-only the Media Server MAY stream a pre-provisioned video track to the caller. Media Servers SHOULD implement video transcoding functions to minimize incompatibilities between real time media and content. The Media Server MUST begin recording video media only when it receives a refresh video frame. A refresh frame contains all of the video information required to decode that frame (i.e. there is no dependency on data from previous video frames). Refresh frames are large and generally sent infrequently to conserve network bandwidth. The Media Server MUST implement standard mechanisms to request that the caller (video encoder) transmit a refresh frame to ensure video Van Dyke, et al. Expires September 1, 2006 [Page 33] Internet-Draft MSCML February 2006 recording begins quickly. The Media Server MUST begin recording the audio track immediately while waiting to receive the video refresh frame. 6.3. Playing Announcements <play> The client issues a <play> request to play an announcement without interruption and with no digit collection. One use, for example, is to announce the name of a new participant to the entire conference. The <play> request has the attributes described in Table 11. +----------------+---------+-----+----------------------------------+ | Attribute | Default | R/O | Description | +----------------+---------+-----+----------------------------------+ | id | | O | Specifies a client defined ID | | | | | for purposes of matching | | | | | requests and responses. | | offset | 0 | O | Specifies the time from the | | | | | beginning of the URL specified | | | | | in the 'prompturl' attribute at | | | | | which play will begin. Expressed | | | | | as a time value (Section 4.2.1) | | | | | from 0 onwards. If the offset | | | | | value is greater than the total | | | | | time of the content it will | | | | | "wrap" to the beginning and | | | | | continue from there until the | | | | | media server reaches the | | | | | specified offset. NOTE: Use of | | | | | this attribute is deprecated. | | promptencoding | | O | Specifies the content encoding | | | | | for file formats that are not | | | | | self-describing (e.g. .WAV). | | | | | Allowable values are "ulaw", | | | | | "alaw" and "msgsm". This | | | | | attribute only affects "file://" | | | | | scheme URLs. NOTE: Use of this | | | | | attribute is deprecated. | | prompturl | | O | The URL of the content to be | | | | | retrieved and played. The target | | | | | may be a local or remote (NFS) | | | | | "file://" scheme URL or an | | | | | "http://" or "https://" scheme | | | | | URL. NOTE: Use of this attribute | | | | | is deprecated. | +----------------+---------+-----+----------------------------------+ Table 11: Attributes of the Play Request Van Dyke, et al. Expires September 1, 2006 [Page 34] Internet-Draft MSCML February 2006 The <play> request has one child element, <prompt>, defined. Use of <prompt> is described in Section 6.1.1. The client MUST NOT use both the <prompt> element and "prompturl" attribute in a single request. As previously discussed, the "prompturl" attribute is supported for backwards compatibility with older MSCML applications but its use is deprecated. The more flexible <prompt> element SHOULD be used instead. The following play request (Figure 24) example shows the delivery of a complex prompt sequence consisting of content accessed via NFS and and spoken variables. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <play id="332985001"> <prompt stoponerror="yes" baseurl="file:////var/mediaserver/prompts/" locale="en_US" offset="0" gain="0" rate="0" delay="0" duration="infinite" repeat="1"> <audio url="num_dialed.raw" encoding="ulaw"/> <variable type="dig" subtype="ndn" value="3014170700"/> <audio url="num_invalid.wav"/> <audio url="please_check.wav"/> </prompt> </play> </request> </MediaServerControl> Figure 24: <Play> Request Example When the announcement has finished playing, the Media Server sends a <response> payload to the client in a SIP INFO message. Details regarding the format of <play> responses are provided in Section 10.4. The following <play> response (Figure 25) example depicts a valid response to the previous request. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response id="332985001" request="play" code="200" text="OK" reason="EOF" playduration="12620" playoffset="12620"> </response> </MediaServerControl> Figure 25: <Play> Response Example Van Dyke, et al. Expires September 1, 2006 [Page 35] Internet-Draft MSCML February 2006 6.4. Prompt and Collect <playcollect> The client issues a <playcollect> request to optionally play an announcement and then collect digits. The <playcollect> request is executed in two phases, prompt and collect. If the client specifies prompt content to be played, using the <prompt> element or prompturl attribute, the media server plays the content before starting the collection phase. If no prompt content is specified the collect phase begins immediately. The basic attributes of <playcollect> are the same as those of <play> which were described in Section 6.3. In addition to these basic attributes, <playcollect> defines others which control digit buffering and barge-in behavior, collection timers, special purpose DTMF key functions and logging of user DTMF input. Each functional category and its attributes are described below. 6.4.1. Control of Digit Buffering and Barge-in Whenever the media server is processing a call which specifies an MSCML service (i.e. "conf" and "ivr"), the media server continuously looks for DTMF digits and places them in a quarantine buffer. The quarantine buffer is examined when a <playcollect> request is received. The media server compares any previously buffered digits for barge-in and to look for matches with DTMF grammars or special purpose keys. This provides the type-ahead behavior for menu traversal and other types of IVR interactions. +-------------+---------+-----+-------------------------------------+ | Attribute | Default | R/O | Description | +-------------+---------+-----+-------------------------------------+ | cleardigits | no | O | Specifies whether previous user | | | | | input should be considered or | | | | | ignored for barge-in purposes and | | | | | DTMF matching. When set to "yes" | | | | | any previously buffered digits are | | | | | removed so prior user input is | | | | | ignored. If set to "no" previously | | | | | buffered digits will be considered. | | | | | If "cleardigits" is set to "no" and | | | | | barge-in is enabled previously | | | | | buffered digits will result in the | | | | | prompt being barged immediately. In | | | | | this case the prompt is not played | | | | | and digit collection begins | | | | | immediately. | Van Dyke, et al. Expires September 1, 2006 [Page 36] Internet-Draft MSCML February 2006 | barge | yes | O | Specifies whether user input will | | | | | barge the prompt and force | | | | | transition to the collect phase. | | | | | When set to "yes" a DTMF input will | | | | | barge the prompt. When set to "no", | | | | | the prompt phase cannot be barged | | | | | and any user input during the | | | | | prompt is placed in the quarantine | | | | | buffer for inspection during the | | | | | collect phase. Note that If the | | | | | "barge" attribute is set to "no", | | | | | the "cleardigits" attribute | | | | | implicitly has a value of "yes". | | | | | This ensures the media server does | | | | | not leave DTMF input that occurred | | | | | prior to the current collection in | | | | | the quarantine buffer after the | | | | | request completes. | +-------------+---------+-----+-------------------------------------+ Table 12: Attributes for Control of Digit Buffering and Barge-in 6.4.2. Mapping DTMF Keys to Special Functions The client can define mappings between DTMF digits and special functions. The media server invokes the special function if the associated DTMF digit is detected. MSCML has two attributes which define mappings that affect termination of the collect phase. These attributes are described in Table 13. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | escapekey | * | O | Specifies a DTMF key that indicates | | | | | the user wishes to terminate the | | | | | current operation without saving any | | | | | input collected to that point. | | | | | Detection of the mapped DTMF key | | | | | terminates the request immediately | | | | | and generates a response. | Van Dyke, et al. Expires September 1, 2006 [Page 37] Internet-Draft MSCML February 2006 | returnkey | # | O | Specifies a DTMF key that indicates | | | | | the user has completed input and | | | | | wants to return all collected digits | | | | | to the client. When the media server | | | | | detects the returnkey, it immediately | | | | | terminates collection and returns the | | | | | collected digits to the client in the | | | | | <response> message. | +-----------+---------+-----+---------------------------------------+ Table 13: DTMF Key Mappings for Playcollect MSCML defines three additional mappings to enable video cassette recorder (VCR) type controls while playing a prompt sequence. Media servers SHOULD support VCR controls. However, if the media server does not support VCR controls, it MUST silently ignore DTMF inputs mapped to VCR functions and complete the <playcollect> request. The VCR control attributes are described in Table 14. +--------------+---------+-----+------------------------------------+ | Attribute | Default | R/O | Description | +--------------+---------+-----+------------------------------------+ | skipinterval | 6s | O | The "skipinterval" attribute | | | | | indicates how far the media server | | | | | should skip backwards or forwards | | | | | when the rewind key (rwkey) or | | | | | fast forward key (ffkey) is | | | | | pressed, specified as a time value | | | | | (Section 4.2.1). | | ffkey | | O | The "ffkey" attribute maps a DTMF | | | | | key to a fast forward operation | | | | | equal to the value of the | | | | | "skipinterval" attribute. | | rwkey | | O | The "rwkey" attribute maps a DTMF | | | | | key to a rewind action equal to | | | | | the value of the "skipinterval" | | | | | attribute. | +--------------+---------+-----+------------------------------------+ Table 14: Attributes for VCR Controls Clients MUST NOT map the same DTMF digit to both the "rwkey" and "ffkey" attributes in a single <playcollect> request. VCR control operations are bounded by the beginning and end of the prompt sequence. A rewind action which moves the offset before the beginning of the sequence results in playback starting at the beginning of the sequence (i.e. offset=0). A fast forward action Van Dyke, et al. Expires September 1, 2006 [Page 38] Internet-Draft MSCML February 2006 which moves the offset past the end of the seqence results in the media server treating the sequence as completed. 6.4.3. Collection Timers MSCML defines several timer attributes that control how long the media server waits for digits in the input sequence. All timer settings are in milliseconds. Table 15 describes these attributes and their use. +------------------------+----------------+-----+-------------------+ | Attribute | Default | R/O | Description | +------------------------+----------------+-----+-------------------+ | firstdigittimer | 5000ms | O | Specifies how | | | | | long the media | | | | | server waits for | | | | | the initial DTMF | | | | | input before | | | | | terminating the | | | | | collection. | | | | | Expressed as a | | | | | time value | | | | | (Section 4.2.1) | | | | | from 1 onwards or | | | | | the strings | | | | | "immediate" and | | | | | "infinite." The | | | | | value "immediate" | | | | | indicates that | | | | | the timer should | | | | | fire immediately | | | | | whereas | | | | | "infinite" | | | | | indicates the | | | | | timer will never | | | | | fire. | | interdigittimer | 2000ms | O | Specifies how | | | | | long the media | | | | | server waits | | | | | between DTMF | | | | | inputs. | Van Dyke, et al. Expires September 1, 2006 [Page 39] Internet-Draft MSCML February 2006 | extradigittimer | 1000ms | O | Specifies how | | | | | long the media | | | | | server waits for | | | | | additional user | | | | | input after the | | | | | specified number | | | | | of digits has | | | | | been collected. | | | | | Expressed as a | | | | | time value | | | | | (Section 4.2.1) | | | | | from 1 onwards or | | | | | the strings | | | | | "immediate" and | | | | | "infinite." The | | | | | value "immediate" | | | | | indicates that | | | | | the timer should | | | | | fire immediately | | | | | whereas | | | | | "infinite" | | | | | indicates the | | | | | timer will never | | | | | fire. | Van Dyke, et al. Expires September 1, 2006 [Page 40] Internet-Draft MSCML February 2006 | interdigitcriticaltime | value of the | O | Specifies how | | r | interdigittime | | long the Media | | | r attribute | | Server waits | | | | | after a grammar | | | | | has been matched | | | | | for a subsequent | | | | | digit that may | | | | | cause a longer | | | | | match. Expressed | | | | | as a time value | | | | | (Section 4.2.1) | | | | | from 1 onwards or | | | | | the strings | | | | | "immediate" and | | | | | "infinite." The | | | | | value "immediate" | | | | | results in | | | | | "shortest match | | | | | first" behavior | | | | | whereas | | | | | "infinite" means | | | | | wait indefinitely | | | | | for additional | | | | | input. If not | | | | | explicitly | | | | | specified this | | | | | attribute is set | | | | | to the value of | | | | | the | | | | | 'interdigittimer' | | | | | attribute. | +------------------------+----------------+-----+-------------------+ Table 15: Collection Timer Attributes The extradigittimer setting enables the "returnkey" input to be associated with the current collection. For example, if maxdigits is set to 3 and returnkey is set to #, the user may enter either "x#", "xx#" or "xxx#", where x represents a DTMF digit. If the media server detects the "returnkey" pattern during the "extradigit" interval, the media server returns the collected digits to the client and removes the "returnkey" from the digit buffer. If this were not the case, the example would return "xxx" to the client and leave the terminating "#" in the digit buffer. At the next <playcollect> request, the media server would process the '#'. This might result in the termination of the following prompt; clearly Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page3]41] Internet-Draft MSCMLDecember 2004 1. Introduction This document describesFebruary 2006 not what the user intended. The extradigittimer has no effect unless returnkey has been set. 6.4.4. Logging Caller DTMF Input Standard SIP mechanisms, such as those discussed in Security Considerations (Section 13) protect MSCML protocol exchanges and the information they contain. These protections do not apply to data captured in Media Server log files. In general Media Server logging is platform specific and therefore not covered by this specification. However, one aspect of logging, which is the capture of sensitive information such as personal identification numbers or credit card numbers, is relevant. The Media ServerControl Markup Language (MSCML). This document describes payloadshas no means to determine whether the DTMF input it receives may be sensitive as thatone can send withis in the purview of the client. Recognizing this, MSCML includes astandard SIP INVITEper- request mechanism toa media server. Basic Networksuppress logging of captured DTMF to be enabled by clients as needed. The "maskdigits" attribute controls whether detected DTMF digits appear in the log output. Clients use this attribute when the MediaServices with SIP [7] describesServer collects sensitive information that should not be accessible through the log files. +------------+---------+-----+--------------------------------------+ | Attribute | Default | R/O | Description | +------------+---------+-----+--------------------------------------+ | maskdigits | no | O | Controls whether user DTMF inputs | | | | | are captured in media serverSIP URI formats. Prior to MSCML, there was notlog | | | | | files. The possible values for this | | | | | attribute are "yes" and "no". | +------------+---------+-----+--------------------------------------+ Table 16: Maskdigits Attribute 6.4.5. Specifying DTMF Grammars MSCML supports four methods for specifying DTMF grammars: the "maxdigits" attribute, which provides astandard waysimple mechanism for collecting any number of digits up todeliver SIP-based enhanced conferencing. Basic SIP constructs, such as describedthe maximum, regular expressions, MGCP [5] digit maps, and H.248.1 [6] digit maps. A media server MUST support the maxdigits and regular expression methods for specifying DTMF grammars and SHOULD support MGCP and H.248.1 methods. A client MUST NOT mix DTMF grammar types inBasic Network Media Services with SIP [7], serves simple n-way conferencing well.a single <playcollect> request. Table 17 describes the details of the "maxdigits" attribute. Van Dyke, et al. Expires September 1, 2006 [Page 42] Internet-Draft MSCML February 2006 +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | maxdigits | | O | Specifies the maximum number of DTMF | | | | | digits to be collected. | +-----------+---------+-----+---------------------------------------+ Table 17: Maxdigits Attribute TheSIP URI provides<pattern> element specifies anatural mechanismdigit pattern or patterns foridentifying a specific SIP conference, while INVITE and BYE methods elegantly implement conference join and leave semantics. However, enhanced conferencing applications also require features such as sizing and resizing, in-conference IVR operations (e.g., recording and playing participant namesthe media server to look for. This element may contain three different child elements which specify thefull conference) and conference event reporting.type of DTMF grammar used in the expression. The <pattern> element has no attributes. <regex> Use regular expressions to define DTMF patterns to match. The complete regular expression syntax used in MSCMLpayloads within standard SIP methods realize these features.is described in Appendix A. <mgcpdigitmap> Use digit maps as specified in MGCP [5]. <megacodigitmap> Use digit maps as specified in H.248.1 [6]. At least one <regex> element MUST be present in <pattern> when regex grammars are used. Multiple <regex> elements MAY be present. When <mgcpdigitmap> or <megacodigitmap> grammars are used <pattern> MUST contain only one grammar element. ThestructureDTMF grammar elements <regex>, <mgcpdigitmap>, andapproach of MSCML satisfy<megacodigitmap> have therequirements set outattributes described in Table 18. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | value | | R | Specifies a string representing a | | | | | DTMF grammar matching the parent | | | | | element type (e.g. regex). Regex | | | | | values represent a single DTMF | | | | | grammar. MGCP and MEGACO digit maps | | | | | allow multiple grammars to be | | | | | described in a single string. | | name | | O | Associates a client defined name for | | | | | grammar string which is sent back inconferencing-framework [8]. In particular, MSCML serves| | | | | the <playcollect> response. This | | | | | attribute is most useful with regex | | | | | type grammars as each grammar element | | | | | can have a unique name. | +-----------+---------+-----+---------------------------------------+ Table 18: Attributes of DTMF Grammar Elements Van Dyke, et al. Expires September 1, 2006 [Page 43] Internet-Draft MSCML February 2006 6.4.6. Playcollect Response When theinterface between<playcollect> has finished playing, theconference factory and a centralized conference mixer. In this case,Media Server sends amedia server has<response> payload to theroleclient in a SIP INFO message. Details of theconference mixer. There<playcollect> response aretwo broad classesdescribed in Section 10.5. 6.4.7. Playcollect Examples The following <playcollect> request (Figure 26) example depicts use ofMSCML functionality.the "maxdigits" attribute to control digit collection. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <playcollect id="332986004" maxdigits="6" firstdigittimer="10000" interdigittimer="5000" extradigittimer="1000" interdigitcriticaltimer="1000" returnkey="#" escapekey="*" cleardigits="no" barge="yes" maskdigits="no"> <prompt baseurl="http://www.example.com/prompts/"> <audio url="generic/en_US/enter_pin.wav"/> </prompt> </playcollect> </request> </MediaServerControl> Figure 26: <Playcollect> Request Example Using Thefirst class includes primitives for advanced conferencing suchMaxdigits Attribute If the caller entered the six DTMF characters "196452" without exceeding any collection timers the response would be asconference configuration, participant leg manipulation and conference event reporting.shown in Figure 27. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="playcollect" id="332986004" code="200" text="OK" reason="match" digits="196452" playduration="1980"> </response> </MediaServerControl> Figure 27: <Playcollect> Response Example Using Thesecond class comprises primitives for interactive voice response (IVR). These include playing audio, collecting digits, and recording audio.Maxdigits Attribute TheIVR featuresfollowing example payloads depict the use ofMSCML began as an adjunct for conferencing. In many scenarios it was impractical or inconvenientregular expressions (Figure 28) toestablish a dialog with a distinct IVR resource and then re-join the conference. Over time, many SIP Proxy Servers, Media Gateway Controllers, and SIP-based applications have used MSCML for simple IVR such as prompt-and-collect. Do note thatcontrol digit collection and two possible responses which differ due to caller input. The <playcollect> request defines two named digit patterns forcomplex IVR it may be more appropriatethe Media Server toemploy a full IVR markup language suchmatch. The first pattern, identified asVoiceXML [9]. In general, a media server offers services"pin" consists of 4 toSIP UAC's such6 DTMF characters. The second pattern, identified asapplication servers, feature servers, and media gateway controllers. See the IPCC Reference Architecture [10] for definitions"help", consists ofthese terms. It is unlikely, but not prohibited, for end user SIP UAC's to have a direct signaling relationship with a media server. This document describesaworking framework and protocol with whichsingle "0" character. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page4]44] Internet-Draft MSCMLDecember 2004 there is considerable implementation experience. Application developers and service providers have created several MSCML-based services sinceFebruary 2006 <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <playcollect id="332986004" firstdigittimer="10000" interdigittimer="5000" extradigittimer="1000" interdigitcriticaltimer="1000" returnkey="#" escapekey="*" cleardigits="no" barge="yes" maskdigits="no"> <prompt baseurl="http://www.example.com/prompts/"> <audio url="generic/en_US/enter_pin.wav"/> </prompt> <pattern> <regex value="x{4,6}" name="pin"/> <regex value="0" name="help"/> </pattern> </playcollect> </request> </MediaServerControl> Figure 28: <Playcollect> Request Example Using Regular Expressions If theinitial version was made available more than a year ago. This experience is highly relevant tocaller entered theongoing work ofDTMF string "1234" theIETF, particularly"pin" grammar would be matched. In that case theSIP [18], SIPPING [19], MMUSIC [20], and XCON [21] work groups, as wellcorresponding response would be asthe CCXML workshown in Figure 29. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="playcollect" id="332986004" code="200" text="OK" reason="match" digits="1234" name="pin" playduration="1980" playoffset="1980"> </response> </MediaServerControl> Figure 29: <Playcollect> Response Example Using Regular Expressions If theVoice Browser Work Group ofcaller pressed "0" theW3C. 2."help" grammar would be matched and the response would be as shown in Figure 30. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="playcollect" id="332986004" code="200" text="OK" reason="match" digits="0" name="help" playduration="1980" playoffset="1980"> </response> </MediaServerControl> Figure 30: <Playcollect> Response Example Using Regular Expressions Van Dyke, et al. Expires September 1, 2006 [Page 45] Internet-Draft MSCMLApproach It is critically importantFebruary 2006 6.5. Prompt and Record <playrecord> The <playrecord> request directs the media server toemphasizeconvert and possibly transcode thegoal of MSCML isthe RTP payloads it receives and store them toprovide a development environment that followstheSIP, HTTP,specified URL using the requested content codec(s) andXML development paradigm. That is,file format. This request proceeds in two phases; prompt and record. The <playrecord> request shares themixing resource is a server that operates on application level constructs such as call participants. Some developers may desire low-level of control over DSP resources. Examplesbasic attributes ofsuch control include path establishment between DSP blocks such<play> and <playcollect> astone detectors, tone generators, ordescribed in Section 6.3. MSCML also defines otherspeech resources. For such users, we STRONGLY suggest using a protocol such as H.248.1 [2]. Suchattributes that controldoes not fittheSIP model. It is,behavior ofcourse, possible to transport such low-level instructions in SIP. However, the programming model moves fromtheclient-server peer paradigm of SIP toprompt and recording phases. These phases and themaster-slave controller model of H.248.1,attributes that control them are described inwhich case H.248.1 is a much more appropriate solution. The MSCML paradigm is important tothedeveloper community, in that developers and operators conceptually write applications about calls, conferences,text andcall legs.tables below. 6.5.1. Prompt Phase TheH.248.1 paradigm is conceptually about resources and plumbing. That is a whole level of implementation details that, for the majority of developers, adds no value. 3. Usepresence or absence ofSIP Request Methods As mentioned above, MSCML payloads may be carried in either SIP INVITEa "prompturl" attribute orINFO requests. The initial INVITE, which creates an enhanced conference, MUST include an MSCML payload. The initial INVITE, which joinschild <prompt> element controls whether or not aparticipant leg to an enhanced conference, MAY include an MSCML payload. All mid-call MSCML payloads are sent via SIP INFO requests. MSCML responses are transported inprompt is played before recording begins. As previously noted, use of thefinal response to"prompturl" attribute is deprecated and clients SHOULD use <prompt> instead. When theSIP INVITE containingclient requests thematching MSCML request or in a SIP INFO message. The only allowable final responsemedia server toa SIP INFO containing a message bodyprompt the caller before recording audio, <playrecord> has two stages. The first is equivalent to a200 OK, per RFC2976 [3]. Therefore, when<playcollect> operation. The client may set theMSCMLprompt phase to be interruptible by DTMF input (barge) and may specify an escape key that will terminate the <playrecord> requestis sent via SIP INFO,before the recording phase begins. Table 19 describes the attributes of <playrecord> that specify the behavior of the prompt phase of theMSCML response is carried in a separate INFOrequest.In general, these responses are asynchronous in nature and require a separate transaction due toVan Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page5]46] Internet-Draft MSCMLDecember 2004 timing considerations. There has been considerable debate on the use of the SIP INFO method for any purpose. Our experience is that MSCML would not have been possible without it. When MSCML was implemented the first SIP Event Notification draft had just been published. At that time, use of SUBSCRIBE/NOTIFY within an existing dialog was undefined. This prevented its use in MSCML since all events occurred in an INVITE established dialog. And while SUBSCRIBE/NOTIFY was well suited for reporting conference events its semantics seemed inappropriate for modifying a participant leg or conference setting where the only "event" was the success or failure ofFebruary 2006 +-------------+---------+-----+-------------------------------------+ | Attribute | Default | R/O | Description | +-------------+---------+-----+-------------------------------------+ | barge | yes | O | Specifies whether user input will | | | | | barge therequest. Lastly, since SIP INFO was an established RFC it was well supported in allprompt and force | | | | | transition to theSIP stack implementations available at that time. We had few if any interoperability issues asrecord phase. | | | | | When set to "yes" aresult. As it turns out, using NOTIFY is not appropriate, asDTMF input will | | | | | barge theNOTIFY would be in responseprompt. When set toan implicit subscription. The issues of implicit subscription have been discussed on"no", | | | | | theSIPprompt phase cannot be barged | | | | | andSIPPING lists. Using SUBSRCIBE is not appropriate for two reasons. The first is semantic. The purpose of SUBSCRIBEany user input during the | | | | | prompt isto register interestplaced inUser Agent state. However, using SUBSCRIBEthe quarantine | | | | | buffer forMSCML results ininspection during theSUBSCRIBE modifying| | | | | collect phase. Note that If theUser Agent state. The second reason SUBSCRIBE is not appropriate is because MSCML| | | | | "barge" attribute isinherently call-based. The association of a SIP dialog with a call leg means MSCML can be incredibly straightforward. For example, if one used SUBSCRIBE or other SIP methodset tosend commands about some context, one must identify"no", | | | | | the "cleardigits" attribute | | | | | implicitly has a value of "yes". | | | | | This ensures the media server does | | | | | not leave DTMF input thatcontext somehow. Relating commandsoccurred | | | | | prior to theSIP dialog they arrive on defines the context for free. Moreover, it is conceptually easy forcurrent collection in | | | | | thedeveloper. Recently we have re-considered usingquarantine buffer after theNOTIFY method for events, as used in,| | | | | request completes. | | cleardigits | no | O | Specifies whether previous user | | | | | input should be considered or | | | | | ignored forexample, KPML [11]. NOTIFYbarge-in purposes. When | | | | | set to "yes" any previously | | | | | buffered digits are removed so | | | | | prior user input isappropriate for KPML as thereignored. If set | | | | | to "no" previously buffered digits | | | | | will be considered. If | | | | | "cleardigits" isusually only a single responseset toa given KPML document. Moreover, mid-call requests can go in both directions, which"no" and | | | | | barge-in isnotenabled previously | | | | | buffered digits will result in the | | | | | prompt being barged immediately. In | | | | | this casefor KPML. Because of the multiple response and peer mid-call request nature of MSCML, we also considered MSRP [12]. MSRP may betheappropriate technology. The main benefit of MSRPprompt is not played | | | | | and recording begins immediately. | | escapekey | * | O | Specifies a DTMF key thatonly proxies interested in seeing MSCML signaling seeindicates | | | | | theMSCML messages. This is in contrastuser wishes to terminate the | | | | | currentscheme, where the interested proxies, as well asoperation without saving | | | | | anyother proxies that happeninput recorded torecord-route, see the MSCML messages. The trade-off here isthatmanypoint. | | | | | Detection of theinterested proxies are border proxies. Inmapped DTMF key | | | | | terminates theinterestrequest immediately | | | | | and generates a response. | +-------------+---------+-----+-------------------------------------+ Table 19: Playrecord Attributes for the Prompt Phase Detection ofinteroperability, we chose to continue using INFO.the escape key generates a response message, and the operation returns immediately. If the user presses any other keys Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page6]47] Internet-Draft MSCMLDecember 2004 In order to guarantee interoperability with this specification, as well as with SIP User Agents that are unaware of MSCML, SIP UACs that wishFebruary 2006 and if the prompt is interruptible (barge="yes"), then the play stops immediately and the recording phase begins. 6.5.2. Record Phase If the request proceeds touse MSCML services MUST Requirethe"mscml" service inrecording phase, theinitial INVITE. Themediaserver, as a SIP UAS, MUST respond appropriatelyserver discards any digits from the collect phase from the quarantine buffer to eliminate unintended termination of theINVITE, as well as advertise its supportrecording. +-------------+------------------+-----+----------------------------+ | Attribute | Default | R/O | Description | +-------------+------------------+-----+----------------------------+ | recurl | | R | Specifies the target URL | | | | | for the recorded content. | | recencoding | ulaw | O | Specifies the encoding ofMSCML in| | | | | the recorded content if it | | | | | cannot be inferred from | | | | | the recurl. Possible | | | | | values are "ulaw", "alaw" | | | | | and "msgsm." | | mode | overwrite | O | Specifies whether theresponse| | | | | recording should overwrite | | | | | or be appended toOPTIONS requests. This alleviates the major issues with using INFO for the transport of application data, namelytheUser Agent's proper interpretation of what is, by design, a opaque message request. SIP continues to progress incredibly quickly| | | | | target URL. Allowable | | | | | values are "overwrite" andwe will continually reevaluate some of the decisions that resulted in| | | | | "append." | | duration | infinite | O | Specifies theoriginal design of MSCML. However, we can confidently say thatmaximum | | | | | allowable duration for theavailability of| | | | | recording. Expressed as awidely supported, flexible request method was very important to| | | | | time value (Section 4.2.1) | | | | | from 1 onwards or thedevelopment| | | | | strings "immediate" andadoption MSCML. 4. MSCML Design 4.1 Transaction Model To avoid undue complexity two rules were established regarding MSCML usage. The first is that only one MSCML body may be present in a SIP request.| | | | | "infinite." Thesecond isvalue | | | | | "immediate" indicates thateach MSCML body may contain only one request or response. This greatly simplified transaction management. MSCML syntax does provide for| | | | | recording will end | | | | | immediately whereas | | | | | "infinite" indicates | | | | | recording should continue | | | | | indefinitely. If theunique identification of multiple requests in a single body part but this| | | | | maximum duration isnot currently allowed. Per| | | | | reached theguidelines of RFC3470 [13], MSCML bodies MUST be well formed and valid. MSCML is a direct request-response protocol. There are no provisional responses, only final responses. A<playrecord> | | | | | requestmay result in multiple notifications, as in the case of requesting active talker reports. This maps to the three major tag trees for MSCML: <request>, <response>,will terminate and<notification>. Figure 1 shows a request body. Depending on the command, one can send the request in an INVITE or an INFO. Figure 2 shows a response body. The SIP INFO method transports response bodies. Figure 3 shows| | | | | generate anotification body. The SIP INFO method transports notifications.response. | Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page7]48] Internet-Draft MSCMLDecember 2004 <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> ... request body ... </request> </MediaServerControl> Figure 1: Request <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <response> ... request body ... </response> </MediaServerControl> Figure 2: Response <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <notification> ... notification body ... </notification> </MediaServerControl> Figure 3: Notification 4.2 XML Usage InFebruary 2006 | beep | yes | O | Specifies whether a beep | | | | | should be played to thephilosophy| | | | | caller immediately prior | | | | | to the start ofXMLthe | | | | | recording phase. Allowable | | | | | values are "yes" and "no." | | initsilence | 3000ms | O | Specifies how long to wait | | | | | for initial speech input | | | | | before terminating | | | | | (canceling) the recording. | | | | | Expressed as atext-based description language,time value | | | | | (Section 4.2.1) from 1 | | | | | onwards or the strings | | | | | "immediate" andnot a programing language, MSCML makes| | | | | "infinite." The value | | | | | "immediate" indicates that | | | | | thechoice of many attribute values for readability bytimer should fire | | | | | immediately whereas | | | | | "infinite" directs the | | | | | media server to wait | | | | | indefinitely. | | endsilence | 4000ms | O | Specifies how long the | | | | | media server waits after | | | | | speech has ended to stop | | | | | the recording. Expressed | | | | | as ahuman. Thus many attributes that would often be "boolean" instead take "yes" or "no" values. For example, what does 'report="false"'time value | | | | | (Section 4.2.1) from 1 | | | | | onwards or'report="1"' mean? However, 'report="yes"' is clearer: I want a report. That said, some programmers prefertheprecision of a boolean. To satisfy both styles, MSCML definesstrings | | | | | "immediate" and | | | | | "infinite." When set to | | | | | "infinite", the recording | | | | | will continue indefinitely | | | | | after speech has ended and | | | | | will only terminate due to | | | | | aXML type, "yn", that takes onDTMF keypress or because | | | | | thevalues "yes", "no", andinput has reached theboolean values, normally "true", "false", "1", and "0". Many attributes in| | | | | maximum desired duration. | | recstopmask | 0123456789ABCD#* | O | Specifies a list of | | | | | individual DTMF characters | | | | | that, if detected, will | | | | | cause theMSCML schema have default values. In orderrecording tolimit demands on the XML parser, MSCML applies these values atbe | | | | | terminated. To ensure theprotocol,| | | | | input of a specific key or | | | | | keys does notXML, level. The MSCML schema documents these defaults as XML annotationscause the | | | | | recording to stop, remove | | | | | theappropriate attribute.DTMF key(s) from the | | | | | list. | +-------------+------------------+-----+----------------------------+ Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page8]49] Internet-Draft MSCMLDecember 2004 5. Advanced Conferencing 5.1 Conference Model The advanced conferencing model is a star controller model, with both signalingFebruary 2006 Table 20: Playrecord Attributes for the Record Phase Media servers MUST support local andmedia directed to a central location. Figure 4 depicts a typical signaling relationship between end users' UAC's, a conference application server,remote (NFS) "file://" scheme URL's in the "recurl" attribute. MSCML supports "http://" anda media server."https://" scheme URLs indirectly through the <managecontent> (Section 8) request. Thedocument cc-conferencing [8] makes usemedia server buffers and returns any digits collected in the prompt phase, with the exception ofthis model.those contained in the the "recstopmask" attribute, in the response. Theapplicationmedia serveris an instantiation ofcompares digits detected during theconference focus.recording phase to the digits specified in the "recstopmask" to determine if they indicate a recording termination request. The media serveris an instantiation of the media mixer. Note that user-level constructs, such as event notifications, areignores digits not present in thepurview ofrecstopmask and passes them into theapplication server. This is why, for example,recording. If DTMF input terminates the recording, the media serverwill notifyreturns theactive talker report using MSCML, whilecollected digit to theapplication server should useclient in theconference package [14] for individual notifications to SIP user agents. Note that<response>. Once recording has begun, theuse ofMedia Server writes theconference package forreceived mediaservertoapplicationthe specified recurl URL no matter what DTMF events the media servernotificationsdetects. It isnot recommended because nonethe responsibility of thefiltering and membership information is available atclient to examine themedia server. +-------+ | UAC 1 |---\ Public URI +-------------+ +-------+ \ _____________| Application | / / | Server | Not shown: +-------+ / / +-------------+ RTP flows directly | UAC 2 |---/ / | Private between UAC'sDTMF input returned in the <response> message to determine whether the audio file should be saved or if it should be deleted and+-------+ / | URI Media Server . / +--------------+ : / | | +-------+ / |potentially re-recorded. If the endsilence timer expires, the Media Server| | UAC n |---/ | | +-------+ +--------------+ Figure 4: Conference Model Each UAC sendstrims the end of the recorded audio by anINVITEamount equal toa Public Conference URI. PresumablytheApplication Server publishes this URI, or itvalue of the "endsilence" attribute. 6.5.3. Playrecord Response When the recording isan ad hoc URI. In any event,finished, theApplicationMedia Server generates aPrivate URI, following<response> message and sends it to therules specified by Basic Network Media Services withclient in a SIP[7]. That is, the URI isINFO message. Details of theform: sip:conf=UniqueID@ms.example.net Where UniqueID is<playrecord> response are described in Section 10.6. 6.5.4. Playrecord Examples The recording example (Figure 31) plays aunique conference identifier,prompt andms.example.net isrecords it to thehost name or IP address ofdestination specified in themedia server. There is nothing to prevent"recurl" attribute encoded as MS-GSM in wave format. Van Dyke, et al. Expires September 1, 2006 [Page 50] Internet-Draft MSCML February 2006 <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <playrecord id="5556123" recurl="file:////nfs.example.com/rec/name.wav" recencoding="msgsm" initsilence="5000" endsilence="3000" duration="30000" barge="yes" beep="yes" mode="overwrite" cleardigits="no" escapekey="*" recstopmask="0123456789#*"> <prompt> <audio url="http://www.example.com/prompts/recordname.wav"/> </prompt> </playrecord> </request> </MediaServerControl> Figure 31: Recording Example If theUAC's from contactingrecording ended because themedia server directly. However, one"endsilence" timer fired and no digits were pressed the response wouldexpectbe as shown in Figure 32. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response id="5556123" request="playrecord" code="200" text="OK" reason="end_silence" digits="" reclength="53032" recduration="6620" playduration="1045" playoffset="1045"> </response> </MediaServerControl> Figure 32: Recording Response Example 6.6. Stop Request <stop> The client issues a <stop> request when theowner ofobjective is to stop a request in progress and not initiate another operation. This request generates a <response> message from themedia serverMedia Server. The only attribute is id, which is optional. The client-defined request id correlates the asynchronous response with its original request and echoes back torestrict who can use media server resources.the client in the Media Server's response. The following MSCML payload (Figure 33) depicts an example <stop> Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page9]51] Internet-Draft MSCMLDecember 2004 As for basic conferencing, described by Basic Network Media Services with SIP [7], the first INVITEFebruary 2006 request. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <stop id="4578903"/> </request> </MediaServerControl> Figure 33: Stop Example The following MSCML payload (Figure 34) depicts a valid response to themedia server withabove request. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="stop" id="4578903" code="200" text="OK"/> </MediaServerControl> Figure 34: Stop Response Example The format of aUniqueID createsresponse to aconference. However,<stop> request is detailed inadvanced conferencing,Section 10.2. As discussed previously, thefirst INVITE includesMedia Server treats aMSCML configure_conference payload. The MSCML payload conveys extended sessionSIP re-INVITE which modifies the established SDP parameters(e.g., numberas an implicit <stop> request. Examples ofparticipants) thatsuch SDP modifications arenot readily expressed inreceiving hold SDPbut must be known to allocate the appropriate resources. The first dialog established foror removing anenhanced conference has several useful propertiesaudio or video stream. When this occurs the Media Server immediately terminates the running <play>, <playcollect> or <playrecord> request, andis referredsends a <response>, indicating "reason=stopped". 7. Call Leg Events MSCML defines event notifications which are scoped to a specific SIP dialog or call leg. These events allow a client to be notified of individual, asynchronous DTMF keypresses asthe "Conference Control Leg."well as various call progress signals. Thecontrol leg is used for play or record audio operations to/from the entire conferencesubscription, event detection andno RTP is expected on the Conference Control Leg. Therefore, the application must send either no SDP or hold SDP (c=0.0.0.0)notifications for call leg events occur in theinitial INVITE request. In addition, the lifetime of the conference is thesameas that of its control leg.SIP dialog. Thisensures thatis different than the conferenceremains in existence even if one or more participant legs unintentionally leaves the conference. 5.2 Configure Conference Taglevel active talker events described earlier. The<configure_conference> tag has two attributes that control the resources the media server sets asidesubscription and notifications for active talker events occur on theconference. The attributes are reservedtalkers and reserveconfmedia. Reservedtalkers setsconference control leg but themaximum number of talkeractual event detection occurs on one or more participant legs.Reserveconfmedia, if set to "yes", allocates resourcesSubscriptions forplaying or recording audio to or fromcall leg events are made by sending an MSCML <configure_leg> request on theentire conference. The default for reserveconfmedia is "yes". Whendesired SIP dialog. Call leg events may be used with thereservedtalkers+1st INVITE arrives atMSCML conferencing or IVR services. When used Van Dyke, et al. Expires September 1, 2006 [Page 52] Internet-Draft MSCML February 2006 with themedia server,IVR service the <configure_leg> request SHOULD not include any conference related attributes. The media serverresponds with a 486 BUSY HERE. NOTE: It wouldMUST ignore these if present. Call leg event subscriptions MUST not besymmetric to have a reservedlisteners parameter. However, the practical limitationmade on the conference control leg since it has no actual RTP mediaserver is the number of talkers for a mixertomonitor. In either case, the applicationprocess for event detection. The media serverregulates who gets in to the conference by either proxying the INVITEs from the user agent clients or metering who it givesMUST reject a <configure_leg> request sent on the conferenceURI to.control leg. Theapplication server can include any MSCML command in the initial INVITE, with<configure_leg> request contains theexception of asynchronous commands, such as <play> or <record>.child elements <subscribe> and <events>. Theapplication server must issue asynchronous commands separately (e.g., in INFO messages)<events> element may contain two child elements which control subscriptions toavoid ambiguous responses. For example,call leg events. These are <keypress> and <signal>. A <configure_leg> request MUST contain at most one <keypress> element but MAY contain multiple <signal> elements which request notification of different call progress events. 7.1. Keypress Events Keypress events are used when the client wishes to receive notifications of individual DTMF events which are not tied tocreateaconference with upspecific <playcollect> request. One use of this facility is to120 active talkers and the abilitymonitor conference legs for DTMF inputs which require application intervention, for example toplay audio intonotify theconference or record parts or all ofmoderator that theconference,caller wishes to speak. Keypress events are also used when the applicationserver specifies both attributes, asdesires complete control of grammars and timing constraints. The MSCML fomat for keypress event subscriptions is shown in Figure6. Van Dyke, et al. Expires June 25, 2005 [Page 10] Internet-Draft MSCML December 200435. <?xmlversion="1.0" encoding="utf-8"?>version="1.0"?> <MediaServerControl version="1.0"> <request><configure_conference reservedtalkers="120"/><configure_leg> <subscribe> <events> <keypress report="standard|long|both|none" maskdigits="yes|no"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure6: 120 Speaker MSCML Example Figure 7 shows35: Keypress Event Subscription Format When used in aconference with up to five active speakers without the capability to play or record audio into the conference. <?xml version="1.0" encoding="utf-8"?> <MediaServerControl version="1.0"> <request> <configure_conference reservedtalkers="5" reserveconfmedia="no"/> </request> </MediaServerControl> Figure 7: 5 Speaker MSCML Example Oncesubscription context theapplication server<keypress> element hascreated the Conference Control Leg, the server can join participants to the conference. The application server directs the INVITE to the Private Conference URI described above. In the example given, this would be sip:conf=UniqueID@ms.example.net . 5.2.1 Conference Leg Attributes Conference legs have a number of parameters the application server can modify. The defaultstwo attributes, 'report' and 'maskdigits', which are detailed in Table1. +----------------------+----------------------+---------------------+21. Van Dyke, et al. Expires September 1, 2006 [Page 53] Internet-Draft MSCML February 2006 +------------+---------+-----+--------------------------------------+ |ParameterAttribute | Default | R/O | Description |+----------------------+----------------------+---------------------++------------+---------+-----+--------------------------------------+ |typereport |talker|Consider this leg'sR | Possible values are 'standard', | | |audio for mixing in| | 'long', 'both' and 'none'. | |the output mix.| | | 'Standard' means detected digits |Alternative is| | | |"listener".should be reported. 'Long' means | |dtmfclamp|yes|Remove detected| that long digits should be reported. | | | | | "Long" digits are defined as a | | | | | single key press held down for more | |DTMF digit from| | | than one second, or two distinct key |audio| |toneclamp|yes|Remove loudpresses (a "double") of the same | | | |single-frequency| digit that occur within two seconds | | |tone from audio| |mixmodeof each other with no other |full|Be a candidate for|Van Dyke, et al. Expires June 25, 2005 [Page 11] Internet-Draft MSCML December 2004| | intervening digits. 'Both' means |the full mix.| | | |Alternatives arethat both 'standard' and 'long' | | | |"mute" to not allow| digit events should be reported. As | | |audio in the mix,| | a "long" digit consists of one or | |"parked" to remove| | | more "normal" digits, a single long |any media streams| | | |from the leg, andduration key press will generate one | | | |"preferred" to give| standard event and one "long" event. | | |this stream| | A "double" will produce two standard | |preferential| | | events and one "long" event. 'None' |selection in the| | | |mix (i.e., even ifmeans no keypress events should be | | | |not loudest talker,| reported; disables keypress event | | |include media, if| | reporting if enabled. | |present, from thismaskdigits | no | O | Controls whether user DTMF inputs |leg in the mix).|+----------------------+----------------------+---------------------+ Table 1: Conference Leg Parameters In addition to these attributes, there are two tags defined. They are inputgain and outputgain. Values for these tags are <auto/>, to use automatic gain control (AGC) to determine input gain for the leg or <fixed/>. <auto/> takes the attributes "startlevel", "targetlevel", and "silencethreshold". All of the parameters are in dB. <fixed> takes the atribute "level", which is in dB. The default for both inputgain and outputgain is <auto/> If the default parameters are acceptable for the leg the application server wishes to enter into the conference, then a normal SIP INVITE is sufficient. However, if the application server wishes to modify one or more of the parameters, the application server can include a MSCML body| | | are captured inaddition to the SDP body. The applicationmedia servercan modify the conference leg parameters by issuing a SIP INFO on the selected dialog representing the conference leg. Of course, the applicationlog | | | | | files. The possible values for this | | | | | attribute are "yes" and "no". | +------------+---------+-----+--------------------------------------+ Table 21: Keypress Subscription Attributes The media servercannot modify SDP insends anINFO message. 5.3 Terminating a Conference To remove a leg fromMSCML response to theconference,subscription immediately upon receiving theapplication server issues a SIP BYE request onrequest. Notifications are sent to theselected dialog representingclient when theconference leg. The application server can terminate all legs in a conference by issuing a SIP BYE request onspecified events are detected. Figure 36 shows theConference Control Leg. If one orformat of keypress notifications. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page12]54] Internet-Draft MSCMLDecember 2004 more participants are stillFebruary 2006 <?xml version="1.0"?> <MediaServerControl version="1.0"> <notification> <keypress digit="[0-9]|[A-D]|#|*" length="standard|long" method="standard|long|double" interdigittime="{time value}"> <status command="idle|play|collect|record" duration={time value}/> </keypress> </notification> </MediaServerControl> Figure 36: Asynchronous DTMF Reporting Response Format When used inthe conference when the media server receives a SIP BYE request on the Conference Control Leg, the media server issues SIP BYE requests on all of the remaining conference legs to ensure clean up of the legs. The media server returnsa200 OK to the SIP BYE request as it sends BYE requests tonotification context, theother legs. This is because we cannot issue a provisional response<keypress> element has several attributes which are used toa non-INVITE request, yet the teardownconvey details of theother legs may "take a while". 5.4 Conference Manipulation Once the conference has begun, the application server can manipulate the conference asevent that was detected. It also contains awhole by issuing commandschild element, <status>, which provides information onthe Conference Leg. For example, the application server canany MSCML request that was in progress when themedia server to recordevent occurred. The details of these notification attributes are described in Table 22. +----------------+---------+-----+----------------------------------+ | Attribute | Default | R/O | Description | +----------------+---------+-----+----------------------------------+ | digit | | R | Specifies theconference, play a prompt toDTMF digit | | | | | detected. Possible values are | | | | | [0-9], [A-D], '#" or '*'. | | length | | R | Specifies theconference, changeduration class of | | | | | theinputDTMF input. Possible values | | | | | are 'standard' oroutput gain for'long'. | | method | | R | Specifies theconference as a whole, and report on events. The elements for these commandskeypress detection | | | | | method that generated the | | | | | notification. Possible values | | | | | are<playrecord>, <play>, <inputgain>, <outputgain>, and <subscribe>, respectively. Figure 8'standard', 'long' andFigure 9 show two sample commands. The first plays a prompt into the conference. The second records the entire conference to| | | | | 'double'. | | interdigittime | | R | Specifies theURI specified by recurl. This file: URI scheme happens to doelapsed time, as a | | | | | time value (Section 4.2.1), | | | | | between thewrite over NFS, per configuration atcurrent event | | | | | detection and themedia server. NOTE:previous one. | +----------------+---------+-----+----------------------------------+ Table 22: Keypress Notification Attributes 7.1.1. Keypress Subscription Examples Theprovisioning of NFS mount pointsfollowing example MSCML payloads depict subscriptions for all possible event types andtheir mapping to the file: schema is purelydisabling keypress reporting. Van Dyke, et al. Expires September 1, 2006 [Page 55] Internet-Draft MSCML February 2006 Figure 37 shows alocal matter at the media server.subscription for standard keypress events. <?xmlversion="1.0" encoding="utf-8"?>version="1.0"?> <MediaServerControl version="1.0"> <request><play prompturl="http://prompts.example.net/us_EN/welcome.au"/><configure_leg> <subscribe> <events> <keypress report="standard"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure8: Full Conference Audio Command - Play37: Standard Digit Events Subscription Figure 38 shows a subscription for long keypress events. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg> <subscribe> <events> <keypress report="long"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure 38: Long Digit Events Subscription Figure 39 shows a subscription for both standard and long keypress events. <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg> <subscribe> <events> <keypress report="both"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure 39: Subscription for both Standard and Long Digit Events Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page13]56] Internet-Draft MSCMLDecember 2004February 2006 Figure 40 shows the client disabling keypress event notifications. <?xmlversion="1.0" encoding="utf-8"?>version="1.0"?> <MediaServerControl version="1.0"> <request><playrecord recurl="file://archive.example.net/conferences/archives/011208.au" beep="no" initsilence="infinite" endsilence="infinite" /><configure_leg> <subscribe> <events> <keypress report="none"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure9: Full Conference Audio Command - Record40: Disabling Keypress Event Reporting 7.1.2. Keypress Notification Examples Theresponse tofollowing MSCML payloads depict keypress event notifications caused by various types of DTMF input. Figure 41 shows a notification generated by the detection of a standard "4" DTMF digit. In thislast request will be similar toexample this is the first digit detected. Thus, the 'interdigittime' attribute has a value of '0'. <?xml version="1.0"?> <MediaServerControl version="1.0"> <notification> <keypress digit="4" length="standard" method="standard" interdigittime="0"> <status command="play" duration="10"/> </keypress> </notification> </MediaServerControl> Figure10.41: Standard Keypress Notification Figure 42 shows a notification generated by detection of a long pound (#). Van Dyke, et al. Expires September 1, 2006 [Page 57] Internet-Draft MSCML February 2006 <?xmlversion="1.0" encoding="utf-8"?>version="1.0"?> <MediaServerControl version="1.0"><response request="playrecord" code="200" text="OK" reclength="1420374"/><notification> <keypress digit="#" length="long" method="long" interdigittime="200"> <status command="idle" duration="4"/> </keypress> </notification> </MediaServerControl> Figure10: Sample Change Command Response A request42: Long Keypress Notification The following MSCML payloads depict the notifications generated by the detection of two standard pound (#) events that also meet the double sequence criteria foran active talker reportlong digits. This scenario generates three notifications. One notification isinsent for each of the two standard keypress events and one notification indicates that they comprise a long digit as well. Multiple notifications are generated because the subscription specified 'report=both', which requests notifications for both long and standard digit events. <?xml version="1.0"?> <MediaServerControl version="1.0"> <notification> <keypress digit="#" length="standard" method="standard" interdigittime="0"> <status command="idle" duration="5"/> </keypress> </notification> </MediaServerControl> Figure11.43: Multiple Notification Example: First Notification <?xmlversion="1.0" encoding="utf-8"?>version="1.0"?> <MediaServerControl version="1.0"><request> <configure_conference> <subscribe> <events> <activetalkers/> </events> </subscribe> </configure_conference> </request><notification> <keypress digit="#" length="standard" method="standard" interdigittime="1000"> <status command="idle" duration="6"/> </keypress> </notification> </MediaServerControl> Figure11: Active Talker Request Later event reporting comes through SIP INFO messages. Figure 12 shows an example report.44: Multiple Notification Example: Second Notification Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page14]58] Internet-Draft MSCMLDecember 2004February 2006 <?xmlversion="1.0" encoding="utf-8"?>version="1.0"?> <MediaServerControl version="1.0"> <notification><conference uniqueID="ab34h76z" numtalkers="16" numlisteners="1382"> <activetalkers> <talker callID="myhost4sn123"/> <talker callID="myhost2sn456"/> <talker callID="myhost12sn78"/> </activetalkers> </conference><keypress digit="#" length="long" method="double" interdigittime="1000"> <status command="idle" duration="6"/> </keypress> </notification></MediaServerControl></MediaServerControl Figure12: Active Talker Event Example An application server can modify a leg by issuing an INFO on the dialog associated with45: Multiple Notification Example: Third Notification 7.2. Signal Events MSCML supports notification of certain call progress tones through theparticipant leg. For example, Figure 13 mutes<signal> element. The format of aconference leg.subscription for signal events is shown in Figure 46. <?xmlversion="1.0" encoding="utf-8"?>version="1.0"?> <MediaServerControl version="1.0"> <request><configure_leg mixmode="mute"/> <request><configure_leg> <subscribe> <events> <signal type="ring|busy|dial|CNG|CED|400" report="yes|no"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure13: Sample Change Leg Command In Figure 8 we saw46: Signal Event Subscription Format When used in arequestsubscription context the <signal> element has two attributes, 'type' and 'report', and no child elements. These attributes are detailed in Table 23. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | report | | R | Controls whether the specified signal | | | | | is reported. Possible values are | | | | | 'yes' and 'no'. When set toplay a prompt'yes' the | | | | | media server invokes the required | | | | | signal detection code and reports | | | | | detected events. When set to 'no' theentire conference. We can also request| | | | | media server disables the associated | | | | | signal detection code and does not | | | | | report events. | Van Dyke, et al. Expires September 1, 2006 [Page 59] Internet-Draft MSCML February 2006 | type | | R | Specifies the type of call progress | | | | | signal toplay a promptdetect. Possible values are | | | | | 'busy', 'ring', 'CED', 'CNG' and | | | | | '400' which correspond toan individual call leg. If we wantbusy tone, | | | | | ring tone, fax CED, fax CNG and 400 | | | | | Hz tone. | +-----------+---------+-----+---------------------------------------+ Table 23: Signal Subscription Attributes NOTE: The details of media server provisioning required toplay a prompt or collect digits only onsupport country specific variants of 'busy' and 'ring' is not covered by this specification. As stated previously a singleleg, we issue the commands within the dialog for the<configure_leg> request MAY contain multiple <signal> elements which request notification of different call progress tones. A single <configure_leg> request SHOULD NOT contain multiple <signal> elements that have thedesired conference participant. Section 6 describes the interactive voice response (IVR) services offered.same 'type' attribute value. Ifan IVR command arrives onthecontrol channel,media server receives such a request ittakes effect onSHOULD honor thewhole conference. This is a mechanism for playing prompts tolast element specifying that type that appears in theentire conference (e.g., announcing new participants). If an IVR command arrives onrequest. The media server generates anindividual leg, it only affects that leg. This is a mechanism for interacting with users, such as to create "waiting rooms", allow a user to mute themselves using key presses, allowing a moderatorimmediate response toout-dial, etc. 6. Interactive Voice Response (IVR) IntheIVR model,<configure_leg> subscription request and sends notifications when theMedia Server actsspecified signals are detected. A single notification is sent as soon asa media processing proxy fortheUAC. This is particularly useful whenspecified signal has been reliably detected. If theUACsignal persists continuously additional notifications will not be sent. If the signal is interrupted and then resumes additional notifications will be sent. 7.2.1. Signal Event Examples The following MSCML payloads show amediasignal event subscription (Figure 47), response (Figure 48) and notification (Figure 49). The cancellation (Figure 50) of an event subscription and the accompanying response (Figure 51) are also shown. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page15]60] Internet-Draft MSCMLDecember 2004 gateway or other device with limited media processing capability. SIP +--------------+ Service URI | Application | /---------------| Server | /(e.g., RFC3087) +--------------+ / |February 2006 <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg> <subscribe> <events> <signal type="busy" report="yes"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure 47: Signal Event Subscription <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="configure_leg" code="200" text="OK"/> </MediaServerControl> Figure 48: Signal Event Subscription Response <?xml version="1.0"?> <MediaServerControl version="1.0"> <notification> <signal type="busy"/> </notification> </MediaServerControl> Figure 49: Signal Event Notification <?xml version="1.0"?> <MediaServerControl version="1.0"> <request> <configure_leg> <subscribe> <events> <signal type="busy" report="no"/> </events> </subscribe> </configure_leg> </request> </MediaServerControl> Figure 50: Signal Subscription Cancellation Van Dyke, et al. Expires September 1, 2006 [Page 61] Internet-Draft MSCML/ SIP | Session / +--------------+ +-----+/ RTP | | | UAC |=====================| Media Server | +-----+ | | +--------------+February 2006 <?xml version="1.0"?> <MediaServerControl version="1.0"> <response request="configure_leg" code="200" text="OK"/> </MediaServerControl> Figure14: IVR Model The IVR service supports basic Interactive Voice51: Signal Subscription Cancellation Responsefunctions, playing announcements, collecting DTMF digits, and recording audio, based on Media Server Control Markup Language (MSCML) directives added8. Managing Content <managecontent> MSCML uses the <managecontent> request to move recorded content from themessage body of a SIP request. Figure 14 showsmedia server to remote locations using thesignaling relationship betweenHTTP protocol. This is aclient UAC,store andApplication Server, and a Media Server. Multifunctionforward model, which requires the completion of local temporary recording before the mediaservers SHOULD useserver can send it to theURI conventions describedweb server. This facility is useful inBasic Network Media Services with SIP [7]. For review,applications such as voice messaging where a message may be reviewed by theMSCML IVR service indicator is "ivr": sip:ivr@ms.example.net NOTE:caller prior to being committed to persistent storage. TheVoiceXML IVR service indicator is dialog. One may carry<managecontent> request has no child elements. 8.1. Managecontent Attributes The attributes of the <managecontent> requestpayload for IVRare described ineitherTable 24 below. +--------------+---------+-----+------------------------------------+ | Attribute | Default | R/O | Description | +--------------+---------+-----+------------------------------------+ | src | | R | Specifies theinitial SIP INVITE or INFO requests. Mid-call requests must uselocal source URL of | | | | | theINFO method.content. TheINFO method reduces certain timing issues that occur with re-INVITES and also uses less processing on bothURL scheme must | | | | | be "file://". | | dest | | O* | Specifies theapplication server and Media Server.destination URL. TheMedia Server notifies| | | | | URL scheme must be "http://". *If | | | | | theapplication thatselected action is 'delete', | | | | | this attribute is optional, | | | | | otherwise it is required. | | action | move | O | Specifies thecommand has completed through a <response> message containing final status information and data such as collected DTMF digits. The media server does not queue IVR requests. Ifoperation for the | | | | | media serverreceivesto execute. Values | | | | | can be either 'move' or 'delete'. | | | | | The 'delete' action operates on | | | | | the local source file. After arequest while another is in progress,| | | | | successful move or delete, the | | | | | media serverstops the first operation and it carries outdeletes thenew request. The Media Server generates a <response> message forsource | | | | | file from thefirst request and returns any data collected up to that point.media server. Ifan application wishes to stop athe | | | | | requestin progress but doesis unsuccessful, the | | | | | source file is notwish to initiate another operation, it issues a <stop> request. This also causesdeleted, which | | | | | gives theMedia Server to generate a <response> message.client complete control | | | | | of the retry strategy. | Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page16]62] Internet-Draft MSCMLDecember 2004 The Media Server treats a SIP re-INVITE with hold media (c=0.0.0.0) as an implicit <stop> request. The media server immediately terminates the running <play>, <playcollect> or <playrecord> request, and sends a <response>, indicating "reason=stopped". 6.1 Play Audio <play> The application issues a <play> request to play an announcement without interruption and with no digit collection. One use,February 2006 | httpmethod | post | O | HTTP protocol method forexample, is to announcethename of a new participantmedia | | | | | server to use in theentire conference.HTTP request. | | | | | Theapplication specifiesonly values are 'post' or | | | | | 'put'. | | name | | O* | Specifies theannouncement to play byfield name for theprompt block| | | | | content in thebody of the request. Attributes include promptencoding (optional), which explicitly specifiesform when using theencoding (mu-law, A-law, MS-GSM, etc.), and id (also optional). ID| | | | | 'post' method. This isan application-defined request identifier that correlates the asynchronous response with its original request and echoes backnot to be | | | | | confused with theapplication in the Media Server's response. When"src" or "dest" | | | | | attributes. *This attribute is | | | | | required when theannouncement"htttpmethod" | | | | | hasfinished playing,theMedia Server sends a <response=> payloadvalue "post." | | fetchtimeout | 10000ms | O | Specifies the maximum time allowed | | | | | for the transfer tothe application incomplete. | | | | | Expressed as aSIP INFO message. The response may carrytime value | | | | | (Section 4.2.1) from 1 onwards. | | mimetype | | O* | Specifies theid,MIME type for thestatus code (e.g., 200),| | | | | media server to transfer thestatus text (e.g., OK), and| | | | | content in. If not provided thereason (EOF or stopped). 6.2 Collect Digits <playcollect> The application issues a <playcollect> request to optionally play an announcement and then collect digits. This request has multiple attributes, all of which are optional. The presence or absence of| | | | | media server MUST infer it from | | | | | theprompt block controls whether there will be an announcement orcontent file extension based | | | | | on theresultmappings contained in | | | | | Table 25. *If the MIME type of therequest is to| | | | | content cannot bedigit collection only. Whenever the media server receives a <playcollect> request, it will continuously buffer and examine collected digits. The media server compares previously buffered digits toinferred from | | | | | thereturnkey, escapekey, and maxdigits attributes to determine if any immediate actionfile extension this attribute | | | | | is required.This provides| +--------------+---------+-----+------------------------------------+ Table 24: Managecontent Attributes Table 25 defines thetype-ahead behavior for menu traversalMIME type values allowed in the 'mimetype' attribute andother types of IVR interactions. The application may override type-ahead behavior by settingthecleardigits parameterfile extensions to which they are mapped. +-----------+--------------------+ | Extension | MIME Type | +-----------+--------------------+ | alaw | audio/x-alaw-basic | | ulaw | audio/basic | | msgsm | audio/ms-gsm | | wav | audio/x-wav | | tif | image/tiff | | tiff | image/tiff | | mov | video/quicktime | | qt | video/quicktime | | 3gp | video/3gpp | | 3gpp | video/3gpp | +-----------+--------------------+ Table 25: File Extension to"yes", which removes all previously-buffered digits such that the only user input considered is what occurs afterMIME Type Mappings Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page17]63] Internet-Draft MSCMLDecember 2004 the request. If cleardigits is set to "no", digits previously buffered will result in the prompt being barged immediately. Prompt play would never begin, and digit collection would start immediately.February 2006 Thedefault for barge is "yes". If the barge attribute is setability to"no", the cleardigits attribute implicitly hasmove or delete any local file presents avalue of "yes". This ensures that DTMF input occurring before the current collection is not left inpotential risk to thebuffer aftersecurity of therequest completes. The application can set two special strings to invoke special processingmedia server system. For this reason, we STRONGLY RECOMMEND implementers limit local file system access whendetected: o The escapekey, which defaults to *, indicates that the user intendsusing <managecontent>. For example, we encourage limiting access based on file ownership and/or toterminatespecific directories. 8.2. Managecontent Example Following is an example showing a local file on thecurrent operation without saving any input collectedmedia server being transferred tothat point. Detection terminatesan HTTP URL using therequest immediately and generates a response. o"put" method. Thereturnkey, which defaults to #, indicatesclient sends theuser has completed input and wants to return all collected digits tofollowing request. <?xml version="1.0"?> <MediaServerControl version="1.0" <request> <managecontent id="102" src="file:////var/mediaserver/rec/6A5GH49B.ulaw" dest="http://www.example.com/recordings/myrecording.ulaw" mimetype="audio/basic" action="move" httpmethod="put" fetchtimeout="5000"/> </request> </MediaServerControl> Figure 52: Managecontent Example Note that theapplication. Whenclient can change the temporary file name assigned by the media serverdetects the returnkey, it immediately terminates collection andas part of this operation as shown. The media server returnsthe collected digitsa response similar to theapplication infollowing. <?xml version="1.0"?> <MediaServerControl version="1.0" <response id="102" request="managecontent" code="200" text="OK"/> </MediaServerControl> Figure 53: Managecontent Response If the request is ambiguous, the<response> message. Themedia servermay also support three additional strings to support VCR controls while playingMUST return aprompt. These strings modify the behavior of the playingstatus code ofthe prompt block."400" and text "Bad Request." If the media serverdoes not support VCR controls,is unable to execute a syntactically correct and unambiguous request itmust silently ignoreMUST return a "500" status code with therequest. o The skipinterval, which defaults to "6s", indicates how fartext "Server Error." For example, if the local file system access restrictions described earlier prevent deletion of the specified file the media servershould skip backwards or forwards inreturns thecurrently playing object from prompturl. ofollowing. Van Dyke, et al. Expires September 1, 2006 [Page 64] Internet-Draft MSCML February 2006 <?xml version="1.0"?> <MediaServerControl version="1.0"> <response id="102" request="managecontent" code="500" text="Server Error" reason="Operation not permitted"/> </MediaServerControl> Figure 54: Managcontent Error Response Theffkey indicates the user wishes to skip forward skipinterval"reason" attribute in thecurrently playing object from prompturl. o The rwkey indicates the user wishes to skip backward skipinterval inresponse conveys additional details on thecurrently playing object form prompturl. Noteserver error thatitoccurred. If there isan error to have the digits mapped to ffkey or rwkey in the digitmap. The VCR controls only work withinasingle <prompt> block. Skipping-back before the begining ofnetwork or remote server error, theblock resultsmedia server provides detailed error information inplayback at the beginning of the block. Skiping-forward past the end oftheblock results<error_info> element contained in the media servertreatingresponse. The following example shows that theprompt as played. NOTE: This is onlymedia server received avery rudimentary implementation of VCR controls. Application developers are STRONGLY RECOMMENDED to use503 error from the remote web server. <?xml version="1.0"?> <MediaServerControl version="1.0"> <response id="102" request="managecontent" code="200" text="OK"> <error_info code="503" text="Service Unavailable" context="http://www.example.com/recordings/myrecording.ulaw"/> </response> </MediaServerControl> Figure 55: Managcontent Storage Error Response 9. Fax Processing 9.1. Recording a Fax <faxrecord> The <faxrecord> request directs theinterrupt time returnedMedia Server to process a fax in answer mode. The reason for a request separate from <playrecord> is that thedigit reportmedia server needs tocalculate whereknow toskip. This enables sensible handling of composite voice objects, etc. If an application developer needs real VCR controls, theyprocess the T.30 [18] or T.38 [19] fax protocols. The <faxrecord> request has multiple attributes and one child element, <prompt>. These attributes areSTRONGLY RECOMMENDED to use VoiceXML with VCRdescribed in Table 26. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page18]65] Internet-Draft MSCMLDecember 2004 extensions. Several timer attributes control how long the Media Server waits for digits in the input sequence. All timer settings are in milliseconds. firstdigittimer controls how long the Media Server waits for the initial DTMF input before terminating collection. interdigittimer controls how long the Media Server waits between DTMF inputs. extradigittimer controls how long the Media Server waits for additional user input afterFebruary 2006 +----------------+---------+-----+----------------------------------+ | Attribute | Default | R/O | Description | +----------------+---------+-----+----------------------------------+ | lclid | "" | O | A string that identifies thespecified number of digits has been collected.| | | | | called station. | | prompturl | | O | Theextradigittimer setting enablesURL of the"returnkey" inputcontent to beassociated with the current collection. For example, if maxdigits is set to 3| | | | | retrieved andreturnkeyplayed. The target | | | | | may be a local or remote (NFS) | | | | | "file://" scheme URL or an | | | | | "http://" or "https://" scheme | | | | | URL. NOTE: Use of this attribute | | | | | isset to #,deprecated. | | promptencoding | | O | Specifies theuser may enter either "x#", "xx#" or "xxx#", where x representscontent encoding | | | | | for files that do not have aDTMF digit. If the "returnkey" pattern| | | | | 'tif' or 'tiff' extension. The | | | | | only allowable value isdetected during the "extradigit" interval,"tiff". | | | | | This attribute only affects | | | | | "file://" scheme URLs. NOTE: Use | | | | | of this attribute is deprecated. | | recurl | | O | Specifies thecollected digits are returned totarget URL for theapplication and| | | | | recorded content. | | rmtid | | O | Specifies the"returnkey" is removed fromcalling station | | | | | identifier of thedigit buffer.remote | | | | | terminal. Ifthis were not the case, the example would return "xxx" topresent, theapplication and leavemedia | | | | | server MUST reject transactions | | | | | with theterminating "#" inremote terminal if thedigit buffer to be processed by| | | | | remote terminal's identifier | | | | | does not match thenext <playcollect> request. This might result invalue of | | | | | 'rmtid'. | +----------------+---------+-----+----------------------------------+ Table 26: Faxrecord Attributes Clients SHOULD use theterminationmore flexible <prompt> mechanism for specifying fax content. Use of thefollowing prompt; clearly'prompturl' attribute is deprecated and may notwhat the user intended. The extradigittimer has no effect unless returnkey has been set.be supported in future MSCML versions. The<regex><prompt> elementspecifiesis described in Section 6.1.1. A <prompt> element sent in adigit pattern for<faxrecord> request MUST not contain <variable> elements. Media servers MUST support local and remote (NFS) "file://" scheme URL's in themedia server to look for."recurl" attribute. MSCML supportsthree modes"http://" and "https://" scheme URLs indirectly through the <managecontent> (Section 8) request. The <faxrecord> request operates in one ofdigit map specification: regular expressions, MGCP [4] digit maps,three modes: receive, poll, andH.248.1 [2] digit maps.turnaround poll. Thetype attribute indicates what kindcombination ofdigit map appears in<prompt> or 'prompturl' attribute and 'recurl' attribute define theexpression. regex The default; use regular expression matching. mgcpdigitmap Use digit maps as specifiedmode. Table 27 describes these modes inMGCP [4]. megacodigitmap Use digit maps as specifieddetail. The 'prompt' column inH.248.1 [2]. Whenthe<playcollect>Van Dyke, et al. Expires September 1, 2006 [Page 66] Internet-Draft MSCML February 2006 table hasfinished playing,theMedia Server sends a <response> payload tovalue 'yes' if theapplication inrequest has either aSIP INFO message. The response may carry<prompt> element or 'prompturl' attribute. +--------+--------+---------+---------------------------------------+ | prompt | recurl | Mode | Operation | +--------+--------+---------+---------------------------------------+ | no | no | Invalid | Request fails. | | no | yes | Receive | Record theid,fax to thecode (e.g., 200),target URL | | | | | specified in 'recurl'. | | yes | no | Poll | Send fax from source specified in thetext(e.g., OK),| | | | | <prompt> element or 'prompturl' | | | | | attribute. If there is a 'rmtid', it | | | | | MUST match thereason (match, timeout, returnkey, escapekey,remote terminal's | | | | | identifier, orstopped), andthecollected digits. Van Dyke, et al. Expires June 25, 2005 [Page 19] Internet-Draft MSCML December 2004 6.3 Recording Audio <playrecord> The <playrecord>requestdirectswill fail. | | yes | yes | TP | Turnaround Poll (TP) mode. If theMedia Server| | | | | remote terminal wishes tocapturetransmit, | | | | | theRTP it receives and deliver itmedia server records the fax toa URI specified by| | | | | thecontrolling applicationtarget URL specified in 'recurl'. | | | | | If theappropriate codec and content encoding. This tag has multiple attributes. The required recurl attribute identifiesremote terminal wishes to | | | | | receive, theURI target formedia server sends therecorded audio. All other attributes are optional. The presence or absence of| | | | | fax from theprompt block controls whethersource URL contained in | | | | | <prompt> ornot'prompturl'. If there is | | | | | aprompt plays before recording begins. When'rmtid', it MUST match remote | | | | | terminal's identifier, or theapplication requestssend | | | | | request will fail. A receive | | | | | operation will still succeed, | | | | | however. | +--------+--------+---------+---------------------------------------+ Table 27: Fax Receive Modes In receive mode, the media serverto promptreceives thecaller before recording audio, <playrecord> has two stages. The first is equivalent to a <playcollect> operation. The application may setfax and writes theprompt phasefax data tobe interruptible by DTMF input (barge) and may also specify an escape key that will terminatethe<playrecord> request beforetarget URL specified by therecording phase begins. Detection of'recurl' attribute. In poll mode, theescape key generatesmedia server sends aresponse message, and the operation returns immediately. If any other keys are pressed and iffax, but as a polled (called) device. In turnaround poll mode, theprompt has been set as interruptible (barge="yes"), thenmedia server will record a fax that theplay stops immediately andremote machine sends. If therecording phase begins. Any digits collected inremote machine requests a transmission, then theprompt phase, withmedia server will send theexception offax. When transmitting a fax therecstopmask, are buffered and returnedmedia server will advertise that it can receive faxes in theresponse. IfDIS message. Likewise, when receiving a fax therequest proceeds tomedia server will advertise that it can send faxes in therecording phase,DIS message. The media server MUST flush any quarantined digitsfromwhen it receives a <faxrecord> request. Van Dyke, et al. Expires September 1, 2006 [Page 67] Internet-Draft MSCML February 2006 9.2. Sending a Fax <faxplay> The <faxplay> request directs thecollect phase are discardedMedia Server to process a fax in originate mode. The reason for a request separate from <play> is that thebufferMedia Server needs toeliminate unintended termination ofknow to process therecording.T.30 [18] or T.38 [19] fax protocols. Themedia server compares digits detected during<faxplay> request has multiple attributes and one child element, <prompt>. These attributes are described in Table 28. +----------------+---------+-----+----------------------------------+ | Attribute | Default | R/O | Description | +----------------+---------+-----+----------------------------------+ | lclid | | O | A string that identifies therecording phase to| | | | | called station. | | prompturl | | O | The URL of thedigits specified incontent to be | | | | | retrieved and played. The target | | | | | may be a local or remote (NFS) | | | | | "file://" scheme URL or an | | | | | "http://" or "https://" scheme | | | | | URL. NOTE: Use of this attribute | | | | | is deprecated. | | promptencoding | | O | Specifies therecstopmask to determine if they indicatecontent encoding | | | | | for files that do not have arecording termination request.| | | | | 'tif' or 'tiff' extension. Themedia server ignores digits not present in the recstopmask and passes them into the recording. If the recording| | | | | only allowable value isterminated because"tiff". | | | | | This attribute only affects | | | | | "file://" scheme URLs. NOTE: Use | | | | | ofa DTMF input,this attribute is deprecated. | | recurl | | O | Specifies thecollected digits are returned totarget URL for theapplication in| | | | | recorded content. | | rmtid | | O | Specifies the<response>. Once recording has begun,calling station | | | | | identifier of the remote | | | | | terminal. If present, the media | | | | | serverwritesMUST reject transactions | | | | | with theaudio toremote terminal if thespecified recurl URL no matter what DTMF events are detected. It is| | | | | remote terminal's identifier | | | | | does not match theresponsibilityvalue of | | | | | 'rmtid'. | +----------------+---------+-----+----------------------------------+ Table 28: Faxplay Attributes Clients SHOULD use theapplication to examine the DTMF input returned in the <response> message to determine whethermore flexible <prompt> mechanism for specifying fax content. Use of theaudio file should be saved or if it should be deleted'prompturl' attribute is deprecated andpotentially re-recorded.may not be supported in future MSCML versions. The <prompt> element is described in Section 6.1.1. A <prompt> element sent in a <faxrecord> request MUST not contain <variable> elements. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page20]68] Internet-Draft MSCMLDecember 2004 Two attributes control how long theFebruary 2006 MediaServer waits for the start of speech to begin the recordingservers MUST support local and remote (NFS) "file://" scheme URL's in theabsence of speech to end the recording: initsilence determines how long to wait for initial speech input before terminating (canceling)"recurl" attribute. MSCML supports "http://" and "https://" scheme URLs indirectly through therecording. This parameter may take an integer value<managecontent> (Section 8) request. The <faxplay> request operates inmilliseconds,one of three modes: send, remote poll, and turnaround poll. The combination of <prompt> ormay be set to "infinite", which directs'prompturl' attribute and 'recurl' attribute define theMedia Server to wait indefinitely.mode. Table 29 describes these modes in detail. Thedefault is 3000 ms (3 seconds). endsilence determines how long'prompt' column in theMedia Server waits after speechtable hasended to stoptherecording. This parameter may take an integer value in milliseconds, or may be set to "infinite". With avalueof "infinite",'yes' if therecording will continue indefinitely after speechrequest hasended and will only terminate due toeither aDTMF keypress<prompt> element orbecause the maximum desired duration has been reached. The default value is 4000 ms (4 seconds). If the endsilence timer expires, the Media Server trims the end of the recorded audio by an amount equal to the endsilence parameter. Additional attributes are: mode whether'prompturl' attribute. +--------+--------+---------+---------------------------------------+ | prompt | recurl | Mode | Operation | +--------+--------+---------+---------------------------------------+ | no | no | Invalid | Request fails. | | yes | no | Send | Send fax from source specified in therecording will overwrite| | | | | <prompt> element orappend. reencoding whether encoding'prompturl' | | | | | attribute. If there ismu-law, A-law, msgsm, etc. duration time in ms for the entire recording. beep whetherabeep will signify'rmtid', it | | | | | MUST match thestart of recording. Whenremote terminal's | | | | | identifier, or therecordingrequest will fail. | | | | | If there isfinished, the media server generatesa<response> message and sends'rmtid', ittomust match | | | | | remote terminal's identifier, or theapplication| | | | | receive request will fail. | | no | yes | Poll | Send fax from source specified ina SIP INFO message. The response contains the id, the code (e.g., 200, 400, 501),thereason (e.g., digit, end_silence, init_silence, max_duration, escapekey, error,| | | | | <prompt> element orstopped), collected digits, and the reclength (size of'prompturl' | | | | | attribute, assuming therecorded file in bytes). The recording example (Figure 16) plays a prompt ("SayName.g11") and recordsremote | | | | | terminal specifies itto the recurl in MS-GSM format, wave-encoded. Van Dyke, et al. Expires June 25, 2005 [Page 21] Internet-Draft MSCML December 2004 <playrecord prompturl="http://prompts.example.net/us_EN/SayName.g711" recurl="file://nfs.example.net/names/greet-joij34923119.wav" recencoding="msgsm" initsilence="15s" endsilence="2s" duration="8s"> </playrecord> Figure 16: Recording Example 6.4 Stop Request <stop> The application issues a <stop> request when the objective is to stopcan receive arequest| | | | | fax inprogress andits DIS message. It the remote | | | | | terminal does notinitiate another operation. This request generates a <response> message fromsupport reverse | | | | | polling, theMedia Server. The only attribute is id, which is optional. The application-definedrequestid correlateswill fail. If | | | | | 'rmtid' is specified, it must match | | | | | remote terminal's identifier, or theasynchronous response with its original| | | | | requestand echoes back towill fail. | | yes | yes | TP | Turnaround Poll (TP) mode. If theapplication in| | | | | remote terminal wishes to transmit, | | | | | theMedia Server's response. The response may carrymedia server records theid,fax to | | | | | thecode (e.g., 200), andtarget URL specified in 'recurl'. | | | | | If thetext (e.g., OK). Note thatremote terminal wishes to | | | | | receive, theMedia Server treats a SIP re-INVITE with hold media as an implicit <stop> request. Themedia serverimmediately terminates the running <play>, <playcollect> or <playrecord> request, andsendsa <response>, indicating "reason=stopped". 6.5 Prompt Block <prompt> This block inthebody of| | | | | fax from the<play>, <playcollect>, or <playrecord> request contains onesource URL contained in | | | | | <prompt> ormore references to physical audio files, provisioned sequences,'prompturl'. If there is | | | | | a 'rmtid', it MUST match remote | | | | | terminal's identifier, orvariables that are played intheorder in which they appear. Figure 17 shows a sample prompt block.send | | | | | request will fail. A receive | | | | | operation will still succeed, | | | | | however. | +--------+--------+---------+---------------------------------------+ Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page22]69] Internet-Draft MSCMLDecember 2004 <prompt baseurl="file:////opt/snowshore/prompts/conf/"> <audio url="please_enter.wav"/> <variable type="silence" value="1"/> <audio url="your.raw" encoding="a-law"/> <variable type="silence" value="1"/> <audio url="http://prompts.example.net/pin_number.wav"/> </prompt> Figure 17: Active Talker Event ExampleFebruary 2006 Table 29: Fax Send Modes In send mode, the media server sends the fax. In remote poll mode, the client places a call on behalf of the media server. Thebaseurl attribute ismedia server requests a fax transmission from thebase URL prepended toremote fax terminal. In turnaround poll mode, theURL attributes withinmedia server will record a fax that the<prompt> block. Each audio element inremote machine sends. If the remote machine requests a<prompt> block refers to an audio file or provisioned sequence fortransmission, then the media serverto play. Thewill send the fax. When transmitting a fax the media serverplays audio fileswill advertise that it can receive faxes in theorder in which they are listedDIS message. Likewise, when receiving a fax the media server will advertise that it can send faxes in theblock. 7. Fax Processing 7.1 Recording Fax <faxrecord>DIS message. The<faxrecord> request directs theMedia Serverto processMUST flush any quarantined digits when it receives afax in answer mode.<faxplay> request. 10. MSCML Response Attributes and Elements 10.1. Mechanism Thereason forMedia Server acknowledges receipt of aseparate tag from the <playrecord> tag is because theclient MSCML request sent in a SIP INVITE by sending a response of either 200 OK or 415 Bad Media Type. The Media Serverneeds to know to processresponds with 415 when theT.30 [15]SIP request contains a content type other than "application/sdp" orT.38 [16] fax protocols. This tag has multiple attributes."application/ mediaservercontrol+xml". Thelclid attribute isMedia Server acknowledges receipt of astring that identifies the called station. The lclid attribute is optional. The default is null. The <faxrecord>client MSCML requestoperatessent inone of three modes: receive, poll, and turnaround poll. In receive mode,a SIP INFO with a 200 OK or 415 Bad Media Type. The Media Server responds with 415 if the INFO request contains a content type other than "application/mediaservercontrol+xml". The Media Serverreceivestransports thefax and writesMSCML <response> message in a SIP INFO request. If there is an error in thefax data torequest or theURI specified byMedia Server cannot complete therecurl attribute. In poll mode,request, the Media Server sendsa fax, butthe <response> message very shortly after receiving the request. If the request is able to proceed, the <response> contains final status information asa polled (called) device. In turnaround poll mode,described below. 10.2. Base <response> Attributes All MSCML responses have theMedia Server will record a faxbasic attributes defined in Table 30. Van Dyke, et al. Expires September 1, 2006 [Page 70] Internet-Draft MSCML February 2006 +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | id | | O | Echoes the client defined ID for | | | | | contained in the request. | | request | | R | Specifies the MSCML request type that | | | | | generated theremote machine sends. Ifresponse. Allowable | | | | | values are "configure_conference", | | | | | "configure_leg", "play", | | | | | "playcollect", "playrecord", "stop", | | | | | "faxplay", "faxrecord" and | | | | | "managecontent". | | code | | R | The final status code for theremote machine requests| | | | | request. MSCML uses atransmission, thensubset of theMedia Server will send| | | | | status classes defined in RFC 3261 | | | | | [4]. In MSCML, 2XX responses indicate | | | | | success, 4XX responses indicate | | | | | client error and 5XX responses | | | | | indicate an error on thefax.Media | | | | | Server. There are no 1XX, 3XX or 6XX | | | | | status codes in MSCML. | | text | | R | Therecurl attribute ishuman readable reason phrase | | | | | associated with theURIstatus code. | +-----------+---------+-----+---------------------------------------+ Table 30: Basic MSCML Response Attributes Responses torecord the fax to, if specified. The prompturl attribute is<configure_conference> and <stop> requests contain only theURIattributes above. MSCML responses tofetch the faxother requests MAY contain additional request specific attributes and elements. These are described below. 10.3. Response Attributes and Elements for <configure_leg> Responses totransmit, if specified. Van Dyke, et al. Expires June 25, 2005 [Page 23] Internet-Draft MSCML December 2004 The rmtid attribute specifies the calling station identifier of<configure_leg> requests have only theremote terminal. If specified,base response attributes defined in Table 30. However, when themedia server MUST reject transactions withrequest contains a <configure_team> element theremote terminal ifresponse includes a <team> element describing theremote terminal's identifier does not match rmtid.teammate configuration for that leg. Thecombinationattributes ofprompturl and recurl definethemode. See<team> element are shown in Table2. +----------------+----------------+----------------+----------------+31. +-----------+---------+-----+---------------------------------------+ |prompturlAttribute |recurlDefault |ModeR/O |OperationDescription |+----------------+----------------+----------------+----------------++-----------+---------+-----+---------------------------------------+ |noid |no|InvalidR |Request fails.The client defined unique identifier | |no|yes|Receive|Record faxfor the conference leg. | | numteam | | R |into recurl.The number of team members for the | |yes|no|Poll|Send fax fromleg. | +-----------+---------+-----+---------------------------------------+ Van Dyke, et al. Expires September 1, 2006 [Page 71] Internet-Draft MSCML February 2006 Table 31: Attributes for <team> Additional information on each team member is conveyed by child <teammate> elements contained within <team>. Each teammate is represented by a single element in the list. The <teammate> element has a single attribute as described in Table 32. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description | +-----------+---------+-----+---------------------------------------+ | id | | R | The client defined unique identifier | | | | |prompturl. Iffor the teammate leg. | +-----------+---------+-----+---------------------------------------+ Table 32: Attributes for <teammate> 10.4. Response Attributes and Elements for <play> In addition to the base response attributes defined in Table 30, responses to <play> requests have the additional attributes described in Table 33. +--------------+---------+-----+------------------------------------+ | Attribute | Default | R/O |rmtid isDescription | +--------------+---------+-----+------------------------------------+ | reason | | O |specified, itFor requests that do not complete | | | | |must matchimmediately, the "reason" | | | | |remoteattribute conveys additional | | | | |terminal'sinformation regarding why the | | | | |identifier, orcommand completed. Possible values | | | | |the requestare "stopped", indicating an | | | | |will fail.explicit or implicit <stop> | |yes|yes|Turnaround|If the remoterequest was received and "EOF" | | | |Poll|terminalindicating that the end of the | | | | |wishes tospecified sequence of URLs was | | | | |transmit, thereached. | | playduration | | R |Media ServerA time value (Section 4.2.1) that | | | | |recordsreturns the duration of the | | | | |fax intoassociated content playout. | Van Dyke, et al. Expires September 1, 2006 [Page 72] Internet-Draft MSCML February 2006 | playoffset | | R |recurl. IfA time value (Section 4.2.1) that | | | | | returns the time offset into theremote| | | | |terminalspecified content sequence where | | | | |wishes toplay was terminated. If the | | | | |receive,initial "offset" value in the | | | | |Media Server | | | |sequence was "0", then |sends the fax| | | | "playduration" and "playoffset" |from| | | | are equal. However, if the the |prompturl. If| | | | initial offset had some other |rmtid is| | | | value "playoffset" serves as a |specified, it| | | | bookmark for the client to resume |must match| | | | play in a subsequent request. | +--------------+---------+-----+------------------------------------+ Table 33: MSCML Response Attributes for <play> 10.4.1. Reporting Content Retrieval Errors If the associated request set "stoponerror=yes" in <prompt> and an error occurred while retrieving the specified content the response will include an <error_info> element detailing the problem. This element contains the response information received from the remote content server. The <error_info> element has the attributes described in Table 34. +-----------+---------+-----+---------------------------------------+ | Attribute | Default | R/O | Description |terminal's | |+-----------+---------+-----+---------------------------------------+ | code | |identifier, orR | The status code returned by the | | | |the send| remote content server. For example, a | | | |request will|Van Dyke, et al. Expires June 25, 2005 [Page 24] Internet-Draft MSCML December 2004web server might return 404 to | | | |fail. A| indicate that the requested content | | | |receive| was not found. | | text | |operation willR | The human readable reason phrase | | | |still succeed,| returned by the remote content | | | |however.|+----------------+----------------+----------------+----------------+ Table 2: Fax Receive Modes The Media Server MUST flush any quarantined digits when it receives a <faxrecord> request. 7.2 Sending Fax <faxplay> The <faxplay> request directs the Media Server to process a fax in originate mode. The reason for a separate tag from the <play> tag is because the Media Server needs to know to process the T.30 [15] or T.38 [16] fax protocols. This tag has multiple attributes. The lclid attribute is a string that identifies the Media Server as the calling station in the DIS message. The lclid attribute is optional. The default is null. The <faxplay> request operates in one of three modes: send, remote poll, and turnaround poll. In send mode, the Media Server sends the fax. In remote poll mode, the Application Server places a call on behalf of the Media Server. The Media Server requests a fax transmission from the remote fax terminal. In turnaround poll mode, the Media Server will record a fax that the remote machine sends. If the remote machine requests a transmission, then the Media Server will send the fax. The recurl attribute is the URI to record the fax to, if specified. The Media Server will advertise in the DIS message it can receive fax transmissions. The prompturl attribute is the URI to fetchserver. For example, thefax to transmit,reason | | | | | phrase "Not Found" would be returned | | | | | ifspecified. The Media Server will advertise in the DIS message it can send fax transmissions. The rmtid attribute specifiesthecalling station identifier ofrequested content was not | | | | | found | | context | | R | Contains theremote terminal. If specified,content URL that was | | | | | being fetched when themedia server MUST reject transactions withretrieval | | | | | error occurred. This enables theremote terminal if| | | | | client to know precisely which URL in | | | | | a sequence caused theremote terminal's identifier does not match rmtid.problem. | +-----------+---------+-----+---------------------------------------+ Table 34: Attributes of <error_info> Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page25]73] Internet-Draft MSCMLDecember 2004 The combination of prompturlFebruary 2006 An <error_info> element MAY be present in the response to any request which contains a child <prompt> element. 10.5. Response Attributes andrecurl defineElements for <playcollect> In addition to themode. Seebase response attributes defined in Table3. +----------------+----------------+----------------+----------------+30, responses to <playcolect> requests have the additional attributes described in Table 35. +--------------+---------+-----+------------------------------------+ |prompturlAttribute |recurlDefault |ModeR/O |OperationDescription |+----------------+----------------+----------------+----------------++--------------+---------+-----+------------------------------------+ |noreason |no|InvalidO |Request fails.For requests that do not complete | |yes|no|Send|Send fax fromimmediately, the "reason" | | | | |prompturl. Ifattribute conveys additional | | | | |rmtid isinformation regarding why the | | | | |specified, itcommand completed. Possible values | | | | |must matchare "stopped", indicating an | | | | | explicit or implicit <stop> | | | | | request was received, "match" | | | | | meaning a DTMF grammar was | | | | | matched, "timeout" indicating that | | | | | no DTMF input was received before | | | | | one of the collection timers | | | | |remoteexpired, and "returnkey" or | | | | |terminal's"escapekey" meaning the DTMF digit | | | | |identifier, ormapped to that key was detected. | | | | | thereceivereturn key or escape key | | | | |request willterminated the operation, | | | | |fail.respectively. | |noplayduration |yes|PollR |Send fax fromA time value (Section 4.2.1) that | | | | |prompturl,returns the duration of the | | | | |assumingassociated content playout. If the | | | | |remotecaller barged the prompt this | | | | |terminalvalue will reflect the play | | | | |specifies itduration up to that event. | Van Dyke, et al. Expires September 1, 2006 [Page 74] Internet-Draft MSCML February 2006 | playoffset | | R |can receive aA time value (Section 4.2.1) that | | | | |fax in its DISreturns the time offset into the | | | | |message. Itspecified content sequence where | | | | | play was terminated. If theremote| | | | |terminal doesinitial "offset" value in the | | | | |not supportsequence was "0", then | | | | |reverse"playduration" and "playoffset" | | | | |polling,are equal. However, if the the | | | | |request willinitial offset had some other | | | | |fail. Ifvalue "playoffset" serves as a | | | | |rmtid isbookmark for the client to resume | | | | |specified, itplay in a subsequent request. If | | | | |must matchthe caller barged the prompt this | | | | |remotevalue will reflect the time offset | | | | |terminal'sat which barge-in occurred. | | digits | | R |identifier, orContains the collected DTMF input | | | | |the requestcharacters. If no DTMF input was | | | | |will fail.collected this attribute is set to | |yes|yes|Turnaround|Iftheremoteempty string (""). | | name | |PollO* |terminalThe client defined name of the | | | | |wishes toDTMF grammar that was matched. | | | | |transmit,*This attribute is required if the | | | | |Media Server"name" attribute was set in the | | | | |recordsmatching DTMF grammar. | +--------------+---------+-----+------------------------------------+ Table 35: MSCML Response Attributes for <playcollect> Responses to <playcollect> requests MAY include an <error_info> element as described in Section 10.4.1. 10.6. Response Attributes and Elements for <playrecord> In addition to the base response attributes defined in Table 30, responses to <playrecord> requests have the|additional attributes described in Table 36. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page26]75] Internet-Draft MSCMLDecember 2004 | | | | fax into | | | | | recurl. If | | | | | the remote |February 2006 +--------------+---------+-----+------------------------------------+ | Attribute | Default | R/O |terminalDescription | +--------------+---------+-----+------------------------------------+ | reason | | O |wishes toFor requests that do not complete | | | | |receive,immediately, the "reason" | | | | |Media Serverattribute conveys additional | | | | |sendsinformation regarding why thefax | | | | | from | | | | | prompturl. If| | | | |rmtid iscommand completed. Possible values | | | | |specified, itare "stopped", indicating an | | | | |must matchexplicit or implicit <stop> | | | | |remoterequest was received, "digit" | | | | |terminal'smeaning a DTMF digit was detected | | | | |identifier, orso the prompt phase was barged, | | | | | "init_silence" meaning thesend| | | | |request will |recording terminated because | | | |fail. A| because of no input, "end_silence" | | | |receive| meaning the recording was | | | |operation will| terminated because the | | | |still succeed,| "endsilence" timer elapsed, | | | |however.|+----------------+----------------+----------------+----------------+ Table 3: Fax Send Modes The Media Server MUST flush any quarantined digits when it receives a <faxplay> request. 8. Response Attributes and Return Codes 8.1 Mechanism The Media Server acknowledges receipt of an application request by sending a response of either 200 OK or 415 BAD MEDIA TYPE. (The latter is sent when the SIP request contains a content type other than "application/sdp" or "application/mediaservercontrol+xml"). The <response> message is transported in a SIP INFO request. If there is an error in the request or the request cannot be completed, the <response> message is sent very shortly after receiving the request. If the request is able to proceed, the <response> contains final status information as listed below. Van Dyke, et al. Expires June 25, 2005 [Page 27] Internet-Draft MSCML December 2004 8.2 <response> Attributes If the request specified an ID, the response will echoed the ID. The "code" is"max_duration" indicating that theresult code| | | | | maximum time for therequest. It can takerecording was | | | | | reached, "escapekey" indicating | | | | | thefollowing values. o 200 indicates command completed. o 400 for <playrecord>, <faxrecord>, and <faxplay> indicates command not accepted dueDTMF input mapped toan error. The text attribute describes the cause of| | | | | "escapekey" was detected, thus | | | | | terminating theerror. o 501 for <playrecord>, <faxrecord>,recording and<faxplay> indicates an error because the media server does not support| | | | | "error" indicating a general | | | | | operation failure. | | playduration | | R | A time value (Section 4.2.1) that | | | | | returns theURL type specified. The "digits" areduration of thereturned digits for <playcollect> and <playrecord>. Its value is| | | | | associated content playout. If thecollected digits, if any. The "reason" is why| | | | | caller barged thecommand terminated. For all requests,prompt this | | | | | value will reflect thereason "stopped" indicatesplay | | | | | duration up to thata <stop> request, another command, or a re-INVITE with hold media stopped the request. Forevent. | | playoffset | | R | A time value (Section 4.2.1) that | | | | | returns the<play> request,time offset into the"EOF" reason means| | | | | specified content sequence where | | | | | play was terminated. If themedia server played out to| | | | | initial "offset" value in theend of| | | | | sequence was "0", then | | | | | "playduration" and "playoffset" | | | | | are equal. However, if thefile. Forthe<playcollect> request, a reason of "match" means| | | | | initial offset had some other | | | | | value "playoffset" serves as amatch was found; "timeout" means no digit was received before| | | | | bookmark for thetime-out timer expired; "returnkey" and "escapekey" meansclient to resume | | | | | play in a subsequent request. If | | | | | thereturn key or escape key terminatedcaller barged theoperation, respectively; and "interrupted" means another request interruptedprompt this | | | | | value will reflect the<playcollect> request. Fortime offset | | | | | at which barge-in occurred. | Van Dyke, et al. Expires September 1, 2006 [Page 76] Internet-Draft MSCML February 2006 | digits | | R | Contains the<playrecord> request, a reason of "digit" means aDTMF digitwas detected; "end_silence" means the recordingthat | | | | | terminatedbecausethetrailing silence timer expired; "init_silence" means thatrecording. If novoice| | | | | DTMF input wasdetected; "max_duration" meansdetected this | | | | | attribute is set to therecording terminated becauseempty | | | | | string (""). | | reclength | | R | The length of themaximumrecorded content | | | | | in bytes. | | recduration | | R | A time value (Section 4.2.1) | | | | | indicating the elapsed duration of | | | | | the recording. | +--------------+---------+-----+------------------------------------+ Table 36: MSCML Response Attributes forrecording completed; "escapekey" means<record> Responses to <playrecord> requests MAY include an <error_info> element as described in Section 10.4.1. 10.7. Response Attributes and Elements for <managecontent> Responses to <managecontent> requests have only the base response attributes defined in Table 30. If a content transfer error occurs while executing theuser enteredrequest theescape keyresponse will also contain an <error_info> element as described ineither play or record mode, thus terminating the recording; or "error",Section 10.4.1. 10.8. Response Attributes and Elements fora general operation failure. For<faxplay> and <faxrecord> In addition to the base response attributes defined in Table 30, responses to <faxplay> and <faxrecord>requests, arequests have the additional attributes described in Table 37. Van Dyke, et al. Expires September 1, 2006 [Page 77] Internet-Draft MSCML February 2006 +----------------+---------+-----+----------------------------------+ | Attribute | Default | R/O | Description | +----------------+---------+-----+----------------------------------+ | reasonof| | R | For requests that do not | | | | | complete immediately, the | | | | | "reason" attribute conveys | | | | | additional information regarding | | | | | why the command completed. | | | | | Possible values are "stopped", | | | | | indicating an explicit or | | | | | implicit <stop> request was | | | | | received, "complete"meansindicating | | | | | successful completion, even if | | | | | there were bad lines or minor | | | | | negotiationproblems, i.e.,problems (e.g. a DCN | | | | | wasreceived;received), "disconnect"means| | | | | meaning that the session wasdisconnected;| | | | | disconnected and "notfax"means| | | | | indicationg that no DIS or DCS | | | | | was received on the connection. | | pages_received | | O* | Indicates the number of fax | | | | | pages received. *Required if any | | | | | pages were received. | | pages_sent | | O* | Indicates the number of fax | | | | | pages sent. *Required if any | | | | | pages were sent. | | faxcode | | R | The"reclength"value of the "faxcode" | | | | | attribute is thelengthbinary-or of | | | | | therecordingbit patterns defined inbytes| | | | | Table 38. | +----------------+---------+-----+----------------------------------+ Table 37: MSCML Response Attributes fora <playrecord>.<faxplay> and <faxrecord> Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page28]78] Internet-Draft MSCMLDecember 2004 The "text" is the descriptive text associated with the response code. For the <faxplay> and <faxrecord> requests, the faxcode attribute is the binary-or of the following bit patterns.February 2006 +------+--------------------------------------+ | Mask | description | +------+--------------------------------------+ | 0 | Operation Failed | | 1 | Operation Succeeded | | 2 | Partial Success | | 4 | Image received and placed in recurl | | 8 | Image sent fromprompturlspecified source URL | | 16 | rmtid did not match | | 32 | Error readingprompturlsource URL | | 64 | Error writing recurl | | 128 | Negotiation failure on send phase | | 256 | Negotiation failure on receive phase | | 512 | Reserved | | 1024 | Irrecoverable IP packet loss | | 2048 | Line errors in received image | +------+--------------------------------------+9.Table 38: Faxcode Mask Responses to <faxplay> and <faxrecord> requests MAY include an <error_info> element as described in Section 10.4.1. 11. Formal Syntax The following syntax specification usesthe augmented Data Type Definition (DTD)XML Schema as described in XML[5]. 9.1[7]. 11.1. Schema <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="MediaServerControl"> <xs:complexType> <xs:choice> <xs:element name="request"> <xs:complexType> <xs:choice> <xs:elementname="configure_conference"> <xs:complexType> <xs:sequence>name="configure_conference" type="configure_conferenceRequestType"/> <xs:elementname="inputgain" type="inputgainType" minOccurs="0"/>name="configure_leg" type="configure_legRequestType"/> <xs:elementname="outputgain" type="outputgainType" minOccurs="0"/>name="play" type="playRequestType"/> <xs:elementname="subscribe" minOccurs="0">name="playcollect" type="playcollectRequestType"/> <xs:element name="playrecord" Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page29]79] Internet-Draft MSCMLDecember 2004 <xs:complexType> <xs:sequence>February 2006 type="playrecordRequestType"/> <xs:elementname="events">name="managecontent" type="managecontentRequestType"/> <xs:element name="faxplay" type="faxRequestType"/> <xs:element name="faxrecord" type="faxRequestType"/> <xs:element name="stop" type="stopRequestType"/> </xs:choice> </xs:complexType> </xs:element> <xs:element name="response" type="responseType"/> <xs:element name="notification"> <xs:complexType><xs:sequence><xs:choice> <xs:elementname="activetalkers" type="activetalkersType"/> </xs:sequence>name="conference" type="conferenceNotificationType"/> <xs:element name="keypress" type="keypressNotificationType"/> <xs:element name="signal" type="signalNotificationType"/> </xs:choice> </xs:complexType> </xs:element></xs:sequence></xs:choice> <xs:attribute name="version" use="required"/> </xs:complexType> </xs:element></xs:sequence><!-- Definitions for base and concrete MSCML requests --> <!-- and embedded types. --> <xs:complexType name="base_requestType" abstract="true"> <xs:attribute name="id" type="xs:string"/> </xs:complexType> <xs:complexType name="playRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="prompt" type="promptType" minOccurs="0"/> </xs:sequence> <xs:attributename="reservedtalkers"name="prompturl" type="xs:string"/> <xs:attributename="reserveconfmedia"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> </xs:attribute>name="offset" type="xs:string"/> <xs:attribute name="promptencoding" type="xs:string"/> </xs:extension> </xs:complexContent> </xs:complexType></xs:element><xs:complexType name="configure_conferenceRequestType"> <xs:complexContent> Van Dyke, et al. Expires September 1, 2006 [Page 80] Internet-Draft MSCML February 2006 <xs:extension base="base_requestType"> <xs:sequence> <xs:elementname="configure_leg"> <xs:complexType>name="subscribe" type="conference_eventsubscriptionType" minOccurs="0"/> </xs:sequence> <xs:attribute name="reservedtalkers" type="xs:positiveInteger"/> <xs:attribute name="reserveconfmedia" type="yesnoType" default="yes"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="configure_legRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="inputgain"type="inputgainType"type="gainType" minOccurs="0"/> <xs:element name="outputgain"type="outputgainType"type="gainType" minOccurs="0"/> <xs:element name="configure_team" type="configure_teamType" minOccurs="0"/> <xs:element name="subscribe" type="leg_eventsubscriptionType" minOccurs="0"/> </xs:sequence> <xs:attributename="id" type="xs:string"/> <xs:attributename="type"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="talker"/> <xs:enumeration value="listener"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="mixmode"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="full"/> <xs:enumeration value="mute"/>Van Dyke, et al. Expires June 25, 2005 [Page 30] Internet-Draft MSCML December 2004<xs:enumeration value="preferred"/> <xs:enumeration value="parked"/></xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="dtmfclamp"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/><xs:enumerationvalue="no"/>value="private"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attributename="toneclamp"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> </xs:attribute>name="dtmfclamp" type="yesnoType"/> <xs:attribute name="toneclamp" type="yesnoType"/> </xs:extension> </xs:complexContent> Van Dyke, et al. Expires September 1, 2006 [Page 81] Internet-Draft MSCML February 2006 </xs:complexType></xs:element> <xs:element name="play"> <xs:complexType> <xs:sequence minOccurs="0"><xs:complexType name="configure_teamType"> <xs:sequence> <xs:elementname="prompt" type="promptType"/>name="teammate" type="teammateType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string"/> <xs:attributename="prompturl" type="xs:string"/> <xs:attribute name="offset" type="xs:string"/> <xs:attribute name="promptencoding" type="xs:string"/> </xs:complexType> </xs:element> <xs:element name="playcollect"> <xs:complexType> <xs:sequence> <xs:element name="prompt" type="promptType" minOccurs="0"/> <xs:element name="regex" minOccurs="0"> <xs:complexType> <xs:attribute name="type" default="regex">name="action" use="required"> <xs:simpleType> <xs:restrictionbase="xs:NMTOKEN">base="xs:string"> <xs:enumerationvalue="regex"/>value="add"/> <xs:enumerationvalue="mgcpdigitmap"/> </xs:restriction> </xs:simpleType> Van Dyke, et al. Expires June 25, 2005 [Page 31] Internet-Draft MSCML December 2004value="delete"/> <xs:enumeration value="query"/> <xs:enumeration value="set"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> <xs:complexType name="teammateType"> <xs:attributename="value"name="id" type="xs:string" use="required"/><xs:attribute name="id" type="xs:string"/></xs:complexType></xs:element><xs:complexType name="playcollectRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="prompt" type="promptType" minOccurs="0"/> <xs:element name="pattern" type="dtmfGrammarType" minOccurs="0"/> </xs:sequence> <xs:attributename="id" type="xs:string"/> <xs:attributename="prompturl" type="xs:string"/> <xs:attribute name="offset" type="xs:string"/> <xs:attribute name="barge"default="yes"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> </xs:attribute>type="yesnoType" default="yes"/> <xs:attribute name="promptencoding" type="xs:string"/> <xs:attribute name="cleardigits"type="xs:string" default="yes"/>type="yesnoType" default="no"/> <xs:attribute name="maxdigits" type="xs:string"/> <xs:attribute name="firstdigittimer"type="xs:string"/>type="xs:string" default="5000ms"/> <xs:attribute name="interdigittimer"type="xs:string"/>type="xs:string" default="2000ms"/> <xs:attribute name="extradigittimer" type="xs:string" default="1000ms"/> <xs:attribute name="interdigitcriticaltimer" type="xs:string"/> <xs:attribute name="skipinterval" type="xs:string" default="6s"/> <xs:attribute name="ffkey"type="xs:string"/>type="DTMFkeyType"/> Van Dyke, et al. Expires September 1, 2006 [Page 82] Internet-Draft MSCML February 2006 <xs:attribute name="rwkey"type="xs:string"/>type="DTMFkeyType"/> <xs:attribute name="returnkey"type="xs:string"type="DTMFkeyType" default="#"/> <xs:attribute name="escapekey"type="xs:string"type="DTMFkeyType" default="*"/> <xs:attribute name="maskdigits" type="yesnoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType></xs:element> <xs:element name="playrecord"> <xs:complexType> <xs:sequence minOccurs="0"><xs:complexType name="playrecordRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:element name="prompt"type="promptType"/>type="promptType" minOccurs="0"/> </xs:sequence> <xs:attributename="id"name="prompturl" type="xs:string"/> <xs:attributename="prompturl"name="promptencoding" type="xs:string"/> <xs:attribute name="offset"type="xs:string"/>type="xs:string" default="0"/> <xs:attributename="barge"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> Van Dyke, et al. Expires June 25, 2005 [Page 32] Internet-Draft MSCML December 2004 </xs:restriction> </xs:simpleType> </xs:attribute>name="barge" type="yesnoType" default="yes"/> <xs:attributename="cleardigits"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> </xs:attribute>name="cleardigits" type="yesnoType" default="no"/> <xs:attribute name="escapekey" type="xs:string" default="*"/> <xs:attribute name="recurl" type="xs:string" use="required"/> <xs:attribute name="mode" default="overwrite"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="append"/> <xs:enumeration value="overwrite"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="recencoding" type="xs:string"/> <xs:attribute name="initsilence" type="xs:string"/> <xs:attribute name="endsilence" type="xs:string"/> <xs:attribute name="duration" type="xs:string"/> <xs:attribute name="beep"default="yes">type="yesnoType" default="yes"/> <xs:attribute name="recstopmask" type="xs:string" default="01234567890*#"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="managecontentRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:attribute name="fetchtimeout" type="xs:string" default="10000"/> Van Dyke, et al. Expires September 1, 2006 [Page 83] Internet-Draft MSCML February 2006 <xs:attribute name="mimetype" type="xs:string"/> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="httpmethod"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumerationvalue="yes"/>value="put"/> <xs:enumerationvalue="no"/>value="post"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attributename="recstopmask"name="action"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="move"/> <xs:enumeration value="delete"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="dest" type="xs:string"/> <xs:attribute name="src" type="xs:string"default="01234567890*#"/>use="required"/> </xs:extension> </xs:complexContent> </xs:complexType></xs:element><xs:complexType name="stopRequestType"> <xs:complexContent> <xs:extension base="base_requestType"/> </xs:complexContent> </xs:complexType> <xs:complexType name="faxRequestType"> <xs:complexContent> <xs:extension base="base_requestType"> <xs:sequence> <xs:elementname="faxplay"> <xs:complexType>name="prompt" type="promptType" minOccurs="0"/> </xs:sequence> <xs:attribute name="lclid" type="xs:string"/> <xs:attribute name="prompturl" type="xs:string"/> <xs:attribute name="recurl" type="xs:string"/> <xs:attribute name="rmtid" type="xs:string"/> </xs:extension> </xs:complexContent> </xs:complexType></xs:element><xs:complexType name="dtmfGrammarType"> <xs:choice> <xs:element name="regex" type="dtmfPatternType" maxOccurs="unbounded"/> <xs:element name="mgcpdigitmap" type="dtmfPatternType"/> <xs:elementname="faxrecord">name="megacodigitmap" type="dtmfPatternType"/> </xs:choice> Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page33]84] Internet-Draft MSCMLDecember 2004 <xs:complexType> <xs:attribute name="lclid" type="xs:string"/> <xs:attribute name="prompturl" type="xs:string"/>February 2006 </xs:complexType> <xs:complexType name="dtmfPatternType"> <xs:attributename="recurl" type="xs:string"/>name="value" type="xs:string" use="required"/> <xs:attributename="rmtid"name="name" type="xs:string"/> </xs:complexType></xs:element> <xs:element name="stop"> <xs:complexType/> </xs:element> <xs:any namespace="##any"/> </xs:choice> </xs:complexType> </xs:element> <xs:element name="response"> <xs:complexType><!-- Definitions for base and concrete MSCML responses --> <!-- and embedded types. --> <xs:complexType name="base_responseType" abstract="true"> <xs:attribute name="request" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="configure_conference"/> <xs:enumeration value="configure_leg"/> <xs:enumeration value="play"/> <xs:enumeration value="playcollect"/> <xs:enumeration value="playrecord"/> <xs:enumeration value="managecontent"/> <xs:enumeration value="faxplay"/> <xs:enumeration value="faxrecord"/> <xs:enumeration value="stop"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="id" type="xs:string"/> <xs:attribute name="code" type="xs:string" use="required"/> <xs:attribute name="text" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="responseType"> <xs:complexContent> <xs:extension base="base_responseType"> <xs:sequence> <xs:element name="error_info" type="stoponerrorResponseType" minOccurs="0"/> <xs:element name="team" type="configure_teamResponseType" minOccurs="0"/> </xs:sequence> <xs:attribute name="reason" type="xs:string"/> <xs:attribute name="reclength" type="xs:string"/> <xs:attribute name="recduration" type="xs:string"/> <xs:attribute name="digits" type="xs:string"/> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="playduration" type="xs:string"/> <xs:attribute name="playoffset" type="xs:string"/> <xs:attribute name="faxcode" type="xs:string"/> <xs:attributename="pages_sent" type="xs:string"/>name="pages_sent" type="xs:string"/> <xs:attribute name="pages_recv" type="xs:string"/> </xs:extension> </xs:complexContent> Van Dyke, et al. Expires September 1, 2006 [Page 85] Internet-Draft MSCML February 2006 </xs:complexType> <xs:complexType name="stoponerrorResponseType"> <xs:attribute name="code" type="xs:string" use="required"/> <xs:attribute name="text" type="xs:string" use="required"/> <xs:attribute name="context" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="configure_teamResponseType"> <xs:sequence> <xs:element name="teammate" type="teammateType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="numteam" type="xs:integer" use="required"/> </xs:complexType> <!-- Definitions for MSCML event subscriptions and --> <!-- embedded types --> <xs:complexType name="conference_eventsubscriptionType"> <xs:sequence> <xs:element name="events"> <xs:complexType> <xs:sequence> <xs:element name="activetalkers" type="activetalkersSubscriptionType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="activetalkersSubscriptionType"> <xs:attribute name="report" type="yesnoType" use="required"/> <xs:attributename="pages_recv" type="xs:string"/>name="interval" type="xs:string" default="60s"/> </xs:complexType></xs:element> <xs:element name="notification"> <xs:complexType><xs:complexType name="leg_eventsubscriptionType"> <xs:sequence> <xs:elementname="conference">name="events"> <xs:complexType> <xs:sequence> <xs:element name="keypress" type="keypressSubscriptionType" minOccurs="0" maxOccurs="1"/> <xs:element name="signal" type="signalSubscriptionType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="keypressSubscriptionType"> Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page34]86] Internet-Draft MSCMLDecember 2004February 2006 <xs:attribute name="report" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="standard"/> <xs:enumeration value="long"/> <xs:enumeration value="both"/> <xs:enumeration value="none"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="maskdigits" type="yesnoType" default="no"/> </xs:complexType> <xs:complexType name="signalSubscriptionType"> <xs:attribute name="type" type="xs:NMTOKEN" use="required"/> <xs:attribute name="report" type="yesnoType" use="required"/> </xs:complexType> <!-- Definitions for MSCML event notifications and --> <!-- embedded types. --> <xs:complexType name="conferenceNotificationType"> <xs:sequence> <xs:element name="activetalkers"type="activetalkersType"/>type="activetalkersNotificationType" minOccurs="0"/> </xs:sequence> <xs:attribute name="uniqueid" type="xs:string" use="required"/> <xs:attribute name="numtalkers" type="xs:string" use="required"/> </xs:complexType></xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:choice> <xs:attribute name="version" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="1.0"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element><xs:complexTypename="activetalkersType">name="activetalkersNotificationType"> <xs:sequence minOccurs="0"> <xs:element name="talker" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="callid" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="keypressNotificationType"> <xs:sequence> <xs:element name="status" type="statusType"/> </xs:sequence> <xs:attributename="report" default="no">name="digit" type="DTMFkeyType" use="required"/> <xs:attribute name="length" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumerationvalue="yes"/>value="standard"/> <xs:enumerationvalue="no"/>value="long"/> </xs:restriction> Van Dyke, et al. Expires September 1, 2006 [Page 87] Internet-Draft MSCML February 2006 </xs:simpleType> </xs:attribute> <xs:attribute name="method" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="standard"/> <xs:enumeration value="long"/> <xs:enumeration value="double"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attributename="interval" type="xs:string"/>name="interdigittime" type="xs:string" use="required"/> </xs:complexType> <xs:complexTypename="autoType">name="statusType"> <xs:attributename="startlevel" type="xs:string"/>name="command" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="idle"/> <xs:enumeration value="play"/> <xs:enumeration value="collect"/> <xs:enumeration value="record"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attributename="targetlevel" type="xs:string"/>name="duration" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="signalNotificationType"> <xs:attributename="silencethreshold" type="xs:string"/>name="type" use="required" fixed="busy"/> </xs:complexType> <!-- Definitions for miscellaneous embedded, helper data types --> <xs:complexTypename="fixedType">name="promptType"> <xs:choice maxOccurs="unbounded"> <xs:element name="audio" type="promptcontentType"/> <xs:element name="variable" type="spokenvariableType"/> </xs:choice> <xs:attributename="level"name="locale" type="xs:string"/></xs:complexType><xs:attribute name="baseurl" type="xs:string"/> <xs:attribute name="stoponerror" type="yesnoType" default="no"/> <xs:attribute name="gain" type="xs:string" default="0"/> <xs:attribute name="gaindelta" type="xs:string" default="0"/> <xs:attribute name="rate" type="xs:string" default="0"/> <xs:attribute name="ratedelta" type="xs:string" default="0"/> <xs:attribute name="repeat" type="xs:string" default="1"/> <xs:attribute name="duration" type="xs:string" default="infinite"/> <xs:attribute name="offset" type="xs:string" default="0"/> <xs:attribute name="delay" type="xs:string" default="0"/> Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page35]88] Internet-Draft MSCMLDecember 2004 <xs:complexType name="inputgainType"> <xs:choice> <xs:element name="auto" type="autoType"/> <xs:element name="fixed" type="fixedType"/> </xs:choice> </xs:complexType> <xs:complexType name="outputgainType"> <xs:choice> <xs:element name="auto" type="autoType"/> <xs:element name="fixed" type="fixedType"/> </xs:choice>February 2006 </xs:complexType> <xs:complexTypename="promptType"> <xs:choice maxOccurs="unbounded"> <xs:element name="audio"> <xs:complexType>name="promptcontentType"> <xs:attribute name="url" type="xs:string" use="required"/> <xs:attribute name="encoding" type="xs:string"/> <xs:attribute name="gain" type="xs:string" default="0"/> <xs:attribute name="gaindelta" type="xs:string" default="0"/> <xs:attribute name="rate" type="xs:string" default="0"/> <xs:attribute name="ratedelta" type="xs:string" default="0"/> </xs:complexType></xs:element> <xs:element name="variable"> <xs:complexType><xs:complexType name="spokenvariableType"> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumerationvalue="date"/>value="dat"/> <xs:enumerationvalue="digit"/>value="dig"/> <xs:enumerationvalue="duration"/>value="dur"/> <xs:enumerationvalue="month"/>value="mth"/> <xs:enumerationvalue="money"/>value="mny"/> <xs:enumerationvalue="number"/>value="num"/> <xs:enumerationvalue="silence"/>value="sil"/> <xs:enumerationvalue="string"/>value="str"/> <xs:enumerationvalue="time"/>value="tme"/> <xs:enumerationvalue="weekday"/>value="wkd"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="subtype"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="mdy"/> <xs:enumeration value="dmy"/> <xs:enumeration value="ymd"/> <xs:enumeration value="ndn"/> <xs:enumeration value="t12"/> <xs:enumeration value="t24"/> <xs:enumeration value="USD"/>Van Dyke, et al. Expires June 25, 2005 [Page 36] Internet-Draft MSCML December 2004<xs:enumeration value="gen"/> <xs:enumeration value="ndn"/> <xs:enumeration value="crd"/> <xs:enumeration value="ord"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="value" type="xs:string" use="required"/> </xs:complexType></xs:element><xs:simpleType name="yesnoType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> Van Dyke, et al. Expires September 1, 2006 [Page 89] Internet-Draft MSCML February 2006 <xs:enumeration value="no"/> <xs:enumeration value="1"/> <xs:enumeration value="0"/> <xs:enumeration value="true"/> <xs:enumeration value="false"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="DTMFkeyType"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]"/> <xs:pattern value="[A-D]"/> <xs:pattern value="[a-d]"/> <xs:pattern value="#"/> <xs:pattern value="\*"/> </xs:restriction> </xs:simpleType> <xs:complexType name="gainType"> <xs:choice> <xs:element name="auto" type="autogainType"/> <xs:element name="fixed" type="fixedgainType"/> </xs:choice> </xs:complexType> <xs:complexType name="autogainType"> <xs:attributename="locale"name="startlevel" type="xs:string"/> <xs:attributename="baseurl"name="targetlevel" type="xs:string"/> <xs:attributename="gain_level" type="xs:string" default="0"/>name="silencethreshold" type="xs:string"/> </xs:complexType> <xs:complexType name="fixedgainType"> <xs:attributename="gain_delta" type="xs:string" default="0"/>name="level" type="xs:string"/> </xs:complexType> </xs:schema>10.12. IANA Considerations10.112.1. IANA Registration of MIME media typeapplication/mediaservercontrol+xmlapplication/ mediaservercontrol+xml MIME media type name: application MIME subtype name: mediaservercontrol+xml Required parameters: none Optional parameters: charset charset This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in XML Media Types[6].[8]. Van Dyke, et al. Expires September 1, 2006 [Page 90] Internet-Draft MSCML February 2006 Encoding considerations: See RFC3023[6].[8]. Interoperability considerations: See RFC2023[6][8] and RFCXXXX. Published specification: RFCXXXX Applications which use this media type: Multimedia, enhanced conferencing and interactive applications. Personal and email address for further information: eburger@brooktrout.com[22][29] Intended usage: COMMON11.13. Security Considerations Because media flows through a media server in a conference, the media server itself MUST protect the integrity, confidentiality, and security of the sessions. It should not be possible for a conference participant, on her own behalf, to be able to "tap in" to another conference without proper authorization.Van Dyke, et al. Expires June 25, 2005 [Page 37] Internet-Draft MSCML December 2004Because conferencing is a high value application, the media server SHOULD implement appropriate security measures. This includes, but not limited to, access lists for application servers. That is, the media server only allows a select list of application or proxy serversis allowedto create conferences, invite participants to sessions, etc. Note that the mechanisms for such security, like private networks, shared certificates, MAC white/black lists, arebeyondbeyond the scope of this document. Security concerns are one important reason MSCML limits requests with conference scope to a separate control leg per conference. MSCML uses the simple, proven, Internet-scale security model of SIP to determine if a client is who they say they are (authentication) and if they are allowed to create and manipulate a conference. However, the security model to enable a control leg to manipulate arbitrary conferences on the media server is extremely difficult. One would need to not only authenticate and authorize the basic conference primitives, but privacy considerations require policies for one client to access another client's conferences, even if the two clients are on the same host. For example, if the media server allowed any control leg to control any conference, an authorized, but unrelated client could maliciously attach itself to an existing session and record or tap the conversation without the participant's knowledge or consent. Participants give implicit authorization to their applications by virtue of the INVITE to the application. However, there is no trust, explicit or implicit, between the users of one service and a distinct client of another service. Van Dyke, et al. Expires September 1, 2006 [Page 91] Internet-Draft MSCML February 2006 Because of the sensitive nature of collected data, such as credit card numbers or other identifying information, the media server MUST support sips: and TLS. Clients, who presumably know the value of the information they collect, as well as the privacy expectations of their users, are free to use clear text signaling or encrypted, secure signaling, depending on the application's needs. Likewise, the media server SHOULD support SRTP [9]. Again, the clients are free to negotiate thescopeappropriate level of media security. All MSCML messages are sent within an INVITE created SIP dialog. As a result it would be difficult for an entity other than the original requestor to interfere with an established MSCML session, as thisdocument.would require detailed information on the dialog state. This allows multiple applications to simultaneously utilize the resources of a single media server without interfering with one another. As an XML markup, all of the security considerations of RFC3023[6][8] apply.12.14. References12.114.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2]Groves, C., Pantaleo, M., Anderson, T.Burger, E., Van Dyke, J., andT. Taylor, "Gateway Control Protocol Version 1",A. Spitzer, "Basic Network Media Services with SIP", RFC3525, June 2003.4240, December 2005. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [5] "Network call signalling protocol for the delivery oftime-criticaltime- critical services over cable television networks using cable modems", ITU-T J.162, March 2001.[5][6] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [7] Thompson, H., Beech, D., Maloney,M.M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, May 2001.[6][8] Murata, M., St. Laurent,S.S., and D. Kohn, "XML Media Types", Van Dyke, et al. Expires September 1, 2006 [Page 92] Internet-Draft MSCML February 2006 RFC 3023, January 2001.12.2 Informative References [7] Burger,[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,"Basic Network Media Services with SIP", draft-burger-sipping-netann-10 (work in progress), October 2004. [8] Johnston, A.andO.K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 14.2. Informative References [10] Levin, O., "Session Initiation Protocol Call Control - Conferencing for User Agents",draft-ietf-sipping-cc-conferencing-06draft-ietf-sipping-cc-conferencing-07 (work in progress),November 2004. [9]June 2005. [11] Carter, J., Danielsen, P., Hunt, A., Ferrans, J., Lucas, B., Porter, B., Rehor, K., Tryphonas, S., McGlashan,S.S., and D.Van Dyke, et al. Expires June 25, 2005 [Page 38] Internet-Draft MSCML December 2004Burnett, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C REC REC-voicexml20-20040316, March 2004.[10][12] International PacketCommunicaitonsCommunications Consortium, "IPCC Reference Architecture V2", June 2002.[11] Burger, E. and M. Dolly, "Keypad Stimulus Protocol (KPML)", draft-IETF-sipping-kpml-07 (work in progress), December 2004. [12] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-09 (work in progress), October 2004.[13] European Telecommunications Standards Institute, "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 version 7.2.0 Release 7)", December 2005. [14] Hollenbeck, S., Rose,M.M., and L. Masinter, "Guidelines for the Use of Extensible MarkupLanugageLanguage (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.[14][15] Jacobs, I., Lie, H., Bos, B., and C. Lilley, "Cascading Style Sheets, level 2 (CSS2) Specification", W3C REC REC-CSS2- 19980512, May 1998. [16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State",draft-ietf-sipping-conference-package-08draft-ietf-sipping-conference-package-12 (work in progress),December 2004. [15]July 2005. [17] Cable Television Laboratories, Inc., "Audio Server Protocol", January 2005. [18] "Procedures for document facsimile transmission in the general switched telephone network", Recommendation T.30, April 1999.[16][19] "Procedures for real-time Group 3 facsimile communication over IP networks", Recommendation T.38, March 2002.[17]Van Dyke, et al. Expires September 1, 2006 [Page 93] Internet-Draft MSCML February 2006 [20] Institute of Electrical and Electronics Engineers, "Information Technology - Portable Operating System Interface (POSIX) - Part 1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June 2001. [21] Burger, E. and M. Dolly, "Keypad Stimulus Protocol (KPML)", draft-IETF-sipping-kpml-07 (work in progress), December 2004. [22] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [23] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-09 (work in progress), October 2004. URIs[18][24] <http://www.ietf.org/html.charters/sip-charter.html>[19] <http://www.ietf.org/html.charters/sippin-charter.html> [20][25] <http://www.ietf.org/html.charters/sipping-charter.html> [26] <http://www.ietf.org/html.charters/mmusic.html>[21][27] <http://www.ietf.org/html.charters/xcon.html>[22][28] <http://www.3gpp.org/ftp/Specs/html-info/23228.htm> [29] <mailto:eburger@brooktrout.com> Appendix A. Regex Grammar Syntax The regular expression syntax used in MSCML is a telephony-oriented subset of POSIX Extended Regular Expressions (ERE) [20] termed Digit REGular EXpression (DRegex). This syntax was first described in KPML [21]. DRegex includes ordinary characters, special characters, bracket expressions and interval expressions. These entities are defined in the list below. character matches digits 0-9, *, #, and A-D (case insensitive) * matches the * character # matches the # character Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page39]94] Internet-Draft MSCMLDecember 2004 Authors' Addresses Jeff Van Dyke Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA EMail: jvandyke@brooktrout.com Eric Burger (editor) Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA EMail: eburger@brooktrout.com Andy Spitzer Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA EMail: woof@brooktrout.com Appendix A. Contributors Jeff Van Dyke, Andy Spitzer,February 2006 [character selector] matches any character in selector [range1-range2] matches any character in range from range1 to range2, inclusive x matches any digit 0-9 {m} matches m repetitions of the previous pattern {m,} matches m or more repetitions of the previous pattern {,n} matches at most n (including zero) repetitions of the previous pattern {m,n} at least m andTerence LoboatSnowShore Networks, Inc.most n repetitions of the previous pattern L the presence of 'L' in any regex expression causes the Media Server to enable "long" digit detection mode. See Section 7.1 for the definition of "long" digits. Table 39 illustrates DRegex usage through examples. +--------------+--------------------------------------------+ | Example | Description | +--------------+--------------------------------------------+ | 1 | Matches the digit 1 | | [179] | Matches 1, 7, or 9 | | [2-9] | Matches 2, 3, 4, 5, 6, 7, 8, 9 | | [02-46-9A-D] | Matches 0, 2, 3, 4, 6, 7, 8, 9, A, B, C, D | | x | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 | | *6[179#] | Matches *61, *67, *69, or *6# | | x{10} | Ten digits (0-9) | | 011x{7,15} | 011 followed by seven to fifteen digits | | L* | Long star | +--------------+--------------------------------------------+ Table 39: DRegex Examples Appendix B. Contributors Jeff Van Dyke and Andy Spitzer did the concept, development, documentation, and execution forMSCML. The IVR implementation was influenced by original work byMSCML at SnowShore Networks, Inc. AndySpitzer while he wasSpitzer's orignal work at The Telephone Connection, Inc. influenced the IVR implementation. Mary Ann Leekley implemented the personalized mix feature and several other enhancements. Cliff Schornak of Commetrex and Jeff Van Dyke developed the facsimile service.Terence Lobo,Jai Cauvet, Rolando Herrero, SrinivasMotamarri, Haj Elfadil,Motamarri andEdwina NowickiAshish Patel contributedin being the first to eat what got cooked up.greatly by testing MSCML. Van Dyke, et al. Expires September 1, 2006 [Page 95] Internet-Draft MSCML February 2006 AppendixB.C. Acknowledgements The following individuals significantly assisted in the development, direction, or, most importantly, debugging of MSCML: oGaurav SrivastvaBrian Badger andSubhash VermaPhil Crable fromBayPacketsVerizon Business oJon HinckleyStephane Bastien fromSkyWave/Sestro Van Dyke, et al. Expires June 25, 2005 [Page 40] Internet-Draft MSCML December 2004BroadSoft o Peter Danielsen of Lucent Technologies o Kevin Flemming formerly of SnowShore Networks, Inc. o WesleyHicks,Hicks and Ravindra Kabre,Kevin Summersformerly from Sonus Networks o Jon Hinckley from SkyWave/Sestro o Terence Lobo formerly of SnowShore Networks, Inc. o Kunal Nawale formerly of SnowShore Networks, Inc. o Edwina Nowicki formerly of SnowShore Networks, Inc. o Diana Rawlins and Sharadha Vijayfromformerly of WorldCom oTim WongGaurav Srivastva and Subhash Verma fromZ-TelBayPackets oStephane BastienKevin Summers fromBroadSoftSonus Networks oKevin Flemming for his feedback on the semantics of creation versus configuration for conferencing.Tim Wong from at&t The authors would also like to thank ScottyFarber, technical writer extraordinaire, who turned our techno-geek into English.Farber for applying her considerable tecnhnical writing expertise to the documentation of MSCML. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page41]96] Internet-Draft MSCMLDecember 2004February 2006 Authors' Addresses Jeff Van Dyke Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA Email: jvandyke@brooktrout.com Eric Burger (editor) Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA Email: eburger@brooktrout.com Andy Spitzer Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA Email: woof@brooktrout.com Van Dyke, et al. Expires September 1, 2006 [Page 97] Internet-Draft MSCML February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society(2004).(2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.Van Dyke, et al. Expires June 25, 2005 [Page 42] Internet-Draft MSCML December 2004Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Van Dyke, et al. ExpiresJune 25, 2005September 1, 2006 [Page43]98] ----