RFC 5707
Media Server Markup Language (MSML)
Independent Submission A. Saleem Request for Comments: 5707 Y. Xin Category: Informational RadiSys ISSN: 2070-1721 G. Sharratt Consultant February 2010 Media Server Markup Language (MSML)Abstract
The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXML. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5707.
IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.Table of Contents
1. Introduction ....................................................4 2. Glossary ........................................................5 3. MSML SIP Usage ..................................................6 3.1. SIP INFO ...................................................7 3.2. SIP Control Framework ......................................8 4. Language Structure .............................................15 4.1. Package Scheme ............................................15 4.2. Profile Scheme ............................................18 5. Execution Flow .................................................19 6. Media Server Object Model ......................................21 6.1. Objects ...................................................21 6.2. Identifiers ...............................................23 7. MSML Core Package ..............................................26 7.1. <msml> ....................................................26 7.2. <send> ....................................................26 7.3. <result> ..................................................27 7.4. <event> ...................................................27 8. MSML Conference Core Package ...................................28 8.1. Conferences ...............................................28 8.2. Media Streams .............................................29 8.3. <createconference> ........................................31 8.4. <modifyconference> ........................................33 8.5. <destroyconference> .......................................34
8.6. <audiomix> ................................................35
8.7. <videolayout> .............................................36
8.8. <join> ....................................................43
8.9. <modifystream> ............................................45
8.10. <unjoin> .................................................46
8.11. <monitor> ................................................47
8.12. <stream> .................................................47
9. MSML Dialog Packages ...........................................51
9.1. Overview ..................................................51
9.2. Primitives ................................................53
9.3. Events ....................................................55
9.4. MSML Dialog Usage with SIP ................................56
9.5. MSML Dialog Structure and Modularity ......................57
9.6. MSML Dialog Core Package ..................................58
9.7. MSML Dialog Base Package ..................................63
9.8. MSML Dialog Group Package .................................81
9.9. MSML Dialog Transform Package .............................85
9.10. MSML Dialog Speech Package ...............................88
9.11. MSML Dialog Fax Detection Package ........................92
9.12. MSML Dialog Fax Send/Receive Package .....................93
10. MSML Audit Package ...........................................100
10.1. MSML Audit Core Package .................................100
10.2. MSML Audit Conference Package ...........................102
10.3. MSML Audit Connection Package ...........................106
10.4. MSML Audit Dialog Package ...............................108
10.5. MSML Audit Stream Package ...............................110
11. Response Codes ...............................................111
12. MSML Conference Examples .....................................113
12.1. Establishing a Dial-In Conference .......................113
12.2. Example of a Sidebar Audio Conference ...................117
12.3. Example of Removing a Conference ........................118
12.4. Example of Modifying Video Layout .......................118
13. MSML Dialog Examples .........................................120
13.1. Announcement ............................................120
13.2. Voice Mail Retrieval ....................................120
13.3. Play and Record .........................................122
13.4. Speech Recognition ......................................125
13.5. Play and Collect ........................................125
13.6. User Controlled Gain ....................................128
14. MSML Audit Examples ..........................................128
14.1. Audit All Conferences ...................................128
14.2. Audit Conference Dialogs ................................129
14.3. Audit Conference Streams ................................130
14.4. Audit All Connections ...................................131
14.5. Audit Connection Dialogs ................................131
14.6. Audit Connection Streams ................................132
14.7. Audit Connection with Selective States ..................133
15. Future Work ..................................................134
16. XML Schema ...................................................134 16.1. MSML Core ...............................................136 16.2. MSML Conference Core Package ............................140 16.3. MSML Dialog Packages ....................................148 16.4. MSML Audit Packages .....................................170 17. Security Considerations ......................................176 18. IANA Considerations ..........................................176 18.1. IANA Registrations for 'application' MIME Media Type ....176 18.2. IANA Registrations for 'text' MIME Media Type ...........178 18.3. URN Sub-Namespace Registration ..........................179 18.4. XML Schema Registration .................................180 19. References ...................................................181 19.1. Normative References ....................................181 19.2. Informative References ..................................182 Acknowledgments ..................................................1831. Introduction
Media servers contain dynamic pools of media resources. Control agents and other users of media servers (called media server clients) can define and create many different services based on how they configure and use those resources. Often, that configuration and the ways in which those resources interact will be changed dynamically over the course of a call, to reflect changes in the way that an application interacts with a user. For example, a call may undergo an initial IVR dialog before being placed into a conference. Calls may be moved from a main conference to a sidebar conference and then back again. Individual calls may be directly bridged to create small n-way calls or simple sidebars. None of these change the SIP [n1] dialog or RTP [i3] session. Yet these do affect the media flow and processing internal to the media server. The Media Server Markup Language (MSML) is an XML [n2] language used to control the flow of media streams and services applied to media streams within a media server. It is used to invoke many different types of services on individual sessions, groups of sessions, and conferences. MSML allows the creation of conferences, bridging different sessions together, and bridging sessions into conferences. MSML may also be used to create user interaction dialogs and allows the application of media transforms to media streams. Media interaction dialogs created using MSML allow construction of IVR dialog sessions to individual users as well as to groups of users participating in a conference. Dialogs may also be specified using other languages, VoiceXML [n5], which support complete single-party application logic to be executed on the media server.
MSML is a transport independent language, such that it does not rely on underlying transport mechanisms and language semantics are independent of transport. However, SIP is a typical and commonly used transport mechanism for MSML, invoked using the SIP URI scheme. This specification defines using MSML dialogs using SIP as the transport mechanism. A network connection may be established with the media server using SIP. Media received and transmitted on that connection will flow through different media resources on the media server depending on the requested service. Basic Network Media Services with SIP [n7] defines conventions for associating a basic service with a SIP Request-URI. MSML allows services to be dynamically applied and changed by a control agent during the lifetime of the SIP dialog. MSML has been designed to address the control and manipulation of media processing operations (e.g., announcement, IVR, play and record, automatic speech recognition (ASR), text to speech (TTS), fax, video), as well as control and relationships of media streams (e.g., simple and advanced conferencing). It provides a general- purpose media server control architecture. MSML can additionally be used to invoke other more complex IVR languages such as VoiceXML. The MSML control interface has been widely deployed in the industry, with numerous client-side and server-side implementations, since 2003. The in-service commercial deployments cover a wide variety of applications including, but not limited to, IP multimedia conferencing, network voice services, IVR, IVVR (interactive voice and video response), and voice/video mail.2. Glossary
Media Server: a general-purpose platform for executing real-time media processing tasks. This is a logical function that maps either to a single physical device or to a portion of a physical device. Media Server Client: an application that originates MSML requests to a media server and also referred to as a control agent in this specification. Network Connection: a participant that represents the termination on a media server of one or more RTP [i3] sessions (for example, audio and video) associated with a call. Network connections are established and removed using a session establishment protocol such as SIP. An instance of a network connection is independent of MSML processing instructions applied to it.
Dialog: an automated IVR participant. Examples of dialogs may be announcement players, IVR interfaces, or voice recorders. Dialogs may be defined in MSML or using VoiceXML [n5]. Conference: an intermediary function that provides multimedia mixing and other advanced conferencing services. This specification currently considers conferences with audio and/or video media types, but is extensible to other media types. Identifier: a name that is used to refer to a specific instance of an object on the media server, such as a conference or a dialog. Identifiers are composed of one or more terms where each term identifies an object class and instance. Object: the generic term for a media server entity that terminates, originates, or processes media. This specification defines four classes of objects and specifies mechanisms to create them, join them together, and destroy them. Participant Object: an object in a media server that sources original media in a call and/or receives and terminates media in a call. Intermediary Object: an object in a media server that acts on media within a call for the benefit of the participants. Independent Object: an object that can exist on a media server independent of other objects. Operator: an intermediary transformer that modifies or transforms a media stream. Examples of operators may be audio gain controls, video scaling, or voice masking. MSML defines operators as media transform objects, which transform media using operations such as gain control, when applied to media streams. Media Stream: a single media flow between two objects. A media stream has a media type and may be unidirectional or bidirectional.3. MSML SIP Usage
SIP is used to create and modify media sessions with a media server according to the procedures defined in RFC 3261 [n1]. Often, SIP third party call control [i4] will be used to create sessions to a media server on behalf of end users. MSML is used to define and change the service that a user connected to a media server will receive. MSML clients are application servers, soft-switches, or other forms of control agents, and SHOULD have an authorized security relationship with the media server. MSML itself does not define authorization mechanisms.
MSML transactions are originated based upon events that occur in the application domain. These events may be independent from any media or user interaction. For example, an application may wish to play an announcement to a conference warning that its scheduled completion time is approaching. Applications themselves are structured in many different ways. Their structure and requirements contribute to their selection of protocols and languages. To accommodate differing application needs, MSML has been designed to be neutral to other languages and independent of the transport used to carry it. MSML is purposely designed to be transport independent. In this release of the specification, SIP INFO [i5] and SIP Control Framework [i11] have been chosen for transport mechanisms for MSML, as described in the following sections.3.1. SIP INFO
SIP INVITE and INFO [i5] requests and responses MAY be used to carry MSML. INFO requests allow asynchronous mid-call messages within SIP with few additional semantics. In addition, there are existing widely deployed implementations of that method, it aids in initial developments that are closely coupled with SIP session establishment, and it allows MSML to be directly associated with user dialogs when third party call control is used. Although INFO is sometimes considered not to be a suitable general- purpose transport mechanism for messages within SIP, there have been proposals to make it more acceptable. MSML may evolve to include other SIP usage and/or to work with other protocols or as a stand- alone protocol established through SIP, in future releases of this document. MSML supports several models for client interaction. When clients use 3PCC to establish media sessions on behalf of end users, clients will have a SIP dialog for each media session. MSML MAY be sent on these dialogs. However the targets of MSML actions are not inferred from the session associated with the SIP dialog. The targets of MSML actions are always explicitly specified using identifiers as previously defined. An application, after interacting with a user, may want to affect multiple objects within a media server. For example, tones or messages are often played to a conference when connections are added or removed. A separate message may also be played to a participant as they are joined, or to moderators. Explicit identifiers, that is, not inferred from a transport mechanism, allow these multiple actions to be easily grouped into a single transaction sent on any SIP dialog.
MSML also supports a model of dedicated control associations. This supports decoupled application architectures where a client can control media server services without also establishing all of the media sessions itself. Control associations are created using SIP, but they do not have any associated media session. Although initially INFO messages will be sent on this SIP dialog, just as with dialogs associated with media sessions, it is possible that in the future, the SIP dialog will be used to establish a separate control session (defined in SDP [n9]) that does not use SIP as the transport for MSML messages. A media server using MSML also sends asynchronous events to a client using MSML scripts in SIP INFO. Events are sent based on previous MSML requests and are sent within the SIP dialog on which the MSML request that caused the event to be generated was received. If this dialog no longer exists when the event is generated, the event is discarded. Events may be generated during the execution of a dialog created by a <dialogstart> element. For example, dialogs can send events based on user input. VoiceXML dialogs, on the other hand, generally interact with other servers outside of MSML using HTTP. An event is also generated when the execution of a dialog terminates, because of either completion or failure. The exact information returned is dependent on the dialog language, the capabilities of the dialog execution environment, and what was requested by the dialog. Both MSML and VoiceXML [n5] allow information to be returned when they exit. These events may be sent in a SIP INFO or a SIP BYE. SIP BYE is used when the dialog itself specifies that the connection should be disconnected, for example, through the use of the <disconnect> element. Conferences may also generate events based upon their configuration. An example of this is the notification of the set of active speakers.3.2. SIP Control Framework
The SIP Control Framework [i11] MAY be used as a transport mechanism for MSML. The Control Framework provides a generic approach for establishment and reporting capabilities of remotely initiated commands. The framework utilizes many functions provided by the Session Initiation Protocol (SIP) [n1] for the rendezvous and establishment of a reliable channel for control interactions. Compared to SIP INFO, the
SIP Control Framework is a more general-purpose transport mechanism and one that is not constrained by limitations of the SIP INFO mechanism. The Control Framework also introduces the concept of a Control Package, which is an explicit usage of the Control Framework for a particular interaction set. This specification has already specified a list of packages for MSML to control the media server in many aspects, including basic dialog, advanced conferencing, advanced dialog, and audit service. Each of these packages has a unique Control Package name assigned in order for MSML to be used with the Control Framework. This section fulfills the mandatory requirement for information that MUST be specified during the definition of a Control Framework Package, as detailed in SIP Control Framework [i11].3.2.1. Control Framework Package Names
The Control Framework [i11] requires a Control Package definition to specify and register a unique name. MSML specification defines Control Package names using a hierarchical scheme to indicate the inherited relationship across packages. For example, package "msml-x" is derived from package "msml", and package "msml-x-y" is derived from package "msml-x". The following is a list of Control Package names reserved by the MSML specification. "msml": this Control Package supports MSML Core Package as specified in section 7. "msml-conf": this Control Package supports MSML Conference Core Package as specified in section 8. "msml-dialog": this Control Package supports MSML Dialog Core Package as specified in section 9.6. "msml-dialog-base": this Control Package supports MSML Dialog Base Package as specified in section 9.7. "msml-dialog-group": this Control Package supports MSML Dialog Group Package as specified in section 9.8. "msml-dialog-transform": this Control Package supports MSML Dialog Transform Package as specified in section 9.9.
"msml-dialog-speech": this Control Package supports MSML Dialog
Speech Package as specified in section 9.10.
"msml-dialog-fax-detect": this Control Package supports MSML Dialog
Fax Detection Package as specified in section 9.11.
"msml-dialog-fax-sendrecv": this Control Package supports MSML Dialog
Fax Send/Receive Package as specified in section 9.12.
"msml-audit": this Control Package supports MSML Audit Core Package
as specified in section 10.1.
"msml-audit-conf": this Control Package supports MSML Audit
Conference Package as specified in section 10.2.
"msml-audit-conn": this Control Package supports MSML Audit
Connection Package as specified in section 10.3.
"msml-audit-dialog": this Control Package supports MSML Audit Dialog
Package as specified in section 10.4.
"msml-audit-stream": this Control Package supports MSML Audit Stream
Package as specified in section 10.5.
An application server using the Control Framework as transport for
MSML MUST use one or multiple package names, depending on the service
required from the media server. The package name(s) are identified
in the "Control-Packages" SIP header that is present in the SIP
INVITE dialog request that creates the control channel, as specified
in [i11]. The "Control-Packages" value MAY be re-negotiated via the
SIP re-INVITE mechanism.
3.2.2. Control Framework Messages
The usage of CONTROL, response, and REPORT messages, as defined in
[i11], by each Control Package defined in MSML is different and
described separately in the following sections.
MSML Core Package "msml"
The application server may send a CONTROL message with a body
of MSML request using the following elements to the MS:
<msml>: the root element that may contain a list of child
elements that request a specific operation. The child elements
are defined in extended packages (e.g., "msml-conf" and "msml-
dialog"). This element is also the root element that contains
an MSML result and event.
<send>: sends an event to the specified recipient within the
media server. Specific event types are defined within the
extended packages.
The media server replies with a response message containing a
MSML result using the following elements:
<result>: reports the results of an MSML transaction.
The media server MAY send the MSML event to the application
server, in a REPORT or CONTROL message, using the element
<event>. The actual content of the <event> and which Control
Framework message to use are defined within the extended
packages.
MSML Conference Core Package "msml-conf"
This package extends the MSML Core Package to define a
framework for creation, manipulation, and deletion of a
conference.
The AS can send a CONTROL message with a body of the MSML
request that contains one or multiple conference-related
commands to the MS. The MS then replies with a response
message with a body of the MSML result to indicate whether or
not the request has been fulfilled.
During the lifetime of a conference, whenever an event occurs,
the media server MAY send CONTROL messages containing MSML
events to notify the application server. The application
server SHOULD reply with a response message with no MSML body
to acknowledge the event has been received.
This package does NOT use the REPORT message.
Dialog Core Package "msml-dialog"
This package extends the MSML Core Package to define the
structural framework and abstractions for MSML dialogs.
The application server MAY send CONTROL messages containing a
MSML request using the following elements:
<dialogstart>: instantiate an MSML media dialog on a connection
or a conference.
<dialogend>: terminates an MSML dialog.
<send>: sends an event and an optional namelist to the dialog,
dialog group, or dialog primitive.
<exit>: used by the dialog description language to cause the
execution of the MSML dialog to terminate.
For the <dialogstart> command, the response message MUST
contain an MSML result that indicates that the dialog has been
started successfully. The MSML result MAY contain <dialogid>
to return the dialog identifier, if the identifier was assigned
by the media server. Subsequently, zero or more MSML events
MAY be initiated by the media server in (update) REPORT
messages to report information gathered during the dialog.
Finally, an MSML event "msml.dialog.exit" SHOULD be generated
in a (terminate) REPORT message when the dialog terminates
(e.g., MSML execution of <exit>).
For the <dialogend> and <send> commands, the response message
contains the final MSML result that indicates that the request
has either been fulfilled or rejected.
Dialog Base Package "msml-dialog-base"
This package extends the MSML Dialog Core Package to define a
set of base functionality for MSML dialogs. The extension
defines individual media primitives, including <play>,
<dtmfgen>, <tonegen>, <record>, <dtmf> and <collect>, to be
used as child element of <dialogstart>. This package does not
change the framework message usage as defined by the MSML
Dialog Core Package.
Dialog Transform Package "msml-dialog-transform"
This package extends the MSML Dialog Core Package to define a
set of transform primitives that works as filter on half-duplex
media streams. The extension defines transform primitives,
including <vad>, <gain>, <agc>, <gate>, <clamp> and <relay>,
that MAY be used as child elements of <dialogstart>. This
package does not change the framework message usage as defined
by the MSML Dialog Core Package.
Dialog Group Package "msml-dialog-group"
This package extends the MSML Dialog Core, Base, and Transform
Packages to define a single control flow construct that
specifies concurrent execution of multiple media primitives.
The extension defines the <group> element that MAY be used as a
child element of <dialogstart> to enclose multiple media
primitives, such that they can be executed concurrently. This
package does not change the framework message usage as defined
by the MSML Dialog Core Package.
Dialog Speech Package "msml-dialog-speech"
This package extends the MSML Dialog Core and MSML Base Package
to define functionality that MAY be used for automatic speech
recognition and text to speech. The extension extends the
<dialogstart> and the <play> elements.
For <dialogstart>, it defines a new child element <speech> to
activate grammars or user input rules associated with speech
recognition. For <play>, it defines a new child element <tts>
to initiate the text-to-speech service.
This package does not change the framework message usage as
defined by the MSML Dialog Core Package.
Dialog Fax Detection Package "msml-dialog-fax-detect"
This package extends the MSML Dialog Core Package to define
primitives provide fax detection service. The extension
defines a primitive <faxdetect> to be used as a child element
of <dialogstart>. This package does not change the framework
message usage as defined by the MSML Dialog Core Package.
Dialog Fax Send/Receive Package "msml-dialog-fax-sendrecv"
This package extends the MSML Dialog Core Package to define
primitives that allow a media server to provide fax send or
receive service. The extension defines new primitives
<faxsend> and <faxrcv>, to be used as a child element of
<dialogstart>. This package does not change the framework
message usage as defined by the MSML Dialog Core Package.
Dialog Audit Core Package "msml-audit"
This package extends the MSML Core Package to define a
framework for auditing media resource(s) allocated on the media
server.
This package follows a simple request/response transaction,
allowing the application server to send CONTROL messages
containing MSML <audit> requests. The media server MUST reply
with a response message containing the result. The result is
contained within the <auditresult> element, returning the
queried state information.
This package does NOT use the REPORT message.
Dialog Audit Conference Package "msml-audit-conf"
This package extends the MSML Audit Core Package to define
conference specific states that MAY be queried via the <audit>
command and the corresponding response MUST be returned by the
<auditresult> element. This package does not change the
framework message usage as defined by the MSML Audit Core
Package.
Dialog Audit Connection Package "msml-audit-conn"
This package extends the MSML Audit Core Package to define
connection specific states that MAY be queried via the <audit>
command and the corresponding response MUST be returned by the
<auditresult> element. This package does not change the
framework message usage as defined by the MSML Audit Core
Package.
Dialog Audit Dialog Package "msml-audit-dialog"
This package extends the MSML Audit Core Package to define
dialog specific states that MAY be queried via the <audit>
command and the corresponding response MUST be returned by the
<auditresult> element. This package does not change the
framework message usage as defined by the MSML Audit Core
Package.
Dialog Audit Stream Package "msml-audit-stream"
This package extends the MSML Audit Core Package to define
stream specific states that MAY be queried via the <audit>
command and the corresponding response MUST returned by the
<auditresult> element. This package does not change the
framework message usage as defined by the MSML Audit Core
Package.
3.2.3. Common XML Support
The XML schema described in [i11] MUST be supported by all Control
Packages defined by MSML. However, the "connection-id" value MUST be
constructed as defined by MSML (i.e., the identifier MUST contain a
local dialog tag only, while the SIP Control Framework [i11] requires
that the "connection-id" contain both local and remote dialog tags).
3.2.4. Control Message Body
A valid CONTROL body message MUST conform to the MSML schema, as included in this specification, for the MSML package(s) used.3.2.5. REPORT Message Body
A valid REPORT body message MUST conform to the MSML schema, as included in this specification, for the MSML package(s) used.4. Language Structure
4.1. Package Scheme
The primary mechanism for extending MSML is the "package". A package is an integrated set of one or more XML schemas that define additional features and functions via new or extended use of elements and attributes. Each package, except for those defined in the current document, is defined in a separate standards document, e.g., an Internet Draft or an RFC. All packages that extend the base MSML functionality MUST include references to the MSML base set of schemas provided in the Internet Drafts. A schema in a package MUST only extend MSML; that is, it must not alter the existing specification. A particular MSML script will include references to all the schemas defining the packages whose elements and attributes it makes use of. A particular script MUST reference MSML base and optionally extension package(s). See the IANA Considerations section. Each package MUST define its own namespace so that elements or attributes with the same name in different packages do not conflict. A script using a particular element or attribute MUST prefix the namespace name on that element or attribute's name if it is defined in a package (as opposed to being defined in the base). MSML consists of a core package that provides structure without support for any specific feature set. Additional packages, relying on the core package, provide functional features. Any combination of additional packages may be used along with the core package. The following describes the set of MSML packages defined in this document.
+--------------------------------------------------------+
| MSML Core |
+--------------------------------------------------------+
/ \ \
+--------+ +--------+ +-------+
| Dialog | | Conf | | Audit |
| Core | | Core | | Core |
+--------+ +--------+ +-------+
________ \_______________________________________ |
------------------------------------------------ |
/ \ \ \ \ \ |
+------+ +---------+ +------+ +------+ +------+ +-------+ |
|Dialog| |Dialog | |Dialog| |Dialog| |Dialog| |Dialog | |
|Base | |Transform| |Group | |Speech| |Fax | |Fax | |
+------+ +---------+ +------+ +------+ |Detect| |Send/ | |
+------+ |Receive| |
+-------+ |
________________________|
-------------------------
/ \ \ \
+-----+ +-----+ +------+ +------+
|Audit| |Audit| |Audit | |Audit |
|Conf | |Conn | |Dialog| |Stream|
+-----+ +-----+ +------+ +------+
o MSML Core Package (Mandatory)
Describes the minimum base framework that MUST be implemented to
support additional core packages.
o MSML Conference Core Package (Conditionally Mandatory, for
Conferencing)
Describes the audio and multimedia basic and advanced conferencing
package that MAY be implemented.
o MSML Dialog Core Package (Conditionally Mandatory, for Dialogs)
Describes the dialog core package that MUST be implemented for any
dialog services. However, systems supporting conferencing only,
MAY omit support for MSML dialogs. The MSML Dialog Core Package
specifies the framework within which additional dialog packages
are supported. The MSML Dialog Base Package MUST be supported,
while all other dialog packages MAY be supported.
o MSML Dialog Base Package (Conditionally Mandatory, for Dialogs)
o MSML Dialog Group Package (Optional)
o MSML Dialog Transform Package (Optional)
o MSML Dialog Fax Detection Package (Optional)
o MSML Dialog Fax Send/Receive Package (Optional)
o MSML Dialog Speech Package (Optional)
o MSML Audit Core Package (Conditionally Mandatory, for Auditing)
Describes the audit core package that MUST be implemented to
support auditing services. The MSML audit core package specifies
the framework within which additional audit packages are
supported.
o MSML Audit Conference Package (Conditionally Mandatory, for
Auditing Conference, Conference Dialog, and Conference Stream)
o MSML Audit Connection Package (Conditionally Mandatory, for
Auditing Connection, Connection Dialog, and Connection Stream)
o MSML Audit Dialog Package (Conditionally Mandatory, for Auditing
Dialog, and MUST be used with either MSML Audit Conference
Package or MSML Audit Connection Package)
o MSML Audit Stream Package (Conditionally Mandatory, for Auditing
Stream, and MUST be used with either MSML Audit Conference
Package or MSML Audit Connection Package)
The formal process for defining extensions to MSML dialogs is to
define a new package. The new package MUST provide a text
description of what extensions are included and how they work. It
MUST also define an XML schema file (if applicable) that defines the
new package (which may be through extension, restriction of an
existing package, or a specific profile of an existing package).
Dependencies upon other packages MUST be stated. For example, a
package that extends or restricts has a dependency on the original
package specification. Finally, the new package MUST be assigned a
unique name and version.
The types of things that can be defined in new packages are:
o new primitives
o extensions to existing primitives (events, shadow variables,
attributes, content)
o new recognition grammars for existing primitives
o new markup languages for speech generation
o languages for specifying a topology schema
o new predefined topology schemas
o new variables / segment types (sets & languages)
o new control flow elements
MSML packages are assembled together to form a specific MSML profile
that is shared between different implementations. The base MSML
dialog profiles that are defined in this document consist of the MSML
Core Package, MSML Dialog Core Package, MSML Dialog Base Package,
MSML Dialog Group Package, MSML Transform Package, MSML Fax Packages,
and the MSML Speech Package.
MSML extension packages, which define primitives, MUST define the
following for each primitive within the package:
o the function that the primitive performs
o the attributes that may be used to tailor its behavior
o the events that it is capable of understanding
o the shadow variables that provide access to information
determined as a result of the primitive's operation
The mechanism used to ensure that a media server and its client share
a compatible set of packages is not defined. Currently, it is
expected that provisioning will be used, possibly coupled with a
future auditing capability. Additionally, when used in SIP networks,
packages could be defined using feature tags and the procedures
defined for Indicating User Agent Capabilities in SIP [i1] used to
allow a media server to describe its capabilities to other user
agents.
4.2. Profile Scheme
Not all devices and applications using MSML will need to support the
entire MSML schema. For example, a media processing device might
support only audio announcements, only audio simple conferencing, or
only multimedia IVR. It is highly desirable to have a system for
describing what portion of MSML a particular media processing device
or control agent supports.
The package scheme described earlier allows MSML functionality to be functionally grouped, relying on the MSML core package. This scheme allows a portion of the complete MSML specification to be implemented, on a per-package basis, and also creates a framework for future extension packages. However, within a given package, in some cases, only a subset of the package functionality may be required. In order to support subsets of packages, with greater degree of granularity than at the package level, a profile scheme is required. MSML package profiles would identify a subset of a given MSML package with specific definitions of elements and attributes. Each MSML package profile MUST be accompanied by one or more corresponding schemas. To use the examples above, there could be an audio announcements profile of the MSML Dialog Base Package, an audio simple conferencing profile of the MSML Conference Core Package, and a multimedia IVR profile of the MSML Dialog Base Package. MSML package profiles MUST be published separately from the MSML specification, in one or more standards documents (e.g., Internet Drafts or RFCs) dedicated to MSML package profiles. Profiles would not be registered with IANA and any organization would additionally be free to create its own profile(s) if required.
(page 19 continued on part 2)
