GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5707

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.

Saleem, et al. Informational [Page 1] RFC 5707 Media Server Markup Language February 2010

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

Saleem, et al. Informational [Page 2] RFC 5707 Media Server Markup Language February 2010

    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

Saleem, et al. Informational [Page 3] RFC 5707 Media Server Markup Language February 2010

 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 ..................................................183

1. 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.

Saleem, et al. Informational [Page 4] RFC 5707 Media Server Markup Language February 2010

 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.

Saleem, et al. Informational [Page 5] RFC 5707 Media Server Markup Language February 2010

 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.

Saleem, et al. Informational [Page 6] RFC 5707 Media Server Markup Language February 2010

 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.

Saleem, et al. Informational [Page 7] RFC 5707 Media Server Markup Language February 2010

 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

Saleem, et al. Informational [Page 8] RFC 5707 Media Server Markup Language February 2010

 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.

Saleem, et al. Informational [Page 9] RFC 5707 Media Server Markup Language February 2010

 "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.

Saleem, et al. Informational [Page 10] RFC 5707 Media Server Markup Language February 2010

       <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.

Saleem, et al. Informational [Page 11] RFC 5707 Media Server Markup Language February 2010

       <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

Saleem, et al. Informational [Page 12] RFC 5707 Media Server Markup Language February 2010

       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.

Saleem, et al. Informational [Page 13] RFC 5707 Media Server Markup Language February 2010

       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).

Saleem, et al. Informational [Page 14] RFC 5707 Media Server Markup Language February 2010

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.

Saleem, et al. Informational [Page 15] RFC 5707 Media Server Markup Language February 2010

         +--------------------------------------------------------+
         |                     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)

Saleem, et al. Informational [Page 16] RFC 5707 Media Server Markup Language February 2010

    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)

Saleem, et al. Informational [Page 17] RFC 5707 Media Server Markup Language February 2010

    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.

Saleem, et al. Informational [Page 18] RFC 5707 Media Server Markup Language February 2010

 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.

5. Execution Flow

 MSML assumes a model where there is a single control context within a
 media server for MSML processing.  That context may have one or many
 SIP [n1] dialogs associated with it.  It is assumed that any SIP
 dialogs associated with the MSML control context have been
 authorized, as appropriate, by mechanisms outside the scope of MSML.
 A media server control context maintains information about the state
 of all media objects and media streams within a media server.  It
 receives and processes all MSML requests from authorized SIP dialogs
 and receives all events generated internally by media objects and
 sends them on the appropriate SIP dialog.  An MSML request is able to
 create new media objects and streams, and to modify or destroy any
 existing media objects and streams.
 An MSML request may simply specify a single action for a media server
 to undertake.  In this case, the document is very similar to a simple
 command request.  Often, though, it may be more natural for a client
 to request multiple actions at one time, or the client would like
 several actions to be closely coordinated by the media server.
 Multiple MSML elements received in a single request MUST be processed
 sequentially in document order.

Saleem, et al. Informational [Page 19] RFC 5707 Media Server Markup Language February 2010

 An example of the first scenario would be to create a conference and
 join it with an initial participant.  An example of the second case
 would be to unjoin one or more participants from a main conference
 and join them to a sidebar conference.  In the first scenario,
 network latencies may not be an issue, but it is simpler for the
 client to combine the requests.  In the second case, the added
 network latency between separate requests could mean perceptible
 audio loss to the participant.
 Each MSML request is processed as a single transaction.  A media
 server MUST ensure that it has the necessary resources available to
 carry out the complete transaction before executing any elements of
 the request.  If it does not have sufficient resources, it MUST
 return a 520 response and MUST NOT execute the transaction.
 The MSML request MUST be checked for well-formedness and validated
 against the schema prior to executing any elements.  This allows XML
 [n2] errors to reported immediately and minimizes failures within a
 transaction and the corresponding execution of only part of the
 transaction.
 Each element is expected to execute immediately.  Elements such as
 <dialogstart>, which take an unpredictable amount of time, are
 "forked" and executed in a separate thread (see MSML Dialog
 Packages).  Once successfully forked, execution continues with the
 element following the </dialogstart>.  As such, MSML does not provide
 mechanisms to sequence or coordinate other operations with dialog
 elements.
 Processing within a transaction MUST stop if any errors occur.
 Elements that were executed prior to the error are not rolled back.
 It is the responsibility of the client to determine appropriate
 actions based upon the results indicated in the response.  Most
 elements MAY contain an optional "mark" attribute.  The value of that
 attribute from the last successfully executed element MUST be
 returned in an error response.  Note that errors that occur during
 the execution of a dialog occur outside the context of an MSML
 transaction.  These errors will be indicated in an asynchronous
 event.
 Transaction results are returned as part of the SIP request response.
 The transaction results indicate the success or failure of the
 transaction.  The result MUST also include identifiers for any
 objects created by a media server for which the client did not
 provide an instance name.  Additionally, if the transaction fails,
 the reason for the failure MUST be returned, as well as an indication
 of how much of the transaction was executed before the failure
 occurred SHOULD be returned.

Saleem, et al. Informational [Page 20] RFC 5707 Media Server Markup Language February 2010

6. Media Server Object Model

 Media servers are general-purpose platforms for executing real-time
 media processing tasks.  These tasks range in complexity from simple
 ones such as serving announcements, to complex ones, such as speech
 interfaces, centralized multimedia conferencing, and sophisticated
 gaming applications.
 Calls are established to a media server using SIP.  Clients will
 often use SIP third party call control (3PCC) [i4] to establish calls
 to a media server on behalf of end users.  However MSML does not
 require that 3PCC be used, only that the client and the media server
 share a common identifier for the call and its associated RTP [i3]
 sessions.
 Objects represent entities that source, sink, or modify media
 streams.  A media streams is a bidirectional or unidirectional media
 flow between objects on a media server.  The following subsections
 define the classes of objects that exist on a media server and the
 way these are identified in MSML.

6.1. Objects

 A media object is an endpoint of one or more media streams.  It may
 be a connection that terminates RTP sessions from the network or a
 resource that transforms or manipulates media.  MSML defines four
 classes of media objects.  Each class defines the basic properties of
 how object instances are used within a media server.  However, most
 classes require that the function of specific instances be defined by
 the client, using MSML or other languages such as VoiceXML.
 The following classes of media processing objects are defined.  The
 class names are given in parentheses:
    o network connection (conn)
    o conference (conf)
    o dialog (dialog)
 Network connection is an abstraction for the media processing
 resources involved in terminating the RTP session(s) of a call.  For
 audio services, a connection instance presents a full-duplex audio
 stream interface within a media server.  Multimedia connections have
 multiple media streams of different media types, each corresponding
 to an RTP session.  Network connections get instantiated through SIP
 [n1].

Saleem, et al. Informational [Page 21] RFC 5707 Media Server Markup Language February 2010

 A conference represents the media resources and state information
 required for a single logical mix of each media type in the
 conference (e.g., audio and video).  MSML models multiple mixes/views
 of the same media type as separate conferences.  Each conference has
 multiple inputs.  Inputs may be divided into classes that allow an
 application to request different media treatment for different
 participants.  For example, the video streams for some participants
 may be assigned to fixed regions of the screen while those for other
 participants may only be shown when they are speaking.
 A conference has a single logical output per media type.  For each
 participant, it consists of the audio conference mix, less any
 contributed audio of the participant, and the video mix shared by all
 conference participants.  Video conferences using voice activated
 switching have an optional ability to show the previous speaker to
 the current speaker.
 Conferences are instantiated using the <createconference> element.
 The content of the <createconference> element specifies the
 parameters of the audio and/or video mixes.
 Dialogs are a class of objects that represent automated participants.
 They are similar to network connections from a media flow perspective
 and may have one or more media streams as the abstraction for their
 interface within a media server.  Unlike connections, however,
 dialogs are created and destroyed through MSML, and the media server
 itself implements the dialog participant.  Dialogs are instantiated
 through the <dialogstart> element.  Contents of the <dialogstart>
 element define the desired or expected dialog behavior.  Dialogs may
 also be invoked by referencing VoiceXML as the dialog description
 language.
 Operators are functions that are used to filter or transform a media
 stream.  The function that an instance of an operator fulfills is
 defined as a property of the media stream.  Operators may be
 unidirectional or bidirectional and have a media type.
 Unidirectional operators reflect simple atomic functions such as
 automatic gain control, filtering tones from conferences, or applying
 specific gain values to a stream.  Unidirectional operators have a
 single media input, which is connected to the media stream from one
 object, and a single media output, which is connected to the media
 stream of a different object.
 Bidirectional operators have two media inputs and two media outputs.
 One media input and output is associated with the stream to one
 object, and the other input and output is associated with a stream to
 a different object.  Bidirectional objects may treat the media
 differently in each direction.  For example, an operator could be

Saleem, et al. Informational [Page 22] RFC 5707 Media Server Markup Language February 2010

 defined that changed the media sent to a connection based upon
 recognized speech or dual-tone multi-frequency (DTMF) received from
 the connection.  Operators are implicitly instantiated when streams
 are created or modified using the elements <join> and <modifystream>,
 respectively.
 The relationships between the different object classes (conf, conn,
 and dialog) are shown in the figure below.
            +--------------------------------------+
            |           Media Server               |
            |                                      |
            |------+                      ,---.    |
            |      |      +------+       /     \   |
 <== RTP ==>| conn |<---->| oper |<---->( conf  )  |
            |      |      +------+       \     /   |
            |------+                      `---'    |
            |   ^                           ^      |
            |   |                           |      |
            |   |   +------+    +------+    |      |
            |   |   |      |    |      |    |      |
            |   +-->|dialog|    |dialog|<---+      |
            |       |      |    |      |           |
            |       +------+    +------+           |
            +--------------------------------------+
 A single, full-duplex instance of each object class is shown together
 with common relationships between them.  An operator (such as gain)
 is shown between a connection and a conference and dialogs are shown
 participating both with an individual connection and with a
 conference.  The figure is not meant to imply only one-to-one
 relationships.  Conferences will often have hundreds of participants,
 and either connections or conferences may be interacting with more
 than one dialog.  For example, one dialog may be recording a
 conference while other dialogs announce participants joining or
 leaving the conference.

6.2. Identifiers

 Objects are referenced using identifiers that are composed of one or
 more terms.  Each term specifies an object class and names a specific
 instance within that class.  The object class and instance are
 separated by a colon ":" in an identifier term.
 Identifiers are assigned to objects when they are first created.  In
 general, either the MSML client or a media server may specify the
 instance name for an object.  Objects for which a client does not
 assign an instance name will be assigned one by a media server.

Saleem, et al. Informational [Page 23] RFC 5707 Media Server Markup Language February 2010

 Media server assigned instance names are returned to the client as a
 complete object identifier in the response to the request that
 created the object.
 It is meaningful for some classes of objects to exist independently
 on a media server.  Network connections may be created through SIP at
 any time.  MSML can then be used to associate their media with other
 objects as required to create services.  Conferences may be created
 and have specific resources reserved waiting for participant
 connections.
 Objects from these two classes, connections and conferences, are
 considered independent objects since they can exist on a standalone
 basis.  Identifiers for independent objects consist of a single term
 as defined above.  For example, identifiers for a conference and
 connection could be "conf:abc" or "conn:1234" respectively.  Clients
 that choose to assign instance names to independent objects must use
 globally unique instance names.  One way to create globally unique
 names is to include the domain name of the client as part of the
 name.
 Dialogs are created to provide a service to independent objects.
 Dialogs may act as a participant in a conference or interact with a
 connection similar to a two-participant call.  Dialogs depend upon
 the existence of independent objects, and this is reflected in the
 composition of their identifiers.  Operators modify the media flow
 between other objects, such as application of gain between a
 connection and a conference.  As operators are merely media transform
 primitives defined as properties of the media stream, they are not
 represented by identifiers and created implicitly.
 Identifiers for dialogs are composed of a structured list of slash
 ('/') separated terms.  The left-most term of the identifier must
 specify a conference or connection.  This serves as the root for the
 identifier.  An example of an identifier for a dialog acting as a
 conference participant could be:
    conf:abc/dialog:recorder
 All objects except connections are created using MSML.  Connections
 are created when media sessions get established through SIP.  There
 are several options clients and media servers can use to establish a
 shared instance name for a connection and its media streams.
 When media servers support multiple media types, the instance name
 SHOULD be a call identifier that can be used to identify the
 collection of RTP sessions associated with a call.  When MSML is used
 in conjunction with SIP and third party call control, the call

Saleem, et al. Informational [Page 24] RFC 5707 Media Server Markup Language February 2010

 identifier MUST be the same as the local tag assigned by the media
 server to identify the SIP dialog.  This will be the tag the media
 server adds to the "To" header in its response to an initial invite
 transaction.  RFC 3261 requires the tag values to be globally unique.
 An example of a connection identifier is: conn:74jgd63956ts.
 With third party call control, the MSML client acts as a back-to-back
 user agent (B2BUA) to establish the media sessions.  SIP dialogs are
 established between the client and the media server allowing the use
 of the media server local tag as a connection identifier.  If third
 party call control is not used, a SIP event package MAY be used to
 allow a media server to notify new sessions to a client that has
 subscribed to this information.
 Identifiers as described above allow every object in a media server
 to be uniquely addressed.  They can also be used to refer to multiple
 objects.  There are two ways in which this can currently be done:
    wildcards
    common instance names
 An identifier can reference multiple objects when a wildcard is used
 as an instance name.  MSML reserves the instance name composed of a
 single asterisk ('*') to mean all objects that have the same
 identifier root and class.  Instance names containing an asterisk
 cannot be created.  Wildcards MUST only be used as the right-most
 term of an identifier and MUST NOT be used as part of the root for
 dialog identifiers.  Wildcards are only allowed where explicitly
 indicated below.
 The following are examples of valid wildcards:
    conf:abc/dialog:*
    conn:*
 An example of illegal wildcard usage is:
    conf:*/dialog:73849
 Although identifiers share a common syntax, MSML elements restrict
 the class of objects that are valid in a given context.  As an
 example, although it is valid to join two connections together, it is
 not valid to join two IVR dialogs.

Saleem, et al. Informational [Page 25] RFC 5707 Media Server Markup Language February 2010

7. MSML Core Package

 This section describes the core MSML package that MUST be supported
 in order to use any other MSML packages.  The core MSML package
 defines a framework, without explicit functionality, over which
 functional packages are used.

7.1. <msml>

 <msml> is the root element.  When received by a media server, it
 defines the set of operations that form a single MSML request.
 Operations are requested by the contents of the element.  Each
 operation MAY appear zero or more times as children of <msml>.
 Specific operations are defined within the conference package and in
 the set of dialog packages.
 The results of a request or the contents of events sent by a media
 server are also enclosed within the <msml> element.  The results of
 the transaction are included as a body in the response to the SIP
 request that contained the transaction.  This response will contain
 any identifiers that the media server assigned to newly created
 objects.  All messages that a media server generates are correlated
 to an object identifier.  Objects and identifiers are discussed in
 section 6 (Media Server Object Model).
 Attributes:
    version: "1.1" Mandatory

7.2. <send>

 Events are used to affect the behavior of different objects within a
 media server.  The <send> element is used to send an event to the
 specified recipient within the media server.
 Attributes:
    event: the name of an event.  Mandatory.
    target: an object identifier.  When the identifier is for a
    dialog, it may optionally be appended with a slash "/" followed by
    the target to be included in an MSML dialog <send>.  Mandatory.
    valuelist: a list of zero or more parameters that are included
    with the event.

Saleem, et al. Informational [Page 26] RFC 5707 Media Server Markup Language February 2010

    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all mark attributes within an
    MSML document should be unique.

7.3. <result>

 The <result> element is used to report the results of an MSML
 transaction.  It is included as a body in the final response to the
 SIP request that initiated the transaction.  An optional child
 element <description> may include text that expands on the meaning of
 error responses.  Response codes are defined in section 11 (Response
 Codes).
 Attributes:
    response: a numeric code indicating the overall success or failure
    of the transaction, and in the case of failure, an indication of
    the reason.  Mandatory.
    mark: in the case of an error, the value of the mark attribute
    from the last successfully executed element that included the mark
    attribute.
 In the case of failure, a description of the reason SHOULD be
 provided using the child element <description>.
 Three other child elements allow the response to include identifiers
 for objects created by the request but that did not have instance
 names specified by the client.  Those elements are <confid> and
 <dialogid>, for objects created through a <createconference> and
 <dialogstart> respectively.

7.4. <event>

 The <event> element is used to notify an event to a media server
 client.  Three types of events are defined by the MSML Core Package:
 "msml.dialog.exit", "msml.conf.nomedia", and "msml.conf.asn".  These
 correspond to the termination of an executing dialog, a conference
 being automatically deleted when the last participant has left, and
 the notification of the current set of active speakers for a
 conference, respectively.  Events may also be generated by an
 executing dialog.  In this case, the event type is specified by the
 dialog (see MSML Dialog Core Package <send>).

Saleem, et al. Informational [Page 27] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    name: the type of event.  If the event is generated because of the
    execution MSML dialog <send>, the value MUST be the value of the
    "event" attribute from the <send> element within the MSML Dialog
    Core Package.  If the event is generated because of the execution
    of an <exit>, the value MUST be "moml.exit".  If the event is
    generated because of the execution of a <disconnect>, the value
    MUST be "moml.disconnect".  If the event is generated because of
    an error, the value must be "moml.error".  Mandatory.
    id: the identifier of the conference or dialog that generated the
    event or caused the event to be generated.  Mandatory.
    <event> has two children, <name> and <value>, which contain the
    name and value respectively of each namelist item associated with
    the event.

8. MSML Conference Core Package

8.1. Conferences

 A conference has a mixer for each type of media that the conference
 supports.  Each mix has a corresponding description that defines how
 the media from participants contributes to that mix.  A mixer has
 multiple inputs that are combined in a media specific way to create a
 single logical output.
 The elements that describe the mix for each media type are called
 mixer description elements.  They are:
 <audiomix> defines the parameters for mixing audio media.
 <videolayout> defines the composition of a video window.
 These elements, defined in sections 8.6 (Audio Mix) and 8.7 (Video
 Layout) respectively, are used as content of the <createconference>
 element to establish the initial properties of a conference.  The
 elements are used within the <modifyconference> element to change the
 properties of a conference once it has been created, or within the
 <destroyconference> element to remove individual mixes from the
 conference.
 Conferences may be terminated by an MSML client using the
 <destroyconference> element to remove the entire conference or by
 removing the last mixer(s) associated with the conference.
 Conferences can also be terminated automatically by a media server
 based on criteria specified when the conference is created.  When the

Saleem, et al. Informational [Page 28] RFC 5707 Media Server Markup Language February 2010

 conference is deleted, any remaining participants will have their
 associated SIP dialogs left unchanged or deleted based on the value
 of the "term" attribute specified when the conference was created.

8.2. Media Streams

 Objects have at least one media input and output for each type of
 media that they support.  Each object class defines the number of
 input and output objects of that class support.  Media streams are
 created when objects are joined, either explicitly using <join> or
 implicitly when dialogs are created using <dialogstart>.  Dialog
 creation has two stages, allocating and configuring the resources
 required for the dialog instance, and implicitly joining those
 resources to the dialog target during the dialog execution.  Refer to
 the MSML Dialog Base Package.
 A join operation by default creates a bidirectional audio stream
 between two objects.  Video and unidirectional streams may also be
 created.  A media stream is created by connecting the output from one
 object to the input of another object and vice versa (assuming a
 bidirectional or full-duplex join).
 Many objects may only support a single input for each type of media.
 Within this specification, only the conference object class supports
 an arbitrary number of inputs.  When a stream is requested to be
 created to an object that already has a stream of the same type
 connected to its single input, the result of the request depends upon
 the type of the media stream.
 Audio mixing is done by summing audio signals.  Automatically mixing
 audio streams has common and straightforward applications.  For
 example, the ability to bridge two streams allows for the easy
 creation of simple three-way calls or to bridge private announcements
 with a (whispered) conference mix for an individual participant.  In
 the case of general conferences, however, an MSML client SHOULD
 create an audio conference and then join participants to the
 conference.  Conference mixers SHOULD subtract the audio of each
 participant from the mix so that they do not hear themselves.
 A media server receiving a request that requires joining an audio
 stream to the single audio input of an object that already has an
 audio stream connected SHOULD automatically bridge the new stream
 with the existing stream, creating a mix of the two audio streams.
 The maximum number of streams that may be bridged in this manner is
 implementation specific.  It is RECOMMENDED that a media server
 support bridging at least two streams.  A media server that cannot
 bridge a new stream with any existing streams MUST fail the operation
 requesting the join.

Saleem, et al. Informational [Page 29] RFC 5707 Media Server Markup Language February 2010

 Unlike audio mixing, there are many different ways that two video
 streams may be combined and presented.  For example, they may be
 presented side by side in separate panes, picture in picture, or in a
 single pane that displays only a single stream at a time based on a
 heuristic such as active speaker.  Each of these options creates a
 very different presentation and requires significantly different
 media resources.
 A join operation does not describe how a new stream can be combined
 with an existing stream.  Therefore, automatic bridging of video is
 not supported.  A media server MUST fail requests to join a new video
 stream to an object that only supports a single video input and
 already has a video stream connected to that input.  For an object to
 have multiple video streams joined to it, the object itself must be
 capable in supporting multiple video streams.  Conference objects can
 support multiple video streams and provide a way to specify the
 mixing presentation for the video streams.
 A media server MUST NOT establish any streams unless the media server
 is able to create all the streams requested by an operation.  Streams
 are only able to be created if both objects support a media type and
 at least one of the following conditions is true:
    1. Each object that is to receive media is not already receiving a
       stream of that type.
    2. Any object that is to receive media and is already receiving a
       stream of that type supports receiving an additional stream of
       that type.  The only class of objects defined in this
       specification that directly support receiving multiple streams
       of the same type are conferences.
    3. The media server is able to automatically bridge media streams
       for an object that is to receive media and that is already
       receiving a stream of the requested type.  The only type of
       media defined in this specification that MAY be automatically
       bridged is audio.
 The directionality of media streams associated with a connection is
 modeled independently from what SDP [n9] allows for the corresponding
 RTP [i3] sessions.  Media servers MUST respect the SDP in what they
 actually transmit but MUST NOT allow the SDP to affect the
 directionality when joining streams internal to the media server.

Saleem, et al. Informational [Page 30] RFC 5707 Media Server Markup Language February 2010

8.3. <createconference>

 <createconference> is used to allocate and configure the media mixing
 resources for conferences.  A description of the properties for each
 type of media mix required for the conference is defined within the
 content of the <createconference> element.  Mixer descriptions are
 described in Audio Mix and Video Layout sections.  When no mixer
 descriptions are specified, the default behavior MUST be equivalent
 to inclusion of a single <audiomix>.
 Clients can request that a media server automatically delete a
 conference when a specified condition occurs by using the
 "deletewhen" attribute.  A value of "nomedia" indicates that the
 conference MUST be deleted when no participants remain in the
 conference.  When this occurs, an "msml.conf.nomedia" event MUST be
 notified to the MSML client.  A value of "nocontrol" indicates that
 the conference MUST be deleted when the SIP [n1] dialog that carries
 the <createconference> element is terminated.  When this occurs, a
 media server MUST terminate all participant dialogs by sending a BYE
 for their associated SIP dialog.  A value of "never" MUST leave the
 ability to delete a conference under the control of the MSML client.
 Attributes:
    name: the instance name of the conference.  If the attribute is
    not present, the media server MUST assign a globally unique name
    for the conference.  If the attribute is present but the name is
    already in use, an error (432) will result and MSML document
    execution MUST stop.  Events that the conference generates use
    this name as the value of their "id" attribute (see section 7.4
    (<event>)).
    deletewhen: defines whether a media server should automatically
    delete the conference.  Possible values are "nomedia",
    "nocontrol", and "never".  Default is "nomedia".
    term: when true, the media server MUST send a BYE request on all
    SIP dialogs still associated with the conference when the
    conference is deleted.  Setting term equal to false allows clients
    to start dialogs on connections once the conference has completed.
    Default is "true".
    mark: a token that MAY be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all mark attributes within an
    MSML document should be unique.

Saleem, et al. Informational [Page 31] RFC 5707 Media Server Markup Language February 2010

 An example of creating an audio conference is shown below.  This
 conference allows at most two participants to contend to be heard and
 reports the set of active speakers no more frequently than every 10
 seconds.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <createconference name="example">
          <audiomix>
             <n-loudest n="3"/>
             <asn ri="10s"/>
          </audiomix>
       </createconference>
    </msml>

8.3.1. <reserve>

 Conference resources may be reserved by including the <reserve>
 element as a child of <createconference>.  <reserve> allows the
 specification of a set of resources that a media server will reserve
 for the conference.  Any requests for resources beyond those that
 have been reserved should be honored on a best-effort basis by a
 media server.
 Attributes:
    required: boolean that specifies whether <createconference> should
    fail if the requested resources are not available.  When set to
    false, the conference will be created, with no reserved resources,
    if the complete reservation cannot be honored.  Default is "true".

8.3.1.1. <resource>

 The resources to be reserved are defined using <resource>.  The
 contents of these elements describe a resource that is to be
 reserved.  Descriptions are implementation dependent.  Media servers
 that support MSML dialogs may use the elements from that package as
 the basis for resource descriptions.  Each resource element may use
 the attribute "n" to define the quantity of the resource to reserve.
 For example, the following creates a conference and reserves two
 types of resources.  One resource element may represent resources
 that are shared by all participants of the conference, while the
 other may represent resources that are reserved for each of the
 expected participants.

Saleem, et al. Informational [Page 32] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    n: number of resources to be reserved.  Default is 1.
    type: specifies whether the resource is to be reserved by each
    individual participant or reserved as a shared conference
    resource.  Valid values for this attribute are "individual" or
    "shared".  Default is "individual".
    <createconference>
       <reserve>
          <resource n="20">
            <!--description of resources used by each participant-->
          </resource>
          <resource n="2" type="shared">
            <!--description of the shared conference resources-->
          </resource>
       </reserve>
    </createconference>

8.4. <modifyconference>

 All of the properties of an audio mix or the presentation of a video
 mix may be changed during the life of a conference using the
 <modifyconference> element.  Changes to an audio mix are requested by
 including an <audiomix> element as a child of <modifyconference>.
 This may also be used to add an audio mixer to the conference if none
 was previously allocated.  Changes to a video presentation are
 requested by including a <videolayout> element as a child of
 <modifyconference>.  Similar to an audio mixer, this may be used to
 add a video mixer if none was previously allocated.
 Mixers are removed by including a mixer description element within
 <destroyconference/>.
 Features and presentation aspects are enabled/added or modified by
 including the element(s) that define the feature or presentation
 aspect within a mixer description.  The complete specification of the
 element must be included just as it would be included when the
 conference is created.  The new definition completely replaces any
 previous definition that existed.  Only things that are defined by
 elements included in the mixer descriptions are affected.  Any
 existing configuration aspects of a conference, which are not
 specified within the <modifyconference/> element, MUST maintain their
 current state in the media server.

Saleem, et al. Informational [Page 33] RFC 5707 Media Server Markup Language February 2010

 For example, if an MSML client wanted to change the minimum reporting
 interval for active speaker notification from that shown in the
 Conference Examples section (<createconference>) it would send the
 following to the media server:
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <modifyconference id="conf:example">
          <audiomix>
             <asn ri="4"/>
          </audiomix>
       </modifyconference>
    </msml>
 This would also enable active speaker notification if it had not
 previously been enabled.  The N-loudest mixing is unaffected.
 Multiple elements MAY be included in the mixer descriptions similar
 to when conferences are created.  For example, in a video conference,
 the video mix description (<videolayout>) could specify that the
 layout of the video being displayed should change such that the
 regions currently displaying participants get smaller and new
 region(s) are created to support additional participants.  A media
 server MUST make all of the requested changes or none of the
 requested changes.
 Additional examples of modifying conferences are presented in the
 Conference Examples section.
 Attributes:
    id: the identifier for a conference.  Wildcards MUST NOT be used.
    Mandatory.
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all "mark" attributes within an
    MSML document SHOULD be unique.

8.5. <destroyconference>

 Destroy conference is used to delete mixers or to delete the entire
 conference and all state and shared resources.  When a mixer is
 removed, all of the streams joined to that mixer are unjoined.  When
 a conference is destroyed, SIP dialogs for any remaining participants
 MUST be maintained or removed based on the value of the "term"
 attribute when the conference was created.

Saleem, et al. Informational [Page 34] RFC 5707 Media Server Markup Language February 2010

 When there is no element content, <destroyconference/> deletes the
 entire conference.  Individual mixers are removed by including a
 mixer description element identifying the mix (or mixes) to be
 removed as content to <destroyconference/>.  <audiomix/> is used
 remove audio mixers and <videolayout/> is used remove video mixers.
 When one or more mixer descriptions are specified, then media server
 MUST only delete the specified mixer and MUST NOT affect any other
 existing mixers.  When <audiomix/> or <videolayout/> is identified
 for individual removal, other feature aspects of the mix MUST NOT be
 included.  If specified, the media server MUST ignore any such
 elements.  When the last mixer is removed from a conference, a media
 server MUST remove all conference state, leaving or removing any
 remaining SIP dialogs as described above.
 Attributes:
    id: the identifier for a conference.  Mandatory.
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all "mark" attributes within an
    MSML document SHOULD be unique.

8.6. <audiomix>

 The properties of the overall audio mix are specified using the
 <audiomix> element.
 Attributes:
    id: an optional identifier for the audio mix.
    samplerate: Integer value specifies the sample rate (in Hz) for
    the audio mixer.  Optional, default value of 8000.
 An example of the description for an audio mix is:
    <audiomix id="mix1">
      <asn ri="10s"/>
      <n-loudest n="3"/>
    </audiomix>

8.6.1. <n-loudest>

 The <n-loudest> element defines that participants contend to be
 included in the conference mix based upon their audio energy.  When
 the element is not present, all participants are mixed.

Saleem, et al. Informational [Page 35] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    n: the number of participants that will be included in the audio
    mix based upon having the greatest audio energy.  Mandatory.

8.6.2. <asn>

 The <asn> element enables notification of active speakers.  Active
 speakers MUST be notified using the <event> element with an event
 name of "msml.conf.asn".  The namelist of the event consists of the
 set of active speakers.  The name of each item is the string
 "speaker" with a value of the connection identifier for the
 connection.
 Attributes:
    ri: the minimum reporting interval defines the minimum duration of
    time that must pass before changes to active speakers will be
    reported.  A value of zero disables active speaker notification.
    asth: specifies the active speaker threshold (in unit of dBm0).
    Valid value range is 0 to -96.  Optional, default is -96.
 An example of an active speaker notification is:
    <event name="msml.conf.asn" id="conf:example">
       <name>speaker</name>
       <value>conn:hd93tg5hdf</value>
       <name>speaker</name>
       <value>conn:w8cn59vei7</value>
       <name>speaker</name>
       <value>conn:p78fnh6sek47fg</value> </event>

8.7. <videolayout>

 A video layout is specified using the <videolayout> element.  It is
 used as a container to hold elements that describe all of the
 properties of a video mix.  The parameters of the window that
 displays the video mix are defined by the <root> element.  When the
 video mix in composed of multiple panes, the location and
 characteristics of the panes are defined by one or more <region>
 elements.  A <region> element is not required when only a single
 video stream is displayed at one time and none of the visual
 attributes of regions are required.
 Some regions may be used to display a video stream based on a
 selection criteria rather than having a video stream of a single
 participant continuously presented in the region.  One such an

Saleem, et al. Informational [Page 36] RFC 5707 Media Server Markup Language February 2010

 example is a distance learning lecture where the instructor sees each
 of the students periodically displayed in a region.  When a region is
 used to display one of a number of streams, it is placed as a child
 of a <selector> element.
 Attributes:
    type: specifies the language used to define the layout.  Layouts
    defined using MSML MUST use the value "text/msml-basic-layout".
    This is the same convention as defined for the layout package from
    the W3C SMIL 2.0 specification [i6].  The default when omitted is
    "text/msml-basic-layout".
    id: an optional identifier for the video layout.

8.7.1. <root>

 The <root> element describes the root window or virtual screen in
 which the conference video mix will be displayed.  Simple conferences
 can display participant video directly within the root window but
 more complex conferences will use regions for this purpose.  Areas of
 the window which are not used to display video will show the root
 window background.
 All video presentations require a root window.  It MUST be present
 when a video mix is created and it cannot be deleted; however, its
 attributes MAY be changed using the <modifyconference> element.
 Attributes:
    size: the size of the root window specified as one of the five
    standard common intermediate formats (e.g., CIF, QCIF).
    backgroundcolor: the color for the root window background defined
    using the values for the "background-color" property of the CSS2
    specification [n10].
    backgroundimage: the URI for an image to be displayed as the root
    window background.  Transparent portions of the image allow the
    background color to show through.

8.7.2. <region>

 <region> elements define video panes that are used to display
 participant video streams.  Regions are rendered on top of the root
 window.

Saleem, et al. Informational [Page 37] RFC 5707 Media Server Markup Language February 2010

 The size of a region is specified relative to the size of the root
 window using the "relativesize" attribute.  Relative sizes are
 expressed as fractions (e.g., 1/4, 1/3) that preserve the aspect
 ratio of the original video stream while allowing for efficient
 scaling implementations.
 Regions are located on the root window based on the value of the
 position attributes "top" and "left".  These attributes define the
 position of the top left corner of the region as an offset from the
 top left corner of the root window.  Their values may be expressed
 either as a number of pixels or as a percent of the vertical or
 horizontal dimension of the root window.  Percent values are appended
 with a percent ('%') character.  Percent values of "33%" and "67%"
 should be interpreted as "1/3" and "2/3" to allow easy alignment of
 regions whose size is expressed relative to the size of the root
 window.
 An example of a video layout with six regions is:
    +-------+---+
    |       | 2 |
    |   1   +---+
    |       | 3 |
    +---+---+---+
    | 6 | 5 | 4 |
    +---+---+---+
    <videolayout type="text/msml-basic-layout">
       <root size="CIF"/>
       <region id="1" left="0" top="0" relativesize="2/3"/>
       <region id="2" left="67%" top="0" relativesize="1/3"/>
       <region id="3" left="67%" top="33%" relativesize="1/3">
       <region id="4" left="67%" top="67%" relativesize="1/3"/>
       <region id="5" left="33%" top="67%" relativesize="1/3"/>
       <region id="6" left="0" top="67%" relativesize="1/3"/>
    </videolayout>
 The area of the root window covered by a region is a function of the
 region's position and its size.  When areas of different regions
 overlap, they are layered in order of their "priority" attribute.
 The region with the highest value for the "priority" attribute is
 below all other regions and will be hidden by overlapping regions.
 The region with the lowest non-zero value for the "priority"
 attribute is on top of all other regions and will not be hidden by
 overlapping regions.  The priority attribute may be assigned values
 between 0 and 1.  A value of zero disables the region, freeing any
 resources associated with the region, and unjoining any video stream
 displayed in the region.

Saleem, et al. Informational [Page 38] RFC 5707 Media Server Markup Language February 2010

 Regions that do not specify a priority will be assigned a priority by
 a media server when a conference is created.  The first region within
 the <videolayout> element that does not specify a priority will be
 assigned a priority of one, the second a priority of two, etc.  In
 this way, all regions that do not explicitly specify a priority will
 be underneath all regions that do specify a priority.  As well,
 within those regions that do not specify a priority, they will be
 layered from top to bottom, in the order they appear within the
 <videolayout> element.
 For example, if a layout was specified as follows:
    <videolayout>
       <root size="CIF"/>
       <region id="a" ... priority=".3" .../>
       <region id="b" ... />
       <region id="c" ... priority=".2" ...>
       <region id="d" ... />
    </videolayout>
 Then the regions would be layered, from top to bottom, c,a,b,d.
 Portions of regions that extend beyond the root window will be
 cropped.  For example, a layout specified as:
    <videolayout>
       <root size="CIF"/>
       <region id="foo" left="50%" top="50%" relativesize="2/3"/>
    </videolayout>
 would appear similar to:
    +-----------+
    |   root    |
    |background |
    |     +-----+--
    |     |     |//
    |     | foo |//
    +-----+-----+//
          |////////
 Visual attributes are used to define aspects of the visual appearance
 of individual regions.  A border may be defined together with a title
 and/or logo.  Text and logos are displayed as images on top of the
 region's video, below all regions with a lower priority.  The visual
 attributes are "title", "titletextcolor", "titlebackgroundcolor",
 "bordercolor", "borderwidth", and "logo".

Saleem, et al. Informational [Page 39] RFC 5707 Media Server Markup Language February 2010

 Visual attributes can also be defined for individual streams (Video
 Stream Properties).  When visual attributes are specified as part of
 both a region and a stream, those associated with the stream MUST
 take precedence.  This allows streams that are chosen for display
 automatically (Stream Selection) to have proper text and logos
 displayed.  The region visual attributes are displayed when no stream
 is associated with the region.
 Two other attributes associated with a region, "blank" and "freeze",
 define the state of the video displayed in the region.  When the
 blank or freeze attribute is assigned the value "true", then the
 media server MUST display the region either as a blank region, or the
 video image frozen at the last received frame.
 These attributes are specified for a region and not allowed for
 streams because that appears to be the common use case.  Applying
 them to streams would allow only that stream to be affected within a
 selector while other streams continue to display normally.  Except
 for personal mixing scenarios, the same effect can be achieved by
 having the participant mute their own transmission to the media
 server.
 Attributes: associated with each region:
    id: a name that can be used to refer to the region.
    left: the position of the region from the left side of the root
    window.
    top: the position of the region from the top of the root window.
    relativesize: the size of the region expressed as a fraction of
    the root window size.
    priority: a number between 0 and 1 that is used to define the
    precedence when rendering overlapping regions.  A value of zero
    disables the region.
    title: text to be displayed as the title for the region
    titletextcolor: the color of the text
    titlebackgroundcolor: the color of the text background
    bordercolor: the color of the region border
    borderwidth: the width of the region border

Saleem, et al. Informational [Page 40] RFC 5707 Media Server Markup Language February 2010

    logo: the URI of an image file to be displayed
    freeze: a boolean value, with a default of "false", that defines
    whether the video image should be frozen at the currently
    displayed frame
    blank: a boolean value, with a default of "false", that defines
    whether the region should display black instead of the associated
    video stream

8.7.3. <selector>

 It is often desired that one of several video streams be
 automatically selected to be displayed.  The <selector> element is
 used to define the selection criteria and its associated parameters.
 The selection algorithm is specified by the "method" attribute.
 Currently defined selection methods allow for voice activated
 switching and to iterate sequentially through the set of associated
 video streams.
 The regions that will display the selected video stream are placed as
 child elements of the <selector> element.  Including regions within a
 <selector> element does not affect their layout with respect to
 regions not subject to the selection.  For simple video conferences
 that display the video directly in the root window, the <root>
 element can be placed as a child of <selector>.  Region elements MUST
 NOT be used in this case.
 For example, below is a common video layout that allows the video
 stream from the currently active speaker to be displayed in the large
 region ("1") at the top left of the layout while the streams from
 five other participants are displayed in regions located at the
 layout periphery.
    +-------+---+
    |       | 2 |
    |   1   +---+
    |       | 3 |
    +---+---+---+
    | 6 | 5 | 4 |
    +---+---+---+

Saleem, et al. Informational [Page 41] RFC 5707 Media Server Markup Language February 2010

    <videolayout type="text/msml-basic-layout">
       <root size="CIF"/>
       <selector id="switch" method="vas">
          <region id="1" left="0" top="0" relativesize="2/3"/>
       </selector>
       <region id="2" left="67%" top="0" relativesize="1/3"/>
       <region id="3" left="67%" top="33%" relativesize="1/3">
       <region id="4" left="67%" top="67%" relativesize="1/3"/>
       <region id="5" left="33%" top="67%" relativesize="1/3"/>
       <region id="6" left="0" top="67%" relativesize="1/3"/>
    </videolayout>
 All selector methods must be defined so that they work if only a
 single region is a child of the selector.  Selector methods that
 support more than one child region MUST specify how the method works
 across multiple regions.  Media server implementations MAY support
 only a single region for methods that are defined to allow multiple
 regions.
 The selector or region for a participant's video is defined using the
 "display" attribute of <stream> during a join operation.  Specifying
 a selector allows the stream to be displayed according to the
 criteria defined by the selector method.  Specifying a region
 supports continuous presence display of participants.  Some streams
 may be joined with both a selector and a region.  In this case, the
 value of <blankothers> attribute defines whether the streams
 associated with a continuous presence region should be blanked when
 the stream is selected for display in one of the selector regions.
 Attributes: common to all selector methods are:
    id: a name that can be used to refer to the selector.
    method: the name of the method used to select the video stream.  A
    value of "vas" (see the following section, Voice Activated
    Switching) MAY be specified.
    status: specifies whether the selector is "active" or "disabled".
    blankothers: when "true", video streams that are also displayed in
    continuous presence regions will have the continuous presence
    regions blanked when the stream is displayed in a selection
    region.

Saleem, et al. Informational [Page 42] RFC 5707 Media Server Markup Language February 2010

8.7.3.1. Voice Activated Switching ("vas")

 Voice activated switching (VAS) is used to display the video stream
 that correlates with the participant who is currently speaking.  It
 is specified using a selector method value of "vas".
 If the video stream associated with the active speaker is not
 currently displayed in a selection region, then it replaces the video
 in the region that is displaying the video of the speaker that was
 least recently active.  If the video of the active speaker is
 currently displayed in a selection region, then there is no change to
 any region.  When VAS is applied to a single region, this has the
 effect that the current speaker is displayed in that region.
 Attributes:
    si: switching interval is the minimum period of time that must
    elapse before allowing the video to switch to the active speaker.
    speakersees: defines whether the active speaker sees the "current"
    speaker (themselves) or the "previous" speaker.

8.8. <join>

 <join> is used to create one or more streams between two independent
 objects.  Streams may be audio or video and may be bidirectional or
 unidirectional.  A bidirectional stream is implicitly composed of two
 unidirectional streams that can be manipulated independently.  The
 streams to be established are specified by <stream> elements (section
 <stream>) as the content of <join>.
 Without any content, <join> by default establishes a bidirectional
 audio stream.  When only a stream of a single type has previously
 been created between two objects, or when only a unidirectional
 stream exists, <join> can be used to add a stream of another media
 type or make the stream bidirectional by including the necessary
 <stream> elements.  Bidirectional streams are made unidirectional by
 using <unjoin> (section <unjoin>) to remove the unidirectional stream
 for the direction that is no longer required.
 In addition to defining the media type and direction of streams,
 <stream> elements are also used to establish the properties of
 streams, such as gain, voice masking, or tone clamping of audio
 streams, or labels and other visual characteristics of video streams.
 Properties are often defined asymmetrically for a single direction of
 a stream.  Creating a bidirectional stream requires two <stream>
 elements within the <join>, one for each direction, if one direction
 is to have different properties from the other direction.

Saleem, et al. Informational [Page 43] RFC 5707 Media Server Markup Language February 2010

 If a media server can provide services using both compressed or
 uncompressed media, the MSML client may need to distinguish within
 requests which format is to be used.  When compressed streams are
 created, both objects must use the same media format or an error
 response (450) is generated.
 Attributes:
    id1: an identifier of either a connection or conference.
    Wildcards MUST NOT be used.  Mandatory.  Any other object class
    results in a 440 error.
    id2: an identifier of either a connection or conference.
    Wildcards MUST NOT be used.  Mandatory.  Any other object class
    results in a 440 error.
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all mark attributes within an
    MSML document SHOULD be unique.
 For example, consider a call center coaching scenario where a
 supervisor can listen to the conversation between an agent and a
 customer and provide hints to the agent, which are not heard by the
 customer.  One join establishes a stream between the agent and the
 customer and another join establishes a stream between the agent and
 the supervisor.  A third join is used to establish a half-duplex
 stream from the customer to the supervisor.  The media server
 automatically bridges the media streams from the customer and the
 supervisor for the agent, and from the customer and the agent for the
 supervisor.
 Assuming the following connections, each with a single audio stream:
    conn:supervisor
    conn:agent
    conn:customer

Saleem, et al. Informational [Page 44] RFC 5707 Media Server Markup Language February 2010

 The following would create the media flows previously described:
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <join id1="conn:supervisor" id2="conn:agent"/>
       <join id1="conn:agent" id2="conn:customer"/>
       <join id1="conn:supervisor" id2="conn:customer">
          <stream media="audio" dir="to-id1"/>
       </join>
    </msml>
    The following example shows joining a participant to a multimedia
    conference.  It assumes that the conference has a video
    presentation region named "topright".  The "display" attribute is
    explained in the section Video Stream Properties.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <join id1="conn:hd83t5hf7g3" id2="conf:example">
          <stream media="audio"/>
          <stream media="video" dir="from-id1" display="topright"/>
          <stream media="video" dir="to-id1"/>
       </join>
    </msml>

8.9. <modifystream>

 Media streams can have different properties such as the gain for an
 audio stream or a visual label for a video stream.  These properties
 are specified as the content of <stream> elements (section <stream>).
 <modifystream> is used to change the properties of a stream by
 including one or more <stream> elements that are to have their
 properties changed.
 Stream properties MUST be set as specified by the element <stream> as
 a child element of <modifystream> element.  Any properties not
 included in the <stream> element when modifying a stream MUST remain
 unchanged.  Setting a property for only one direction of a
 bidirectional stream MUST NOT affect the other direction.  The
 directionality of streams can be changed by issuing an <unjoin>
 followed by a <join>.  Any streams that exist between the two objects
 that are not included within <modifystream> MUST NOT be affected.
 Attributes:
    id1: an identifier of either a conference or a connection.  The
    instance name MUST NOT contain a wildcard if "id2" contains a
    wildcard.  Mandatory.

Saleem, et al. Informational [Page 45] RFC 5707 Media Server Markup Language February 2010

    id2: an identifier of either a conference or a connection.  The
    instance name MUST NOT contain a wildcard if "id1" contains a
    wildcard.  Mandatory.
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all mark attributes within an
    MSML document is RECOMMENDED to be unique.

8.10. <unjoin>

 Unjoin removes one or more media streams between two objects.  In the
 absence of any content in the <stream> element, all media streams
 between the objects MUST be removed.  Individual streams may be
 removed by specifying them using <stream> elements, while the
 unspecified streams MUST NOT be removed.  A bidirectional stream is
 changed to a unidirectional stream by unjoining the direction that is
 no longer required, using the <unjoin> element.  Operator elements
 MUST NOT be specified within <stream> elements when streams are being
 unjoined using the <unjoin> element.  Any specified stream operators
 MUST be ignored.
 <unjoin> and <join> may be used together to move a media stream, such
 as from a main conference to a sidebar conference.
 Attributes:
    id1: an identifier of either a conference or a connection.  The
    instance name MUST NOT contain a wildcard if "id2" contains a
    wildcard.  Mandatory.
    id2: an identifier of either a conference or a connection.  The
    instance name MUST NOT contain a wildcard if "id1" contains a
    wildcard.  Mandatory.
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all mark attributes within an
    MSML document SHOULD be unique.
 The following removes a participant from a conference and plays a
 leave tone for the remaining participants in the conference.

Saleem, et al. Informational [Page 46] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <unjoin id1="conn:jd73ht89sf489f" id2="conf:1"/>
       <dialogstart target="conf:1" type="application/moml+xml">
          <play>
             <audio uri="file://leave_tone.wav"/>
          </play>
       </dialogstart>
    </msml>

8.11. <monitor>

 Monitor is a specialized unidirectional join that copies the media
 that is destined for a connection object.  One example of the use for
 <monitor> may be quality monitoring within a conference.  The media
 stream may be removed using the <unjoin> element (see the section
 <unjoin>).
 Attributes:
    id1: an identifier of the connection to be monitored.  Mandatory.
    Any other object class results in a 440 error.  Wildcards MUST NOT
    be used.
    id2: an identifier of the object that is to receive the copy of
    the media destined to id1.  id2 may be a connection or a
    conference.  Mandatory.  Any other object class results in a 440
    error.  Wildcards MUST NOT be used.
    compressed: "true" or "false".  Specifies whether the join should
    occur before or after compression.  When "true", id2 must be a
    connection using the same media format as id1 or an error response
    (450) is generated.  Default is "false".
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all mark attributes within an
    MSML document SHOULD be unique.

8.12. <stream>

 Individual streams are specified using the <stream> element.  They
 MAY be included as a child element in any of the stream manipulation
 elements <join>, <modifystream>, or <unjoin>.

Saleem, et al. Informational [Page 47] RFC 5707 Media Server Markup Language February 2010

 The type of the stream is specified using a "media" attribute that
 uses values corresponding to the top-level MIME media types as
 defined in RFC 2046 [i7].  This specification only addresses audio
 and video media.  Other specifications may define procedures for
 additional types.
 A bidirectional stream is identified when no direction attribute
 "dir" is present.  A unidirectional stream is identified when a
 direction attribute is present.  The "dir" attribute MUST have a
 value of "from-id1" or "to-id1" depending on the required direction.
 These values are relative to the identifier attributes of the parent
 element.
 The compressed attribute is used to distinguish the compressed nature
 of the stream when necessary.  It is implementation specific what is
 used when the attribute is not present.  Joining compressed streams
 acts much like an RTP [i3] relay.
 The properties of the media streams are specified as the content of
 <stream> elements when the element is used as a child of <join> or
 <modifystream>.  Stream elements MUST NOT have any content when they
 are used as a child of <unjoin> to identify specific streams to
 remove.
 Some properties are defined within MSML as additional attributes or
 child elements of <stream> that are media type specific.  Ones for
 audio streams and video streams are defined in the following two sub-
 sections.  Operators, viewed as properties of the media stream, MAY
 be specified as child elements of the <stream> element.
 Attributes:
    media: "audio" or video".  Mandatory
    dir: "from-id1" or "to-id1".
    compressed: "true" or "false".  Specifies whether the stream uses
    compressed media.  Default is implementation specific.

8.12.1. Audio Stream Properties

 Audio mixes can be specified to only mix the N-loudest participants.
 However, there may be some "preferred" participants that are always
 able to contribute.  When audio streams are joined to a conference
 that uses N-loudest audio mixing, preferred streams need to be
 identified.

Saleem, et al. Informational [Page 48] RFC 5707 Media Server Markup Language February 2010

 A preferred audio stream is identified using the "preferred"
 attribute.  The "preferred" attribute MAY be used for an audio stream
 that is input to a conference and MUST NOT be used for other streams.
 Additional attributes of the <stream> element for audio streams are:
 Attributes:
    preferred: a boolean value that defines whether the stream does
    not contend for N-loudest mixing.  A value of "true" means that
    the stream MUST always be mixed while a value of "false" means
    that the stream MAY contend for mixing into a conference when
    N-loudest mixing is enabled.  Default is "false".
 There are two elements that can be used to change the characteristics
 of an audio stream as defined below.

8.12.1.1. <gain>

 The <gain> element may be used to adjust the volume of an audio media
 stream.  It may be set to a specific gain amount, to automatically
 adjust the gain to a desired target level, or to mute the stream.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the gain primitive.
    amt: a specific gain to apply specified in dB or the string "mute"
    indicating that the stream should be muted.  This attribute MUST
    NOT be used if "agc" is present.
    agc: boolean indicating whether automatic gain control is to be
    used.  This attribute MUST NOT be used if "amt" is present.
    tgtlvl: the desired target level for AGC specified in dBm0.  This
    attribute MUST be specified if "agc" is set to "true".  This
    attribute MUST NOT be specified if "agc" is not present.
    maxgain: the maximum gain that AGC may apply.  Maxgain is
    specified in dB.  This attribute MUST be used if "agc" is present
    and MUST NOT be used when "agc" is not present.

8.12.1.2. <clamp>

 The <clamp> element is used to filter tones and/or audio-band dtmf
 from a media stream.

Saleem, et al. Informational [Page 49] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    dtmf: boolean indicating whether DTMF tones should be removed.
    tone: boolean indicating whether other tones should be removed.

8.12.2. Video Stream Properties

 Video mixes define a presentation that may have multiple regions,
 such as a quad-split.  Each region displays the video from one or
 more participants.  When video streams are joined to such a
 conference, the region that will display the video needs to be
 specified as part of the join operation.
 The region that will display the video is specified using the
 "display" attribute.  The "display" attribute MUST be used for a
 video stream that is input to a conference and MUST NOT be used for
 other streams.  The value of the attribute MUST identify a <region>
 (see the section <region>) or a <selector> (see the section
 <selector>) that is defined for the conference.  A stream MUST NOT be
 directly joined to a region that is defined within a selector.
 Changing the value of the "display" attribute can be used to change
 where in a video presentation layout a video stream is displayed.
 Additional attributes of the <stream> element for video streams are:
 Attributes:
    display: the identifier of a video layout region or selector that
    is to be used to display the video stream.
    override: specifies whether or not the given video stream is the
    override source in the region defined by "display" attribute.
    Valid values are "true" or "false".  Optional, default value is
    "false".  Only a video stream that is input to a conference can be
    the override source.  A particular region can have at most one
    override source at a time.  The most recently joined video stream
    with this attribute set to "true" becomes the override source.
    When there's an override source in place, its video is always
    displayed in the region, regardless of what video selection
    algorithm (either a selector or continuous presence mode) is
    configured for that region.  Once the override source is cleared,
    the conference MUST revert back to original video selection
    algorithm.

Saleem, et al. Informational [Page 50] RFC 5707 Media Server Markup Language February 2010

8.12.2.1. <visual>

 Some regions of video conferences may display different streams
 automatically, such as when voice activated switching is used.
 Connections MAY also be joined directly without the use of video
 mixing.  In these cases, the <visual> element may be used to define
 visual display properties for a stream.
 The <visual> element MAY use any of the visual attributes defined for
 regions (see the section <region>).  This allows the visual aspects
 of regions within a <selector> to be tailored to the selected video
 stream, or for streams that are directly joined to display a name or
 logo.

9. MSML Dialog Packages

9.1. Overview

 MSML Dialog Packages define an XML [n2] language for composing
 complex media objects from a vocabulary of simple media resource
 objects called primitives.  It is primarily a descriptive or
 declarative language to describe media processing objects.  MSML
 dialogs operate on a single or multiple streams that are identified
 by the MSML document outside the scope of the MSML Dialog Package.
 MSML dialogs are intended to be used in different environments.  As
 such, the language itself does not define how an MSML dialog is used.
 Each environment in which an MSML dialog is used must define how it
 is used, the set of services provided, and the mechanism for passing
 information between the environment and MSML dialog.  The specific
 mechanisms used to realize the interface between MSML dialog and its
 environment are platform specific.
 MSML Dialog Packages provide two models for access to media resources
 and service creation building blocks.  Both models MAY be used in
 conjunction with each other in a complementary manner.  The first
 model (referred to as "Media Primitives and Composites", part of the
 mandatory MSML Dialog Base Package) contains media primitives (such
 as digit collection and announcements) and composite functions (such
 as play and collect combined as a single operation).  The second
 model (referred to as "Media Groups", part of the optional MSML
 Dialog Group Package) allows the ability to define complex customized
 interactions, via event passing mechanisms, between media primitives,
 if required.

Saleem, et al. Informational [Page 51] RFC 5707 Media Server Markup Language February 2010

    MSML Dialog Core Package
       Defines core framework over which all MSML Dialog Packages
       operate.
    MSML Dialog Base Package
       Media Primitives
          <dtmf> or <collect>
                      DTMF digit collection
          <play>
                      Playing of Announcements
          <dtmfgen>
                      Generation of DTMF digits
          <tonegen>
                      Tone genration
          <record>
                      Media recording
       Media Composites
          <collect>
                      Supports play and collect operation.
                      Composite function with inclusion of play.
          <record>
                      Supports play and record operation.
                      Composite function with inclusion of play.
    MSML Dialog Group Package
          <group>
                      Allows grouping of media primitives for parallel
                      execution, with an event exchange mechanism
                      between the media primitives to achieve
                      customized media operations. All the above media
                      primitive elements are accepted within the
                      group.
 The following operations MUST be supported using elements described
 above using either the MSML Dialog Base Package or MSML Dialog Group
 Package.
    Announcement only
                      <play>
          Collection only
                      <dtmf> or <collect>
          Recording only
                      <record>

Saleem, et al. Informational [Page 52] RFC 5707 Media Server Markup Language February 2010

          Play and Collect
                      <collect>
                         <play/>
                      </collect>
          Play and Record
                      <record>
                         <play/>
                      </record>
 Additional MSML Dialog Packages are:
    o MSML Dialog Transform Package
    o MSML Dialog Speech Package
    o MSML Fax Detection Package
    o MSML Fax Send/Receive Package
 MSML dialogs MAY be used to simply expose primitive media resource
 objects but will be used more often to describe dialog operations and
 media transformation objects that can be controlled via user
 interaction.
 MSML dialogs do not contain any computation or flow control
 constructs.  There are no results automatically generated when media
 operations complete.  Results MUST be explicitly requested using a
 <send> or <exit> element within the definition of the MSML dialog.

9.2. Primitives

 Primitives perform a single function on a media stream or multiple
 streams such as generating audio/video, recognizing speech or DTMF,
 or adjusting the gain.  They may be composed so that primitives
 execute concurrently.  Primitives not composed for concurrent
 execution MUST simply execute sequentially in the order they occur in
 an MSML document.  All concurrently executing primitives in the same
 MSML object (defined in one MSML document) MAY interact with each
 other through events (see MSML Dialog Group Package).
 Primitives are categorized into one of the following descriptive
 categories.
    o  Recognizers have a media input but no output.  They allow
       different things within a media stream to be recognized or
       detected and for events to be generated based upon received
       media.

Saleem, et al. Informational [Page 53] RFC 5707 Media Server Markup Language February 2010

    o  Transformers have one media input and output and may send and
       receive events.
    o  Sources and sinks generate or consume media.  They have either
       a media input or a media output but not both.  They may receive
       and generate events.
    o  Composites combine underlying primitives to provide higher-
       level user interaction, without the need for specific event-
       based exchange between the primitives.  The composite elements
       provide a simpler mechanism for more commonly used services,
       such as play and collect or play and record.
 Primitives may define different media processing behavior (states)
 based upon the events that they receive.  Primitives that support
 different processing states must define their default starting state
 and should support the "initial" attribute to allow that state to be
 specified when the primitive is instantiated.  All primitives must
 support the "terminate" event class.
 The following types of primitives are defined within this
 specification:
    Recognizers    Transformers   Source/Sink   Composites
    ------------------------------------------------------
     dtmf/collect   agc            play          dtmf/collect
     faxdetect      clamp          record        record
     speech         gain           dtmfgen
     vad            gate           tonegen
                    relay          faxsend
                                   faxrcv
 Primitives have shadow variables, similar to those within VoiceXML
 [n5], which are automatically assigned values when the primitives are
 used.  Upon initialization of an MSML dialog context, all shadow
 variables have the string value "undefined".  Each primitive has its
 own instance of shadow variables that are global in scope to the
 entire MSML dialog context.
 Names SHOULD be assigned to individual primitives when more than one
 primitive of the same type is used within one MSML document.  Shadow
 variables are overwritten if the primitive has not been named and is
 instantiated a second time.
 Shadow variables cannot be modified under user control.  They may be
 returned from the MSML dialog context using the <send> element.

Saleem, et al. Informational [Page 54] RFC 5707 Media Server Markup Language February 2010

9.3. Events

 Events provide the mechanism for primitives to interact with each
 other and for an MSML context to interact with its external
 environment.  The external environment is defined by the way in which
 an MSML context has been invoked.  This will often be through MSML,
 but other languages and protocols such as SIP may also be used.
 Every primitive and group conceptually implements their own event
 queue.  Events sent to them get placed into their associated queue.
 Events are removed from their queues and processed in order.
 Primitives within a group conceptually have their own thread of
 execution.  Due to the asynchronous nature of servicing events from
 multiple queues, it cannot be assumed that several events sent in
 sequence to different queues will be processed in the order in which
 they were sent.  For example, if recognition of something led to
 sending events to both a <play> and a <record> in that order, it is
 possible that the <record> may process its event before the <play>.
 Primitives each define the set of events that they support and the
 behavior associated with their handling of each event.  This allows
 many types of behaviors to be defined.  For example, VCR type
 controls can be constructed by defining primitives that support
 events corresponding to each control.  Media recognition/detection
 can be used to cause those events to be generated.
 Alternatively, events can be originated elsewhere, such as from a
 control agent, and simply received by the primitive implementing the
 control.  Examples of the use of events include adjusting volume
 (gain) and pause and resume of both announcement playout and record
 creation.
 Primitives act on events based upon the longest match of an event
 name.  Event names are a period '.' delimited sequence of tokens.
 The first token, or the root of the name, can be considered an event
 class.  Matching allows a standard meaning to be defined and then
 extended based upon what triggers an event's generation.  For
 example, a record primitive has different behavior depending upon
 whether it completed because a user stopped speaking or because it
 was cancelled.  The recording is retained in the first case but not
 the second.
 Longest match allows new recognizers to be created and used without
 changing how existing primitives are defined.  For example, a face
 recognition capability could be created that generates a
 terminate.frowning event when a user looks puzzled.  Although no
 primitive directly defines this event, it will still effect a generic
 terminate action.  Primitives that require specialized behavior based

Saleem, et al. Informational [Page 55] RFC 5707 Media Server Markup Language February 2010

 upon frowning may be extended to support this.  As well, the event
 can still be exported from the MSML context without requiring that
 primitives receiving the event understand facial expressions.

9.4. MSML Dialog Usage with SIP

 MSML dialogs MAY be used directly with SIP for dialog interactions
 (e.g., IVR or fax).  It can be initially invoked as part of the
 "Prompt and Collect" service described in "Basic Network Media
 Services with SIP" [n7].  That defines service indicators for a small
 number of well-defined services using the user part of the SIP
 Request-URI (R-URI).
 The prompt and collect service uses "dialog" as the service
 indicator.  URI parameters further refine the specific IVR request.
 This document defines an additional parameter "msml-param" for the
 dialog service indicator as follows:
 dialog-parameters = ";" ( dialog-param [ vxml-parameters ] )
                         | moml-param
 dialog-param      = "voicexml=" dialog-url
 moml-param        = "moml=" moml-url
 There are no additional URI parameters when MSML is used as the
 dialog language.
 MSML dialogs define discrete IVR dialog commands.  These commands MAY
 be included directly in the body of the INVITE to the "dialog"
 service indicator by using the "cid" [n8] URL scheme.  This scheme
 identifies a message body part that in this case would contain the
 MSML dialog request.  Note that a multipart message body, containing
 a single part, MUST be present even if the INVITE does not contain an
 SDP offer.  Subsequent MSML dialog requests are sent in the body of
 SIP INFO messages as are all messages from a media server.
 An example of SIP URI as described above is:
    sip:dialog@mediaserver.example.net;\
        moml=cid:14864099865376@appserver.example.net
 The body part that contained the MSML dialog referenced by the URL
 would have a Content-Id header of:
    Content-Id: <14864099865376@appserver.example.net>

Saleem, et al. Informational [Page 56] RFC 5707 Media Server Markup Language February 2010

 The results of executing an <exit> or <disconnect>, or of executing a
 <send> that has a "target" attribute value equal to "source", are
 notified in SIP INFO messages using the <event> element from MSML
 Core package.  No messages are sent if execution completes normally
 without executing one of these elements.
 If there is an error during validation or execution, then a media
 server MUST notify the error as described above and must include the
 namelist items "moml.error.status" and "moml.error.description".  The
 values for these items are defined in section 11.
 A restricted subset of MSML dialogs can also be used with the
 "Announcement" service defined in [n7].  This service uses "annc" as
 the service indicator and defines parameters that describe an
 announcement.  The "play=" parameter identifies the URL of a prompt
 or a provisioned announcement sequence.  The value of the "play="
 parameter can refer to an MSML dialog body part using a "cid" URL as
 described above.  That body part must only contain the <play>
 primitive.
 Using MSML dialogs enhances the announcement service by allowing the
 client to specify a sequence of audio segments rather than requiring
 each sequence to be provisioned as well as support for video.
 Moreover, MSML dialogs define a standard set of variables in contrast
 to [n7] which defines a parameterization mechanism but does not
 formally specify any semantics.
 If a media server does not understand the "cid" scheme or does not
 understand MSML dialogs, it must respond with the SIP response code
 "488 - not acceptable here".  If the MSML dialog body contains
 elements other than the <play> primitive, or there are errors during
 validation, a media server must respond with a SIP response code "400
 - bad request".  Finally, if there is a discrepancy between
 parameters specified in the Request-URI and corresponding attributes
 defined in the MSML dialog body, the Request-URI parameters must be
 silently ignored.
 MSML dialogs MUST NOT change the operation of the announcement
 service from that defined in [n7].  When the announcement completes,
 a media server issues a SIP BYE request.  The INFO method MUST NOT
 used with the announcement service.

9.5. MSML Dialog Structure and Modularity

 MSML is structured as a set of packages.  Only the core and base
 packages are required.  The Dialog Core Package defines the framework
 for MSML requests to a media server, without specific functionality.
 It consists of the "primitive" abstraction, an abstract element for

Saleem, et al. Informational [Page 57] RFC 5707 Media Server Markup Language February 2010

 control flow, the sequential execution model, and the <send> element.
 That is, the MSML Dialog Core Package allows for the execution of a
 sequence of one or more media processing primitives with the ability
 to notify events to the invocation environment.
 Primitives are contained within the MSML Dialog Base Package, which
 defines the basic <play>, <record>, <dtmf>, <dtmfgen>, <tonegen>, and
 <collect> elements.  Another package, the MSML Dialog Transform
 Package, defines the simple half-duplex filters.  More advanced
 primitives are defined in the speech and fax packages.  The MSML
 speech package depends on the MSML Dialog Base Package as it extends
 the capability of <play> by adding synthesized speech.  Finally, the
 group execution model, which is currently the only element that
 changes the flow of control, is defined in a separate MSML Dialog
 Group Package.  All of these packages are optional with the exception
 that MSML Dialog Core and MSML Dialog Base Packages MUST be
 implemented to provide the minimal functionality.

9.6. MSML Dialog Core Package

 The MSML Dialog Core Package defines the structural framework and
 abstractions for MSML dialogs (via its schema).  It also defines the
 basic elements that are not part of the core primitive or control
 abstractions.  This package is dependent on the MSML Core Package.
 Events generated by MSML dialogs, such as prompt completion, digits
 collected, or dialog termination, are communicated by the media
 server via the MSML Core Package (see MSML Core Package <event>).
 MSML dialogs are executed independently from the MSML core context.
 When an MSML dialog is started, MSML allocates the dialog control
 resources, and if successful, starts those resources executing.  MSML
 core execution then continues without waiting for the MSML dialog to
 complete.  This forking of MSML dialog invocation from the MSML core
 context is done via the <dialogstart> element.  Media streams are
 created between the MSML dialog target and other internal media
 server resources as part of dialog execution.  Stream creation is
 subject to the requirements defined in the MSML Core Package and
 media streams as defined by the MSML Conference Core Package.

9.6.1. <dialogstart>

 The <dialogstart> element is used to instantiate an MSML media dialog
 on connections or conferences.  The dialog is specified either inline
 or by a URI [n6].  Inline dialogs MUST be composed of any of the MSML
 Dialog Packages.  MSML dialogs MAY be defined externally as VoiceXML
 [n5].  The MSML dialog description MUST NOT be inline if the src
 attribute, containing a URI, is present.

Saleem, et al. Informational [Page 58] RFC 5707 Media Server Markup Language February 2010

 The originator of the MSML dialog is notified using a
 "msml.dialog.exit" event when the dialog completes.  Any results
 returned by the dialog when it exits are sent as a namelist to the
 event.
 The "msml.dialog.exit" event is also used when dialogs fail due to
 errors encountered fetching external documents or errors that occur
 within the dialog execution thread.  In this case, a namelist
 containing the items "dialog.exit.status" and
 "dialog.exit.description" is returned with the event to inform the
 client of the failure and the failure reason.  The values of these
 items are defined within this package and the MSML Core Package.
 Information from the failed dialog may be returned as additional
 namelist items.
 Attributes:
    target: an identifier of a connection or a conference that will
    interact with the dialog.  The identifier must not contain
    wildcards.  Mandatory.
    src: the URL of the dialog description.  MUST NOT be used if the
    MSML dialog description is inline.  Otherwise, an error (422) will
    result and MSML document execution will stop.
    type: a MIME type that identifies the type of language used to
    describe the dialog.  application/moml+xml and
    application/vxml+xml are used to identify MSML dialogs and
    VoiceXML [n5] respectively.  Mandatory.
    name: an instance name for the dialog.  If the attribute is not
    present, the media server will assign an identifier to the dialog.
    If the attribute is present but the name is already associated
    with the target, an error (431) will result and MSML document
    execution will stop.  Any results that a dialog generates will be
    correlated to its identifier.
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML element is returned in an error
    response.  Therefore, the value of all "mark" attributes within an
    MSML document should be unique.
 The following sections show examples of initiating an external MSML
 dialog, an inline embedded MSML dialog, and an MSML-initiated
 VoiceXML dialog.
 The following example starts an MSML dialog on a connection.

Saleem, et al. Informational [Page 59] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <dialogstart target="conn:abcd1234"
             type="application/moml+xml"
             name="sample"
             src="http://server.example.com/scripts/foo.moml"/>
     </msml>
 The following example starts an inline embedded MSML dialog on a
 connection.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
      <dialogstart target="conn:abcd1234" name="sample">
         <play>
            <audio uri="file://clip1.wav"/>
            <audio uri="http://host1/clip2.wav"/>
            <tts uri="http://host2/text.ssml"/>
            <var type="date" subtype="mdy" value="20030601"/>
         </play>
         <send target="source"
                event="done"
                namelist="play.amt play.end"/>
       </dialogstart>
    </msml>
 The following example starts a VoiceXML dialog on a connection.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <dialogstart target="conn:abcd1234"
           type="application/vxml+xml"
           name="sample"
           src="http://server.example.com/scripts/foo.vxml"/>
    </msml>
 If this dialog fails once its execution thread had begun, for
 example, the fetch of the VoiceXML document failed, an example of the
 event that would be returned would be:
    <?xml version="1.0" encoding="UTF-8"?>
    <event name="msml.dialog.exit"
           id="conn:abcd1234/dialog:sample">
       <name>dialog.exit.status</name>
       <value>423</value>
       <name>dialog.exit.description</name>
       <value>External document fetch error</value>
    </event>

Saleem, et al. Informational [Page 60] RFC 5707 Media Server Markup Language February 2010

9.6.2. <dialogend>

 Dialog end is used to terminate an MSML dialog created through
 <dialogstart> before it completes of its own accord.  The operation
 of <dialogend> depends on the dialog language being used by the
 executing context.  When that context is VoiceXML, a
 "connection.disconnected" event will be thrown to the VoiceXML
 application.  When that context is MSML dialog, a "terminate" event
 will be sent to the MSML core context.
 <dialogend> allows the executing dialog the opportunity to gracefully
 complete before generating a "msml.dialog.exit" event.  Dialog
 results may be returned and will be contained as a namelist to that
 event.
 Attributes:
    id: the identifier of a dialog.  Mandatory.
    mark: a token that can be used to identify execution progress in
    the case of errors.  The value of the mark attribute from the last
    successfully executed MSML dialog element is returned in an error
    response.  Therefore, the value of all "mark" attributes within an
    MSML document should be unique.
 For example, if the dialog from the previous example was still
 executing, the following would terminate the dialog and generate an
 "msml.dialog.exit" event.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <dialogend id="conn:abcd1234/dialog:sample"/>
    </msml>

9.6.3. <send>

 The <send> element sends an event and optional namelist to the
 recipient identified by the target attribute.  Event names are
 defined by the recipient.  In the case where the recipient is an MSML
 dialog group or primitive, the events are defined within this
 document.  Other recipients MAY use names that are suitable for their
 environment.
 The "target" attribute specifies the recipient of the event.
 Recipients MAY be other MSML dialog primitives or groups executing
 within the object, the object itself, or the environment that invoked
 the MSML dialog.  Sending events to media primitives or groups is
 supported by the MSML Dialog Group Package.  Any target that is

Saleem, et al. Informational [Page 61] RFC 5707 Media Server Markup Language February 2010

 unknown within the object is assumed to be destined to the external
 environment.  By convention, the string "source" SHOULD used to
 address that environment, but any target name distinct from the MSML
 dialog namespace MAY be used.
 Attributes:
    event: the name of an event.  Mandatory.
    target: the recipient of the event.  The recipient MUST be a MSML
    dialog primitive, the currently executing group, or the MSML
    dialog environment.  A primitive is specified by a primitive type,
    optionally appended by a period '.' followed by the identifier of
    a primitive.  Identifiers are only needed when more than one
    primitive of the same type exists in the object.  The executing
    group is specified using the token "group".  The environment is
    specified using the token "source", optionally appended by a
    period '.' followed by any environment specific target.
    Mandatory.
    namelist: a list of zero or more shadow variables that are
    included with the event.

9.6.4. <exit>

 The <exit> element causes execution of the MSML dialog to terminate.
 Attributes:
    namelist: a list of one or more shadow variables that MAY
    optionally be sent to the context that invoked the MSML Dialog
    object.

9.6.5. <disconnect>

 The <disconnect> element is similar to <exit> but has the additional
 semantics of indicating to the context that invoked the MSML dialog
 that it should disconnect from a media server, the media stream
 associated with the object.  The method of disconnection depends upon
 how the media stream was initially established.  If SIP was used, a
 <disconnect> would cause a media server to issue a BYE request.  The
 request would be sent for the SIP dialog associated with media
 session on which the MSML dialog was operating.

Saleem, et al. Informational [Page 62] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    namelist: a list of one or more shadow variables that MAY
    optionally be sent to the context that invoked the MSML dialog
    object.

9.7. MSML Dialog Base Package

 The MSML Dialog Base Package defines a required set of base
 functionality for the media server.  It supports individual media
 primitives, such as playing an announcement or collection digits, as
 well as composite operations such as play and collect.  When this
 package is used in conjunction with the MSML Dialog Group Package,
 the event-based mechanism is used to control primitives.  This
 package may also be used in conjunction with the MSML Speech Package
 to extend the functionality of prompts to include TTS and user input
 collection to include ASR.
 In the following sections, subsections of a primitive define child
 elements of that primitive and are not themselves considered
 primitives.  They do not receive events or populate shadow variables.

9.7.1. <play>

 Play is used to generate an audio or video stream.  It MUST play in
 sequence the media created by the child media elements <audio>,
 <video>, <media>, <tts>, and <var>.  When the play stops, either
 because the terminate event is received or all media generation has
 completed, the <playexit> element, if present, is executed.  At least
 one media generation element must be present.
 Play supports two states: generate and suspend.  Media generation
 occurs in the generate state and is suspended in the suspend state.
 Once in the suspend state, media generation continues upon receiving
 the generate event.  The default initial state is generate.
 Audio MAY be generated in different languages by specifying the
 xml:lang attribute for <play> and/or the child elements of <play>.
 The language is inherited by the child elements, but each child MAY
 specify its own language.  Except for physical audio clips, it is an
 error if a language is specified but the media server cannot render
 the audio in the requested language.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the play primitive.

Saleem, et al. Informational [Page 63] RFC 5707 Media Server Markup Language February 2010

    interval: specifies the delay between stopping one iteration and
    beginning another.  The attribute has no effect if iterate is not
    also specified.  Default is no interval.
    iterate: specifies the number of times the media specified by the
    child media elements should be played.  Each iteration is a
    complete play of each of the child media elements in document
    order.  Defaults to once '1'.
    initial: defines the initial state for the play element.  Default
    is "generate".
    maxtime: defines the maximum allowed time for the <play> to
    complete.
    barge: defines whether or not audio announcements may be
    interrupted by DTMF detection during play-out.  The DTMF digit
    barging the announcement is stored in the digit buffer.  Valid
    values for barge are "true" or "false", and the attribute is
    mandatory.  When barge is applied to a conference target, DTMF
    digit detected from any conference participant MUST terminate the
    announcement.
    cleardb: defines whether or not the digit buffer is cleared, prior
    to starting the announcement.  Valid values for cleardb are "true"
    or "false", and the attribute is mandatory.
    offset: defines an offset, measured in units of time, where the
    <play> is to begin media generation.  Offset is only valid when
    all child media elements are <audio>.
    skip: an amount, expressed in time, that will be used to skip
    through the media when "forward" and "backward" events are
    received.  Default is 3 s (three seconds).
    xml:lang: specifies the language to use for content that can be
    rendered in different languages.
    Events:
    The following describes input events to the media primitive
    object.  The MSML Dialog Group Package allows an event exchange
    mechanism between primitives.
    pause: causes the play to enter the suspend state.
    resume: causes play to enter the generate state.

Saleem, et al. Informational [Page 64] RFC 5707 Media Server Markup Language February 2010

    forward: skips forward through the media.  Only has effect when
    all child media elements are <audio>.
    backward: skips backward through the media.  Only has effect when
    all child media elements are <audio>.
    restart: skips to the beginning of the media.  Only has effect
    when all child media elements are <audio>.
    toggle-state: causes the suspend / generate state to toggle.
    terminate: terminates the play and assigns values to the shadow
    variables.
 Shadow Variables:
    play.amt: identifies the length of time for which media was
    generated before the play was stopped.  This does not include time
    that may have elapsed while the play was in the suspend state.
    play.end: contains the event that caused the play to stop.  When
    the play stops because all media generation has completed, end is
    assigned the value "play.complete".
 Note: Attributes barge and cleardb provide a simplified mechanism for
 controlling play operations with implicit DTMF without the use of
 <group> and event exchange mechanism.  When using the <play> element
 within the group framework and barge is specified, detection of barge
 condition generates an implicit terminate event to the play
 primitive.
 The following sections describe the child elements of <play>.

9.7.1.1. <audio>

 The <audio> element identifies prerecorded audio to play.  Local URI
 references may resolve to a single physical audio clip, a logical
 clip, or a provisioned sequence of clips (physical or logical).  A
 logical clip is one that can be rendered differently based on the
 language attribute.  Logical clips are provisioned for each of the
 languages that a media server supports.  Remote URI references are
 resolved according to the capabilities of the remote server.
 Attributes:
    uri: identifies the location of the audio to be played.  The file
    and http schemes are supported.  Mandatory.

Saleem, et al. Informational [Page 65] RFC 5707 Media Server Markup Language February 2010

    format: defines the encoding and file type of the audio resource.
    The format attribute is defined as a string type of form
    "audio/<filetype>;codecs=<codec>".  The keyword 'audio' identifies
    an audio content.  The codecs field identifies the audio file's
    codec to be used for decoding the audio content.  If format
    attribute is not specified, the filetype MUST be determined from
    the URI and the codec information MUST be determined from the
    media resource.
    audiosamplerate: identifies audio sample rate in kHz.  If not
    specified, the sample rate SHOULD be determined from the media
    resource.
    audiosamplesize: identifies audio sample size in bits.  If not
    specified, the sample size SHOULD be determined from the media
    resource.
    iterate: specifies the number of times the audio is to be played.
    Defaults to once '1'.
    xml:lang: specifies the language to use when the URI identifies a
    logical clip, either directly, or as part of a sequence.

9.7.1.2. <video>

 The <video> element identifies prerecorded multimedia to play.
 Contents identified by the URI attribute may contain audio only,
 video only, or both audio and video.  The media server SHOULD attempt
 to play both audio and video from the identified URI, if both are
 available in the content.
 Attributes:
    uri: identifies the location of the video or multimedia to be
    played.  The file and http schemes are supported.  Mandatory.
    format: defines the encoding and file type of the video or
    multimedia resource.  The format attribute is defined as a string
    type of form "video/<filetype>;codecs=<codecx>,<codecy>".  The
    keyword 'video' identifies video-only media or media containing
    audio and video.  The "codecs" field identifies the audio and/or
    video codecs to be used for decoding the file content, where the
    order of the codec values is not significant.  In the event of
    audio and video content, using 'video' keyword, the
    codecs=<codecx>,<codecy> field MAY be used to identify the audio
    codec and the video codec.  If not specified, the codec
    information SHOULD be determined from the media file.

Saleem, et al. Informational [Page 66] RFC 5707 Media Server Markup Language February 2010

    audiosamplerate: identifies audio sample rate in kHz.  If not
    specified, the sample rate SHOULD be determined from the media
    file.
    audiosamplesize: identifies audio sample size in bits.  If not
    specified, the sample size SHOULD be determined from the media
    file.
    codecconfig: identifies an optional special instruction string for
    codec configuration.  Default is to send no special configuration
    string to the codec.
    profile: identifies a video profile name specific to the codec.
    If not specified, default video profile of the codec SHOULD be
    selected.
    level: identifies a video profile level to the codec.  Default is
    to send no profile information to the codec and allow the codec to
    select an internal default.
    imagewidth: identifies the width of video image in pixels.
    Default is to use image width information from media file.
    imageheight: identifies the height of video image in pixels.
    Default is to use image height information from media file.

Saleem, et al. Informational [Page 67] RFC 5707 Media Server Markup Language February 2010

    maxbitrate: identifies the bitrate of the video signal in kbps.
    Default is to use maximum bitrate information from the media file.
    framerate: identifies the video frame rate in frames per second.
    Default is to use frame rate information from the media file.
    iterate: specifies the number of times the media content is to be
    played.  Defaults to once '1'.

9.7.1.3. <media>

 The <media> element identifies multimedia content for play.  All
 content of the <media> element MUST start to play concurrently.  This
 element may be used to generate a multimedia stream from two
 independent media resources, one identifying audio and the other
 identifying video.
 The <media> element MUST contain at least one child element.  Valid
 child elements of <media> are <audio> and <video>, as described
 earlier.  <media> element MUST contain at most one <audio> element or
 at most one <video> element.

9.7.1.4. <var>

 The <var> element specifies the generation of audio from a variable
 using prerecorded audio segments.  A variable represents a semantic
 concept (such as date or number) and dynamically produces the
 appropriate speech.
 Prerecorded audio allows an application vendor or service provider to
 choose the exact voice for their audio and therefore completely
 control the "sound and feel" of the service provided to end users.
 It provides very high audio quality and allows the variables to blend
 seamlessly into the surrounding audio segments.
 Text to speech (TTS) using Speech Synthesis Markup Language (SSML)
 [n11] may also be used to render variables, but may not provide as
 good quality, or allow as complete control of the "sound and feel" or
 user experience.  TTS is normally used for reading text such as
 emails and for very large vocabularies such as stock names.  TTS
 results in a very clear difference between the variables and the
 surrounding audio segments.  (See MSML Dialog Speech Package.)
 Attributes:
    type: specifies the type of variable.  Mandatory.  Variable type
    must be one of "date", "digits", "duration", "month", "money",
    "number", "silence", "time", or "weekday".

Saleem, et al. Informational [Page 68] RFC 5707 Media Server Markup Language February 2010

    subtype: specifies an optional clarification of type.  Specific
    values depend upon the type.
    value: text that should be rendered appropriate to the type and
    subtype attributes.  Mandatory.
    xml:lang: specifies the language to use when rendering the
    variable.

9.7.1.5. <playexit>

 The <playexit> element MUST be invoked when generation of all content
 of the <play> has come to completion.  The contents of this element
 MAY be used to send events.
 Attributes:
    none

9.7.2. <dtmfgen>

 DTMF generator originates one or more DTMF digits in sequence.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the dtmfgen primitive.
    digits: a string of characters from the alphabet "0-9a-d#*" that
    correspond to a sequence of DTMF tones.  Mandatory.
    level: used to define the power level for which the tones will be
    generated.  Expressed in dBm0 in a range of 0 to -96 dBm0.  Larger
    negative values express lower power levels.  Note that values
    lower than -55 dBm0 will be rejected by most receivers (TR-
    TSY-000181, ITU-T Q.24A).  Default is -6 dBm0.
    dur: the duration in milliseconds for which each tone should be
    generated.  Implementations may round the value if they only
    support discrete durations.  Default is 100 ms.
    interval: the duration in milliseconds of a silence interval
    following each generated tone.  Implementations may round the
    value if they only support discrete durations.  Default is 100 ms.
 Events:
    terminate: terminates DTMF generation and assigns values to the

Saleem, et al. Informational [Page 69] RFC 5707 Media Server Markup Language February 2010

    shadow variables.
 Shadow Variables:
    dtmfgen.end: contains the event that caused DTMF generation to
    stop.
 The following sections describe the child elements of <dtmfgen>.

9.7.2.1. <dtmfgenexit>

 The <dtmfgenexit> element MUST be invoked when the DTMF generation
 operation completes or is terminated as a result of receiving the
 terminate event.  The <dtmfgenexit> element MAY be used to send
 events when the DTMF generation has completed.
 Attributes:
    none

9.7.3. <tonegen>

 Tone generator allows customized tone generation.  A sequence of
 varying tones with optional silence intervals can be composed using
 the <tonegen> element.  Child elements of <tonegen>, namely <tone>
 and <silence>, specify a single tone or sequence of tones.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the tonegen primitive.
    iterate: A numeric value specifying the total number of
    iterations.  A value of 'forever' represents infinite repetitions.
    Optional.  Default is 1.
 Events:
    terminate: terminates tone generation and assigns values to the
    shadow variables.
 Shadow Variables:
    tonegen.end: contains the event that caused tone generation to
    stop.
 The following sections describe the child elements of <tonegen>.

Saleem, et al. Informational [Page 70] RFC 5707 Media Server Markup Language February 2010

9.7.3.1. <tone>

 The <tone> element specifies a single tone with an optional silence
 interval.  The tone specification consists of two tone frequencies,
 their attenuation values, a duration of the tone, and the number of
 times to repeat the tone.
 Attributes:
    duration: time duration or length of the individual tone,
    specified in "ms" or "s" in increments of 10 ms.  A value of 0
    represents an infinite duration.  Mandatory.
    iterate: specifies the number of times to execute the contents of
    <tone> element.  A value of 'forever' represents infinite
    repetitions.  Optional.  Default is 1.
 Events:
    none
 Child Elements:
    The child elements of <tone> element specify a single tone and an
    optional silence interval to be inserted at the end of tone
    generation.  A tone is defined by <tone1> and <tone2> elements.
    Each <tone> element MUST contain at least one of <tone1> or
    <tone2>, or MAY contain <tone1> and <tone2> exactly once.
    <tone1>
       Attributes:
          freq: specifies the frequency of the first tone in "Hz",
          ranging from 0 to 3999 Hz.  Mandatory.
          atten: specifies the attenuation level expressed in dBm0,
          ranging from 0 to -96 dBm0.  Mandatory.
    <tone2>
       Attributes:
          freq: specifies the frequency of the second tone in "Hz",
          ranging from 0 to 3999 Hz.  Mandatory.
          atten: specifies the attenuation level expressed in dBm0,
          ranging from 0 to -96 dBm0.  Mandatory.

Saleem, et al. Informational [Page 71] RFC 5707 Media Server Markup Language February 2010

    <silence> - Refer to the silence element definition below.

9.7.3.2. <silence>

 The <silence> element inserts a silence interval as optional content
 of <tonegen> or <tone> elements.
 Attributes:
    duration: specifies the amount of silence interval in "ms" or "s",
    in increments of 10ms.  Mandatory.
 Events:
    none

9.7.3.3. <tonegenexit>

 The <tonegenexit> element MUST be invoked when the tone generation
 operation completes or is terminated as a result of receiving the
 terminate event.  The <tonegenexit> element MAY be used to send
 events when the tone generation has completed.
 Attributes:
    none

9.7.4. <record>

 Record creates a recording.  Similar to play, <record> supports two
 states: create and suspend.  Received media becomes part of the
 recording when <record> is in the create state and is discarded when
 it is in the suspend state.
 Recording MUST be terminated when a terminate event is received or
 when a nospeech event is received and no audio has yet been recorded.
 <record> differentiates different types of terminate events.
 An optional <play> element MAY be specified as a child element of
 <record>.  This mechanism provides a complete play-record operation,
 where the prompts specified within the <play> element are played in
 advance of start of recording.
 Note: Attributes prespeech, postspeech, and termkey provide a
 simplified mechanism for controlling record operations using implicit
 DTMF and VAD, without the use of <group> and event exchange
 mechanism.

Saleem, et al. Informational [Page 72] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the record primitive.
    append: a boolean that defines whether the recording is allowed to
    be appended to an existing file if dest already exists.  Default
    is "false".  The attribute is ignored if the scheme is http.
    dest: the destination for the recording, which will contain either
    audio only, video only, or both audio and video depending on the
    stream(s) being recorded.  Recording MAY be either local or
    external based upon the attribute value.  File and http schemes
    are supported.
    audiodest: the destination for the audio-only recording.
    Recording MAY be either local or external based upon the attribute
    value.  All combinations of dest, audiodest, and videodest are
    valid.  File and http schemes are supported.
    videodest: the destination for the video-only recording.
    Recording MAY be either local or external based upon the attribute
    value.  All combinations of dest, audiodest, and videodest are
    valid.  File and http schemes are supported.
    format: defines the encoding and file type of the recording.  The
    format attribute is defined as a string type of form
    "audio|video/filetype;codecs=x,y".  The keyword 'audio' identifies
    an audio only recording, while the keyword 'video' identifies
    video-only recording or an audio plus video recording.  The codecs
    field identifies the audio and/or video codecs to be used for the
    recording, where the order of the codec values is not significant.
    In the event of audio and video recording, using 'video' keyword,
    the codecs=x,y field MAY be used to identify the audio codec and
    the video codec.  Mandatory.
    codecconfig: identifies an optional special instruction string for
    codec configuration.  Default is to send no special configuration
    string to the codec.
    audiosamplerate: identifies audio sample rate in kHz.  If not
    specified, the sample rate SHOULD be determined from the media
    source.
    audiosamplesize: identifies audio sample size in bits.  If not
    specified, the sample size SHOULD be determined from the media
    source.

Saleem, et al. Informational [Page 73] RFC 5707 Media Server Markup Language February 2010

    profile: identifies a video profile name specific to the codec.
    If not specified, default video profile of the codec SHOULD be
    selected for the recording.
    level: identifies a video profile level to the codec.  Default is
    to send no profile information to the codec and allow the codec to
    select an internal default.
    imagewidth: identifies the width of video image in pixels.
    Default is to use image width information from the media source.
    imageheight: identifies the height of video image in pixels.
    Default is to use image height information from the media source.
    maxbitrate: identifies the bitrate of the video signal in kbps.
    Default is to use maximum bitrate information from the media
    source.
    framerate: identifies the video frame rate in frames per second.
    Default is to use frame rate information from the media source.
    initial: defines the initial state for the record element.
    Default is "create", which starts the recording as soon as the
    <record> element is executed.  The "initial" attribute is
    applicable only when <record> is used within the <group>
    structure.
    maxtime: defines the maximum length of the recording in units of
    time.  Mandatory.
    prespeech: defines a timer value, in seconds, for detection of
    absence of audio energy at the start of the record operation.  If
    no audio energy is detection for the amount of time specified by
    prespeech, the recording is terminated.  Default is 0 s, which
    does not activate the prespeech timer.
    postspeech: defines a timer value, in seconds, for detection of
    absence of audio energy while the recoding is in progress.  During
    an in progress recording, if absence of audio energy is detected
    as specified by the postspeech timer, the recording is terminated.
    Default is 0 s, which disables the ability to terminate a
    recording due to postspeech silence.
    termkey: defines a single DTMF key that, when detected, terminates
    the recording.  Absence of this attribute prevents the recording
    from being terminated due to detection of DTMF digits.  When
    termkey is specified, the detected DTMF digit terminates the
    recording and the DTMF digit is not entered in the digit buffer.

Saleem, et al. Informational [Page 74] RFC 5707 Media Server Markup Language February 2010

 Events:
    The following describes input events to the media primitive
    object.  The MSML Dialog Group Package allows an event exchange
    mechanism between primitives.
    pause: causes the record to enter the suspend state.  Received
    media is discarded.
    resume: causes the record to resume if it was suspended.  It has
    no effect otherwise.
    toggle-state: causes the suspend / create state to toggle.
    terminate: terminates the recording and assigns values to the
    shadow variables.
    terminate.cancelled: terminates the recording and assigns values
    to the shadow variables.  If the dest attribute used the file
    scheme, the local recording is deleted.  Applications are
    responsible for removing external files created using the http
    scheme.
    terminate.finalsilence: terminates the recording and assigns
    values to the shadow variables.  If the dest attribute used the
    file scheme, the final silence is removed from the recording.
    nospeech: terminates the recording and assigns values to the
    shadow variables if it is received and no recording has yet been
    created.  The "nospeech" event is ignored if audio has already
    been recorded.
 Shadow Variables:
    record.len: the actual length of the recording measured in units
    of time.  This does not include time that may have elapsed while
    the record was in the suspend state.
    record.end: contains the event that caused the record to
    terminate.  When the record terminates because maxtime is
    exceeded, end is assigned the value "record.complete.maxlength".
    record.recordid: contains the value of the "dest" attribute, if
    supplied, otherwise contains a media server assigned record
    identifier.
    Record termination due to prespeech silence results in assigned
    value of "record.failed.prespeech"

Saleem, et al. Informational [Page 75] RFC 5707 Media Server Markup Language February 2010

    Record termination due to postspeech silence results in assigned
    value of "record.complete.postspeech"
    Record termination due to DTMF detection results in assigned value
    of "record.complete.termkey"
 The following sections describe the child elements of <record>.

9.7.4.1. <play>

 The optional <play> element as a child element of <record> allows a
 prompt to be played prior to start of recording.  The record
 operation starts at the end of the play sequence or if the play is
 barged by DTMF, assuming that barge=true is specified for <play>.
 For a complete description, refer to <play> element.

9.7.4.2. <tonegen>

 The optional <tonegen> element as a child element of <record> allows
 a tone or sequence of tones to be played prior to start of recording.
 The record operation starts at the end of the tone generation.  For a
 complete description, refer to <tonegen> element.

9.7.4.3. <recordexit>

 The <recordexit> element MUST be invoked when the record operation
 completes or when the recording is terminated as a result of
 receiving the terminate event.  The <recordexit> element MAY be used
 to send events when the recording has completed.
 Attributes:
    none

9.7.5. <dtmf> or <collect>

 DTMF input fulfills several roles within MSML dialogs.  It is used to
 trigger events that will affect the media processing operation of
 other primitives.  It is also used to collect DTMF digits from a
 media stream that are to be reported back to the user of MSML dialog.
 Often DTMF detection is used for both purposes.  Barge is the most
 common example, where a prompt is stopped based upon DTMF input but
 more digits may remain to be collected.
 DTMF detection supports multiple simultaneous recognition patterns.
 Different patterns can be used to trigger sending different events in
 order to implement DTMF controls.  Alternatively, one pattern may be

Saleem, et al. Informational [Page 76] RFC 5707 Media Server Markup Language February 2010

 used to represent a collection and another pattern, a substring of
 the first, used as a barge indication.
 An optional <play> element MAY be specified as a child element of
 <dtmf> or <collect>.  This mechanism provides a complete play-collect
 operation, where the prompt(s) specified within the <play> element
 are played in advance of DTMF digit collection.
 Note that all patterns share the same digit collection buffer, inter-
 digit timing, a single <nomatch> element, and a single <noinput>
 element.  As such, multiple patterns may not be suitable to support
 simultaneous collections for different purposes.  When this is
 required, separate <dtmf> elements should be used instead.
 <dtmf> terminates if any of the <pattern>, <noinput>, or <nomatch>
 elements are matched the maximum number of times that they are
 allowed.  The number of times they may match may be specified as an
 attribute of <dtmf> or of the individual child elements.
 Element identifier <dtmf> is equivalent to <collect>.  However,
 <collect> is the preferred name.  MSML clients SHOULD use <collect>,
 while MSML servers SHOULD support both.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to this primitive.
    cleardb: a boolean indication of whether the buffer for digit
    collection should be cleared of any collected digits when the
    element is instantiated.  If set to false, any digits currently in
    the buffer MUST be immediately compared against the pattern
    elements.
    fdt: defines the first-digit timer value.  The first-digit timer
    is started when DTMF detection is initially invoked.  If no DTMF
    digits are detected during this initial interval, the <noinput>
    element MUST be invoked.  Optional, default is 0 s (wait forever
    for the first digit).
    idt: defines the inter-digit timer to be used when digits are
    being collected.  When specified, the timer is started when the
    first digit is detected and restarted on each subsequent digit.
    Timer expiration is applied to all patterns.  After that, if any
    patterns remain active and a nomatch element is specified, the
    nomatch is executed and DTMF input MUST terminate.  The idt
    attribute should only be used when digit collection is being
    performed.  Optional, default is 4 s.

Saleem, et al. Informational [Page 77] RFC 5707 Media Server Markup Language February 2010

    edt: defines the extra-digit timer value.  Specifies the length of
    time the media server MUST wait after a match to detect a
    termination key, if one is specified by the <pattern> element.
    Optional, default is 4 s.
    starttimer: boolean value that defines whether the first digit
    timer (fdt) is started initially.  When set to false, the
    starttimer event must be received for it to start.  Default is
    "false".
    iterate: specifies the number of times the <pattern>, <noinput>,
    and <nomatch> elements may be executed unless those elements
    specify differently.  The value "forever" MAY be used to indicate
    that these may be executed any number of times.  Default is once
    '1'.
    ldd: defines the minimum duration for a digit to be held in order
    for it to be detected as a long DTMF digit.  A long DTMF digit
    event MUST be treated as a single DTMF event, and MUST contain an
    extra character 'L' at the end to be distinguished from the other
    regular digit events.  For example, "#L" and "#" are different
    DTMF events.  Optional, default of 0 s.  A value of 0 s disables
    long DTMF digit detection and reporting.  Attribute value is an
    integer with a valid range from 100 ms to 100 s (units MUST be
    supplied).
 Events:
    The following describes input events to the media primitive
    object.  The MSML Dialog Group Package allows an event exchange
    mechanism between primitives.
    starttimer: starts the first digit timer (fdt) if it has not
    already been started.  Has no effect otherwise.
    terminate: terminates the DTMF input and assigns values to the
    shadow variables.
 Shadow Variables:
    dtmf.digits: the string of DTMF digits that have been received
    (the contents of the digit buffer).
    dtmf.len: the number of digits in the digit buffer.
    dtmf.last: the last digit in the digit buffer.

Saleem, et al. Informational [Page 78] RFC 5707 Media Server Markup Language February 2010

    dtmf.end: contains the event that caused the <dtmf> to terminate
    or is assigned one of "dtmf.match", "dtmf.noinput", or
    "dtmf.nomatch" depending upon which of the corresponding elements
    reached its maximum.
 The following sections describe the child elements of <dtmf> or
 <collect>.

9.7.5.1. <play>

 The optional <play> element as a child element of <dtmf> or <collect>
 allows a prompt to be played prior to DTMF digit collection.  DTMF
 digit collection starts at the end of the play sequence or if the
 play is barged by DTMF, assuming that barge=true is specified for
 <play>.  For a complete description, refer to <play> element.

9.7.5.2. <pattern>

 The <pattern> element describes one or more DTMF digits that are to
 be recognized.  When the pattern is matched, the child elements MUST
 be executed.
 Attributes:
    digits: the digit pattern that should be matched.  Mandatory.
    format: an enumerated value that defines the format used to
    express the digit pattern.  The format may be "mgcp" or "megaco"
    for patterns expressed as a digit map from those specifications,
    or as one of the simple built-in formats defined within this
    specification.  Currently, a single built-in format "moml+digits"
    is defined that allows a match based on either one or more
    specific digits, or based upon a specific length specification
    with an optional return key.  "moml+digits" is the default.
    iterate: specifies the number of times the <pattern> may be
    matched.  The value "forever" may be used to indicate that
    <pattern> may be matched any number of times.  This value
    overrides any specified in <dtmf>.  Default is once '1'.

9.7.5.3. <detect>

 The contents of the <detect> element MUST be executed whenever any
 DTMF is first detected.  It MUST be matched at most once.
 Attributes:
    none

Saleem, et al. Informational [Page 79] RFC 5707 Media Server Markup Language February 2010

9.7.5.4. <noinput>

 The <noinput> element is used when DTMF is being collected.  Children
 of the <noinput> element MUST be executed when DTMF has not been
 detected and the first digit timeout occurs.
 Attributes:
    iterate: specifies the number of times the <noinput> may be
    triggered.  The value "forever" may be used to indicate that
    <noinput> may be triggered any number of times.  This value
    overrides any specified in <dtmf>.  Default is once '1'.

9.7.5.5. <nomatch>

 The <nomatch> element is used when DTMF is being collected.  Children
 of the <nomatch> element MUST be executed when it is determined that
 none of the individual patterns can be matched.
 Attributes:
    iterate: specifies the number of times the <nomatch> may be
    triggered.  The value "forever" may be used to indicate that
    <nomatch> may be triggered any number of times.  This value
    overrides any specified in <dtmf>.  Default is once '1'.

9.7.5.6. <dtmfexit>

 The <dtmfexit> element MUST be invoked when the dtmf input completes
 because one of <pattern>, <noinput>, or <nomatch> occurred its
 maximum number of times.
 Attributes:
    None

9.7.6. <moml>

 The root element <moml> MUST be used when the document is a stand-
 alone MSML dialog, where the invoking application media type
 indicates 'application/moml+xml'.  Additionally, for backwards
 compatibility, the <moml> element MUST be used within <dialogstart>,
 which contains an inline embedded MSML dialog.
 Valid contents of <moml> are all elements described within this MSML
 Dialog Base Package.

Saleem, et al. Informational [Page 80] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    version: "1.0" Mandatory.
    id: an identifier unique to this object.  Events returned from
    MSML dialog (the "target" attribute of a <send> is equal to
    "source") will be correlated with this identifier.  Mandatory.
 Events:
    terminate: terminates the MOML context.  A terminate event gets
    sent to the currently executing <group> or primitive.

9.8. MSML Dialog Group Package

 The group package defines a single control flow construct that
 specifies concurrent execution.  Primitives are composed for
 concurrent execution by placing them within a <group> element.
 Groups define how media flows between multiple concurrently executing
 primitives.  They have one or more inputs and one or more outputs.  A
 <group> represents the declaration of a complex media processing
 operation.  The event interaction between primitives (see the
 following subsection) is defined within the context of one or more
 groups.  However groups themselves do not scope events, they simply
 define that primitives are concurrently executing and a primitive
 must be executing in order to receive an event.
 Placing primitives within a group structure is an optional feature of
 this specification.  It allows for complex services to created using
 the event exchange mechanism between the primitives.  For simpler
 services, such as play/collect or play/record, the use of group
 mechanism is not necessary.  MSML Dialog Group Package is dependent
 on the MSML Dialog Base Package.
 Groups may also be used to describe media objects that transform a
 media stream while optionally allowing application or user control of
 the transformation.  For example, a gain control could be defined
 that responds to user speech or DTMF input.  In this case, a
 recognition primitive would send events to a gain control primitive.
 Groups have one attribute that defines the media flow within them.
 They also have a dimension that defines how many media inputs and
 outputs they have.  Currently, dimensions of 1 and 2 are supported
 based upon the group topology.  These correspond to a group with one
 input and one output and a group with two inputs and two outputs.

Saleem, et al. Informational [Page 81] RFC 5707 Media Server Markup Language February 2010

 Media flow to and from the primitives within the group is based upon
 a topology attribute of the <group> element.  The topology attribute
 defines a topology schema and implies the group dimension.
 There are several common ways in which primitives are often connected
 together.  A schema provides a convenient template that can be
 applied to multiple primitives without having to define all of the
 individual media relationships.  The following two schemas are
 initially defined for one-dimensional groups:
 o  parallel: specifies that media sent to the group is sent to every
    primitive that has an input.  The group bridges the output from
    every primitive that has an output into a single common group
    output.
 o  serial: specifies that the first primitive listed in the group
    receives the media sent to the group.  Its output is to be
    connected to the input of the next primitive defined within the
    group and so on until the last primitive within the group becomes
    the group output.
 Groups with these topologies are shown in the two diagrams below.
 The group on the left has a parallel topology and that on the right
 has a serial topology.
         /-> P1 --\
        /          \
 G(in) +---> P2 ----> G(out)     G(in) --> P1 --> P2 --> P3 --> G(out)
        \          /
         \-> P3 --/
 More complex media flows MAY be created by nesting groups of serial
 and parallel topologies within each other.  For example, the diagram
 below has a group with a serial topology nested within a star
 topology.
             /-----> P1 ------------------------\
            /                                    \
    Gs(in) +-> Gp(in) --> P2 --> P3 --> Gp(out) -+> Gs(out)
 This combination could be used to create record operation where DTMF
 was to be clamped from the recording itself, but a DTMF key press is
 still used to stop the recording.  In this case, P1 would be a DTMF
 recognizer, P2 would be a clamp primitive, and P3 a recorder as shown
 by the following example.  This example omits child elements and
 attributes not concerned with the core concept.  The following
 section discusses sending events, and the details of each of the
 primitives are found in section 4.

Saleem, et al. Informational [Page 82] RFC 5707 Media Server Markup Language February 2010

    <group topology="parallel">
       <dtmf/>
       <group topology="serial">
          <clamp/>
          <record/>
       </group>
    </group>
 A single schema, "fullduplex", is defined for a two-dimensional
 group.  A full-duplex two-dimensional group has exactly two immediate
 children.  Those children may be primitives or other one-dimensional
 groups.  A "fullduplex" group must only be used as the top-most group
 and must not be nested.  Each primitive (P1) and group (G2) becomes
 half of the full-duplex group as shown in the diagram below.
    G-A(in1)  +-> G2 --> G-B(out1)
    G-A(out2) <-- P1 <-+ G-B(in2)
 Full-duplex groups are symmetrical when both halves are the same.
 They are asymmetrical when they differ.  Asymmetric groups need to
 have a name associated with each side.  The left side is defined as
 the input of the first child of the full-duplex group combined with
 the output of the second child.  The right side is reverse.  These
 sides were labeled A and B respectively in the preceding diagram.
 An example of a full-duplex group is the user operated gain control
 mentioned at the beginning of this subsection.  The gain should
 operate on the audio that a user hears, but the gain is controlled by
 recognizing things such as DTMF or spoken commands in media that the
 user originates.  The following shows the XML tag grouping that would
 accomplish this and corresponds to the media flow shown in the
 diagram above.  If the user's audio is not required for anything
 other than control of the gain, then the <relay> is not required and
 the internal group could be omitted.  A complete XML description for
 this is included in the examples section.
    <group topology="fullduplex">
       <group topology="parallel">
          <dtmf/>
          <relay/>
       </group>
       <gain/>
    </group>
 Primitives within a group MUST begin concurrently but MAY finish
 asynchronously based upon events that they receive or their task
 completes.  A group MUST terminate when all of the primitives within

Saleem, et al. Informational [Page 83] RFC 5707 Media Server Markup Language February 2010

 it have completed.  If the group contains a <groupexit> element, then
 the contents of that element MUST be executed as part of group
 termination.
 A group itself MAY receive a terminate event requesting termination.
 A terminate event sent to the group causes a terminate event to be
 sent to each of its currently active primitives.  The <groupexit>
 element is not executed until all primitives have processed their
 respective terminate events.

9.8.1. <group>

 The <group> element allows the contained primitives to be executed
 concurrently.
 Attributes:
    topology: specifies a schema that defines the flow of media within
    the group.  Three schemas are initially defined.  "fullduplex" is
    specified for use with two-dimensional groups.  "parallel" and
    "serial" are for use with one-dimensional groups.  The definitions
    of these topologies are in section 9.8.  Mandatory.
    id: identifies the name of the group.  Mandatory when groups are
    nested.
 Events:
    terminate: causes a terminate event to be sent to each element
    contained within the group.

9.8.2. <groupexit>

 The <groupexit> element allows events to be sent when group
 processing completes.  Group processing completes when all contained
 primitives terminate.
 Attributes:
    none
 Events:
    none

Saleem, et al. Informational [Page 84] RFC 5707 Media Server Markup Language February 2010

9.9. MSML Dialog Transform Package

 The MSML Dialog Transform Package gathers together the simple
 primitives that work as filters on half-duplex media streams.

9.9.1. <vad>

 Voice activity detection (VAD) is used to detect voice and silence
 when speech recognition is not required.  Similar to both speech and
 DTMF, a VAD has different media conditions that it can match.  Those
 conditions can be qualified by a minimum length of time that is
 required for them to be considered recognized.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the vad primitive.
    starttimer: boolean value that defines whether the timer is
    started to allow recognition of the initial condition (voice,
    silence).  When set to false, the starttimer event must be
    received in order for the initial condition to be recognized.  The
    timer does not affect recognition of the transition conditions.
    Default is "false".
 Events:
    starttimer: starts the timer to allow recognition of the initial
    condition if it has not already been started.  Has no effect
    otherwise.
    terminate: terminates voice activity detection.
 Shadow Variables:
    none
 The following sections describe the child elements of <vad>.

9.9.1.1. <voice>, <silence>, <tvoice>, <tsilence>

 Each child element corresponds to a condition that a VAD can detect.
 The first two detect when voice or silence has been initially present
 for a minimum length of time since the VAD was started.  The second
 two require that a transition to the voice or silence condition first
 occur.

Saleem, et al. Informational [Page 85] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    len: the length of time the condition must persist in order to be
    recognized.  Mandatory.  In the case of <tvoice> and <tsilence>,
    the length of time applies only to the final recognized condition.
    sen: the maximum length of time the condition not being detected
    may occur without causing the detector to begin measuring that
    condition.

9.9.2. <gain>

 Gain MAY be used to adjust of the gain of a media stream by a
 specific amount.  Application of <gain> removes any previous
 connection AGC setting used by the <agc> element.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the gain primitive.
    incr: an increment, expressed in dB, that will be used to adjust
    the gain when "louder" and "softer" events are received.  Default
    is 3 dB.
    amt: a specific gain to apply specified in dB.  Mandatory.
 Events:
    mute: self-explanatory.
    unmute: self-explanatory.
    reset: sets the gain to zero dB.
    louder: makes the audio on a stream louder.
    softer: makes the audio on a stream quieter.
    amt: sets the gain to the specified value between -96 dB and 96
    dB.

9.9.3. <agc>

 Automatic gain control MAY be used to have a media server
 automatically adjust the gain of a media stream.  Application of
 <agc> removes any previous connection gain setting used by the <gain>
 element.

Saleem, et al. Informational [Page 86] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the gain primitive.
    tgtlvl: the desired target level for AGC, specified in dBm0 with a
    valid range of -40 to 0.  Mandatory.
    maxgain: an optional attribute used to specify the maximum gain
    that AGC will apply, specified in dBm0 with a valid range of 0 to
    40, with a default of 10.
 Events:
    mute: self-explanatory.
    unmute: self-explanatory.

9.9.4. <gate>

 The <gate> element is a simple filter that will pass or halt media,
 regardless of the format of the media stream, based on the events it
 receives.  <gate> shares the same mute and unmute events for
 compatibility with the gain primitives <gain> and <agc>.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the gate primitive.
    initial: the values "pass" and "halt" define whether media is
    initially allowed to pass.  Default is to pass.
 Events:
    mute: halts media flow through the primitive.
    unmute: allows media to pass through the primitive.

9.9.5. <clamp>

 This element MAY be used to filter DTMF tones from a media stream.
 Media other than DTMF tones is passed unchanged.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the clamp primitive.

Saleem, et al. Informational [Page 87] RFC 5707 Media Server Markup Language February 2010

 Events:
    none.

9.9.6. <relay>

 This element is a simple primitive that copies its input to its
 output.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the relay primitive.
 Events:
    none.

9.10. MSML Dialog Speech Package

 The MSML speech package defines functionality that MAY be used for
 automatic speech recognition <speech> and extends the <play>
 primitive defined in the MSML Dialog Base Package to include speech
 synthesis.  As such, this package depends on the MSML Dialog Base
 Package.

9.10.1. <speech>

 The <speech> element activates grammars or user input rules
 associated with speech recognition.  If multiple grammars are
 specified, all are activated.  All active grammars share the same
 timers, recognition attributes, and <noinput> and <nomatch> elements.
 Each grammar may have its own <match> element.
 <speech> terminates if any of the <grammar>, <noinput>, or <nomatch>
 elements are matched the maximum number of times that they are
 allowed.  The number of times they may match may be specified as an
 attribute of <speech> or of the individual child elements.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the speech primitive.
    noint: specifies a time period during which speech input must be
    started; otherwise, the associated <noinput> element is invoked.

Saleem, et al. Informational [Page 88] RFC 5707 Media Server Markup Language February 2010

    norect: specifies a maximum time period during which speech must
    begin to be matched; otherwise, the associated <nomatch> element
    is invoked.
    spcmplt: specifies the length of silence necessary after speech
    before a result will be finalized in the case where there is a
    complete match of an active grammar.  Following the silence, the
    appropriate <match> element will be triggered if the result is
    above the confidence level.  Otherwise, a <nomatch> element will
    be triggered.
    spincmplt: specifies the length of silence necessary after speech
    before a result will be finalized in the case where there is a
    incomplete match of all active grammars.  Following the silence,
    the <nomatch> element will be triggered.
    confidence: the minimum confidence level that the recognizer must
    have to consider a recognition result as matching a grammar.
    Expressed as an integer between 1-100.
    sens: specifies the sensitivity of the recognizer to determine
    whether speech is present.  Lower sensitivity may be required for
    the recognizer to work well in the presence of high background
    noise or line echo.
    starttimer: boolean value that defines whether the no input
    (noint) and no recognition (norect) are started initially.  When
    set to false, the starttimer event must be received in order to
    start them.  Default is "false".
    iterate: specifies the number of times the <grammar>, <noinput>,
    and <nomatch> elements may be executed unless those elements
    specify differently.  The value "forever" may be used to indicate
    that these may be executed any number of times.  Default is once
    '1'.
 Events:
    sens: sets the sensitivity of the recognizer as described above.
    starttimer: starts the no input (noint) and no recognition
    (norect) timers if they have not already been started.  Has no
    effect otherwise.
    terminate: terminates the speech input and assigns values to the
    shadow variables.

Saleem, et al. Informational [Page 89] RFC 5707 Media Server Markup Language February 2010

 Shadow Variables:
    speech.end: contains the event that caused the <speech> to
    terminate or is assigned one of "speech.match", "speech.noinput",
    or "speech.nomatch" depending upon which of the corresponding
    elements reached its maximum.
    speech.results: contains the results of a matched grammar.  The
    results are formatted using the Natural Language Semantics Markup
    Language (NLSML) [n4].  When this variable is referenced to return
    results, the results are returned as a separate MIME entity.
 The following sections describe the child elements of <speech>.

9.10.1.1. <grammar>

 The <grammar> element specifies and activates a speech grammar based
 on Speech Recognition Grammar Specification (SRGS) [n3] XML notation.
 Grammars may be referenced by a URI or defined inline.  Child
 elements of <match> MUST be executed when the specified speech
 grammar is matched.
 Attributes:
    uri: specifies the location of an SRGS grammar when the grammar is
    not defined inline.
    iterate: specifies the number of times the <grammar> may be
    matched.  The value "forever" MAY be used to indicate that
    <grammar> may be matched any number of times.  This value
    overrides any specified in <speech>.  Default is once '1'.

9.10.1.2. <match>

 <match> is a child of <grammar> and specifies the actions to take
 when the corresponding grammar is matched.

9.10.1.3. <noinput>

 The <noinput> element is used when speech is being recognized.
 Children of the <noinput> element MUST be executed when speech has
 not been detected and the no input timeout (noint) occurs.

Saleem, et al. Informational [Page 90] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    iterate: specifies the number of times the <noinput> may be
    triggered.  The value "forever" may be used to indicate that
    <noinput> may be triggered any number of times.  This value
    overrides any specified in <speech>.  Default is once '1'.

9.10.1.4. <nomatch>

    The <nomatch> element is used when speech is being recognized.
    Children of the <nomatch> element MUST be executed when it is
    determined that none of the active grammars will match.
    Attributes:
    iterate: specifies the maximum number of times the <nomatch> may
    be triggered.  The value "forever" MAY be used to indicate that
    <nomatch> may be triggered any number of times.  This value
    overrides any specified in <speech>.  Default is once '1'.

9.10.1.5. <speechexit>

 The <speechexit> element MUST be invoked when the speech input
 completes because one of <grammar>, <noinput>, or <nomatch> occurred
 its maximum number of times.
 Attributes:
    none

9.10.2. <play>

 The <play> element, as defined in the MSML Dialog Base Package, is
 extended with a new child element for synthesizing speech.  From an
 XML perspective, <tts> is a member of a media substitution group.
 See the schema at the end of this document for details.
 The following sections describe the child elements of <play>.

9.10.2.1. <tts>

 Contents of the <tts> element are rendered using text-to-speech
 services and must be compliant to the SSML specification [n11].
 Element content MAY be plain text, contain the SSML <speak> element,
 or the uri attribute should identify the location of text to be
 rendered.

Saleem, et al. Informational [Page 91] RFC 5707 Media Server Markup Language February 2010

 Attributes:
    uri: identifies the location of the text to be rendered.  The file
    and http schemes are supported.
    iterate: specifies the number of times the text-to-speech block is
    to be rendered.  Defaults to once '1'.
    xml:lang: specifies the language to use when it is not explicitly
    specified as an attribute for <speak>.

9.11. MSML Dialog Fax Detection Package

 The Fax Detection Package defines primitives that allow a media
 server to provide facsimile detection services.

9.11.1. <faxdetect>

 Fax tone detection is used to detect the presence of the T.30 Calling
 Tone (CNG) or Called Station Identification (CED) tone in a media
 stream.  Child elements of <faxdetectexit> MUST be executed when a
 CNG tone is detected.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the faxdetect primitive.
 Events:
    terminate: terminates fax tone detection and assigns values to the
    associated shadow variables.
 Shadow Variables:
    faxdetect.tone: A string that specifies the fax tone type detected
    by the media server.  Values supported SHOULD include "CED",
    "CNG", or empty string.  The empty string MUST be used if fax tone
    detection terminated before detection of a fax tone, resulting in
    execution of the <faxdetectexit> element.
    faxdetect.end: A string value that specifies the reason for
    termination of <faxdetect>.  Values supported SHOULD include
    "faxdetect.complete" (due to detection of CED or CNG tone),
    "faxdetect.failed.noresource" (failed due to lack of resources on
    the media server), "faxdetect.failed" (failed due to any other
    reason) "faxdetect.terminated" (terminated by <dialogend>), or
    undefined.

Saleem, et al. Informational [Page 92] RFC 5707 Media Server Markup Language February 2010

9.11.2. <faxdetectexit>

 The <faxdetectexit> element MUST be invoked when fax detection,
 invoked via <faxdetect>, terminates.  Child elements of
 <faxdetectexit>, <send> and <exit>, allow events to be reported by
 the media server.
 Attributes:
    none

9.12. MSML Dialog Fax Send/Receive Package

9.12.1. <faxsend>

 The <faxsend> primitive provides the functionality of a calling fax
 terminal.  This typically means sending a set of pages.  However, it
 can also mean requesting the called terminal to send pages instead
 of, or in addition to, receiving pages.  The fax images to send are
 defined by the <sendobj> elements, described below.
 Requesting the called terminal to send pages happens when the
 <rxpoll> element is included as part of <faxsend>.  This element may
 be included in addition to, or instead of, the <sendobj> element.
 One <sendobj> (at a minimum) or <rxpoll> element must be present.
 When both are present, a media server will first send pages and will
 then poll the other terminal, requesting pages.
 Because fax is a distinct media type, the <faxsend> primitive is not
 expected to interact with other primitives.  Rather, it will interact
 using fax protocols with a remote fax terminal (or gateway) and will
 send requested status events to its invoking environment.  During fax
 operation, shadow variables are used to record the progress and
 parameters of the varying stages of fax operation.
 Status events are requested by including one or more status request
 elements.  These elements correspond to different stages or events in
 fax operation and cause predefined events to be sent to the invoking
 environment when they occur.  Since the only recipient of these
 events is expected to be a fax control agent, requests are simplified
 by associating a predefined namelist of shadow variables with each
 event.  This decision may be revisited to allowed tailored namelists
 based on further implementation experience.  Status requests apply
 both to sending and polling operation.
 Attributes:
    lclid: the identifier that a media server uses to identify itself.

Saleem, et al. Informational [Page 93] RFC 5707 Media Server Markup Language February 2010

    minspeed: the minimum acceptable speed to negotiate for the
    operation.
    maxspeed: the maximum speed to negotiate for the operation.  This
    attribute is primarily for testing purposes.
    ecm: specifies whether Error Correction Mode (ECM) is allowed to
    be used if supported by the remote terminal.  Defaults to "true".
 Events:
    terminate: terminates the fax send operation.
 Shadow Variables:
    fax.rmtid: the identifier of the remote fax terminal.
    fax.rate: the negotiated speed for the operation.
    fax.resolution: identifies the resolution of the image.  Both
    metric- and inch-based resolutions are defined.  Metric-based
    resolutions are 75x75, 150x150, 204x98, 204x196, 204x391, and
    408x391.  Inch-based resolutions are 200x200, 300x300, 400x400,
    and 600x600.
    fax.pagesize: identifies the negotiated page size.  Metric sizes
    are "A3", "A4", "A5", "A6", and "B4".  Inch-based page sizes are
    "Letter" and "Legal".
    fax.encoding: identifies the image encoding utilized.  Valid
    values are "MH", "R", "MMR", and "JPEG".
    fax.ecm: identifies whether ECM operation was used.
    fax.pagebadlines: the number of bad lines in a page.
    fax.objbadlines: the number of bad lines in an object.
    fax.opbadlines: the number of bad lines in an operation.
    fax.objuri: the objuri of the current object.
    fax.resendcount: the number of pages resent due to errors.
    fax.totalpages: the number of pages processed or stored.
    fax.totalobjects: the count of the objects used in the operation.

Saleem, et al. Informational [Page 94] RFC 5707 Media Server Markup Language February 2010

    fax.duration: the duration of the operation expressed as a
    duration in seconds and milliseconds (e.g., "23s250ms").
    fax.result: contains the reason that caused the fax operation to
    complete.  When the operation completes successfully, the value
    will be assigned "fax.success".  Other values include
    "fax.partial", "fax.nofax", "fax.remotedisconnect",
    "fax.uri.access.error", and "fax.invalid.startpage".
 The following sections describe the child elements of <faxsend>.

9.12.1.1. <sendobj>

 <sendobj> is used to define a fax transmission.  There MAY be
 multiple instances of the element, which will be transmitted in
 order.
 Attributes:
    objuri: a URI that points to the fax image that will be
    transmitted.  Mandatory.
    startpage: the first page of a multi-page objuri to send.
    pagecount: page count.

9.12.1.2. <hdrfooter>

 <hdrfooter> describes the header/footer that a media server MAY put
 on pages.  The header or footer may be defined as the content of the
 <format> child element.  The <format> element is only allowed if the
 type attribute has a value of "header" or "footer".
 Attributes:
    type: specifies whether a header or a footer should be put on
    pages and identifies the source of the header or footer.  The
    following enumerated values may be used:
       "header" indicates that the media server should put a header on
                pages using the contents of the <format> element.
       "nohdr"  indicates that there should be no header or footer.
       "footer" indicates that the media server should put a footer on
                pages using the contents of the <format> element.

Saleem, et al. Informational [Page 95] RFC 5707 Media Server Markup Language February 2010

    style: defines the style of insertion onto a fax page that a media
    server should use for the header or footer.  Valid styles are
    "append", "overlay", or "replace".
 <format> is a child of the <hdrfooter> element that defines the style
 format to be used for the header or footer.  It uses a "C" language
 style format statement (as shown below) to define the contents and
 layout of the header or footer.
    code    length   name              format
     %a       3     day of week       3-character abbreviation
     %d       2     date              01-31
     %m       2     month             01-12
     %y       2     year              00-99
     %Y       4     year              0000-9999
     %I       2     12 hour           01-12
     %H       2     24 hour           00-23
     %M       2     minute            00-59
     %S       2     seconds           00-59
     %p       2     AM/PM             AM or PM
     %P       2     page number       01-99
     %T       2     total pages       01-99
     %l       20    local ID (sender) 0-9, + or spaces
     %r       20    remote ID (rcvr)  0-9, + or spaces
     %%       1     percent           display % in header/ftr

9.12.1.3. <rxpoll>

 <rxpoll> provides the information necessary for a receive polling
 operation to occur.  The object(s) to be received are defined by one
 or more <rcvobj> elements.  The <rcvobj> is defined further under the
 child elements of <faxrcv>.  The <rxpoll> element MAY also include a
 description of the header/footer that a media server SHOULD put on
 received pages.  The <hdrfooter> element and its usage is described
 above.
 Attributes:
    rmtid: specifies the identifier of the remote fax terminal that is
    to be associated with a polling operation.  A media server MUST
    NOT execute a polling operation unless the value of rmtid matches
    that of the connected remote machine.  Mandatory.

Saleem, et al. Informational [Page 96] RFC 5707 Media Server Markup Language February 2010

9.12.1.4. <faxstart>

 The <faxstart> element requests that an event be sent when fax
 operation has begun.  When triggered, the following will be executed:
 <send target="source" event="fax.start"/>

9.12.1.5. <faxnegotiate>

 The <faxnegotiate> element requests that an event be sent when a
 negotiation has been completed.  Multiple events MAY be sent each
 time a Digital Command Signal (DCS) frame is sent or received.  When
 triggered, the following will be executed:
    <send target="source" event="fax.negotiate"
       namelist="fax.rmtid
          fax.rate
          fax.resolution
          fax.pagesize
          fax.encoding
          fax.ecm"/>

9.12.1.6. <faxpagedone>

 The <faxpagedone> element requests that an event be sent when a page
 has been sent or received.  When triggered, the following will be
 executed:
    <send target="source" event="fax.pagedone"
          namelist="fax.resolution
          fax.pagesize
          fax.encoding
          fax.pagebadlines
          fax.resendcount"/>

9.12.1.7. <faxobjectdone>

 The <faxobjectdone> element requests that an event be sent when an
 objuri has been completed.  When triggered, the following will be
 executed:
    <send target="source" event="fax.objectdone"
          namelist="fax.objuri
          fax.objbadlines
          fax.resendcount
          fax.totalpages
          fax.result"/>

Saleem, et al. Informational [Page 97] RFC 5707 Media Server Markup Language February 2010

9.12.1.8. <faxopcomplete>

 The <faxopcomplete> element requests that an event be sent when an
 operation has been completed.  When triggered, the following will be
 executed:
    <send target="source" event="fax.opcomplete"
          namelist="fax.totalpages
          fax.opbadlines
          fax.resendcount
          fax.totalobjects
          fax.duration
          fax.result"/>

9.12.1.9. <faxpollstarted>

 The <faxpollstarted> element requests that an event be sent when a
 polling operation has started.  When triggered, the following will be
 executed:
    <send target="source" event="fax.opcomplete"
          namelist="fax.rmtid
          fax.rate
          fax.resolution
          fax.pagesize
          fax.encoding
          fax.ecm"/>

9.12.2. <faxrcv>

 The <faxrcv> primitive provides the functionality of a called fax
 terminal.  Typically this type of operation is to receive pages.
 However, it can include sending pages instead of, or in addition to,
 receiving them.  The fax objects to receive are defined by the
 <rcvobj> elements, described below.
 A media server SHOULD send pages as a polled terminal when the
 <txpoll> element is included as part of <faxrcv>.  This element may
 be included in addition to, or instead of, the <rcvobj> element.  One
 <rcvobj> or <txpoll> element must be present.  When both are present,
 a media server SHOULD first receive pages and will then allow the
 other terminal to poll the media server, requesting pages.
 Because fax is a distinct media type, the <faxrcv> primitive is not
 expected to interact with other primitives.  Rather, it will interact
 using fax protocols with a remote fax terminal and will send

Saleem, et al. Informational [Page 98] RFC 5707 Media Server Markup Language February 2010

 requested status events to its invoking environment.  During fax
 operation, shadow variables are used to record the progress and
 parameters of the varying stages of fax operation.
 Status events are requested by including one or more status request
 elements.  These elements correspond to different stages or events in
 fax operation and cause predefined events to be sent to the invoking
 environment when they occur.  Since the only recipient of these
 events is expected to be a fax control agent, requests are simplified
 by associating a predefined namelist of shadow variables with each
 event.  This decision may be revisited to allowed tailored namelists
 based on further implementation experience.  Status requests apply
 both to receiving and polling operation.
 Attributes:
    id: an optional identifier that may be referenced elsewhere for
    sending events to the faxrecv primitive.
    lclid: the identifier that a media server uses to identify itself.
    ecm: specifies whether ECM mode is allowed to be used if supported
    by the remote terminal.  Defaults to "true".
 Events:
    terminate: terminates the fax reception operation.
 Shadow Variables:
    <faxrcv> supports the same set of shadow variables as <faxsend>
    The following sections describe the child elements of <faxrcv>.
    In addition to the elements defined below, <faxrcv> MAY also have
    the following child elements, which were defined under <faxsend>:
    o  <hdrfooter>
    o  <faxstart>
    o  <faxnegotiate>
    o  <faxpagedone>
    o  <faxobjectdone>
    o  <faxopcomplete>
    o  <faxpollstarted>
 Their meaning and usage are the same as previously defined.

Saleem, et al. Informational [Page 99] RFC 5707 Media Server Markup Language February 2010

9.12.2.1. <rcvobj>

 <rcvobj> is used to define fax objects that a media server will
 receive.  There may be multiple instances of the element, which will
 be used in order.
 Attributes:
    objuri: a URI that points to the location that a received image is
    to be stored.  Mandatory.
    maxpages: the maximum number of pages that will be stored in
    objuri.

9.12.2.2. <txpoll>

 <txpoll> provides the information for a polling operation to occur as
 part of a fax receive operation.  An object or multiple objects to be
 sent may be supplied by one or more <sendobj> elements.  In the event
 of multiple occurrences, a media server MUST select the <sendobj>
 element whose rmtid attribute matches that of the remote terminal.
 The <sendobj> element was defined previously as a child element of
 <faxsend>.  The <txpoll> element is extended with an rmtid attribute
 that specifies the identifier of the remote fax terminal and is used
 to select the specific <sendobj> to send.
 A media server SHOULD put a header/footer on transmitted pages based
 on any <hdrfooter> element included as part of <txpoll>.
 Attributes:
    rmtid: specifies the identifier of the remote fax terminal that is
    to be associated with a polling operation.  A media server MUST
    NOT execute a polling operation unless the value of rmtid matches
    that of the connected remote machine.  Mandatory.

10. MSML Audit Package

10.1. MSML Audit Core Package

 This section describes the MSML Audit Core Package that MAY be
 implemented to support auditing services.
 Audit requests and results may vary based on the information being
 audited.  The MSML Audit Core Package specifies the framework to send
 audit request, defines a state list, and builds audit results.  The

Saleem, et al. Informational [Page 100] RFC 5707 Media Server Markup Language February 2010

 additional audit packages define package specific state lists and
 associated audit result content.  The additional audit packages MUST
 be defined within the framework specified by the Audit Core Package.

10.1.1. <audit>

 The <audit> element is an optional child element of <msml>, which MAY
 be used by MSML clients to perform state auditing of current media
 resources allocated and in use by the media server.  The requested
 state information is returned in an MSML response.
 Attributes:
    queryid: the identifier of the MSML object being queried by the
    MSML client.  Mandatory.  Supported object types: conference or
    connection.  Wildcards are allowed.
    statelist: a list of one or more state parameters that are being
    queried.  Optional.  If not present, the media server SHOULD
    return the id of audited object only.  Each object type may
    contain a set of states.  If the "statelist" contains any state
    that does not match the audited object type, the request MUST be
    rejected.
    mark: in the case of an error, the value of the mark attribute
    from the last successfully executed element that included the mark
    attribute.
 State Parameters:
    The state parameter MUST be named using a dot-notation format
    "audit.X.a.b.c...", where X is the mandatory field that indicates
    the class name of the object (e.g., "conf" or "conn") and the
    "a.b.c..."  is the optional field used to describe the actual name
    of the state parameter in a hierarchical manner.  The wildcard "*"
    MAY be used as part of a state name; however, it MUST only be used
    in the last field of the dot-notation (e.g., "audit.conf.*" is
    valid, but "audit.conf.*.a" is invalid).  When a wildcard is used,
    it is equivalent to querying all the states below the specified
    level.  Each field (e.g., within "a.b.c...") will result in
    individual element names <a>, <b>, and <c> in the audit result to
    contain corresponding state value.  The parent/child relationship
    between these elements follows the hierarchy of the state name
    (i.e., <c> is child element of <b>, and <b> is child element of
    <a>).

Saleem, et al. Informational [Page 101] RFC 5707 Media Server Markup Language February 2010

10.1.2. <auditresult>

 The <auditresult> element is an optional child element of <result>,
 which MUST be used by the media server to return the audit result.  A
 specific instance of the <auditresult> element contains the state
 information of a single active object.  Therefore, if multiple
 objects are within the scope of the audit request, then one
 <auditresult> element per object MUST be present.  A zero occurrence
 of <auditresult> element indicates that there are no active resources
 within the scope of the audit request.
 Attributes:
    targetid: the identifier of a conference or connection.
    Mandatory.  Wildcard is not allowed.
 The <auditresult> may contain child element(s) that return additional
 state information, corresponding to the "statelist" attribute in the
 <audit> request.  The child element names correspond to the fields of
 the state parameter name (e.g., "a.b.c..."), following the same
 hierarchical structure.

10.2. MSML Audit Conference Package

 This section describes the MSML Audit Conference Package that MUST be
 implemented to support auditing of conference services.  The MSML
 Audit Conference Package follows the framework specified by the MSML
 Audit Core Package.  This package defines the state parameter list
 and audit result for conference auditing.

10.2.1. State Parameters

 All conference state parameter names MUST be prefixed by
 "audit.conf".
    confconfig: query the conferences general configuration.
    confconfig.audiomix: query the audio mixer's general configuration
    in the conference.
    confconfig.audiomix.asn: query the current ASN setting in the
    audio mixer.
    confconfig.audiomix.n-loudest: query the current n-loudest setting
    in the audio mixer.
    confconfig.videolayout: query the video layout's general
    configuration in the conference.

Saleem, et al. Informational [Page 102] RFC 5707 Media Server Markup Language February 2010

    confconfig.videolayout.root: query the root window setting of the
    video layout.
    confconfig.videolayout.selector: query the video stream selector
    setting of the video layout.
    confconfig.controller: query who is the conference controller.
    dialog: query the active dialog information on the conference.
    See MSML Audit Dialog Package for details.
    stream: query the active stream information on the conference.
    See MSML Audit Stream Package for details.

10.2.2. <auditresult>

 The <auditresult> attribute of "targetid" is required to indicate
 results for auditing a conference.
 The <auditresult> element may optionally contain the following child
 elements, returning additional conference state information, if
 corresponding states are queried and available.

10.2.2.1. confconfig

 The <confconfig> element is used to return the general configuration
 state(s) of a conference, using the following attributes.
 Attributes:
    deletewhen: as defined by <createconference> element in MSML
    Conference Core Package.
    term: as defined by <createconference> element in MSML Conference
    Core Package.

10.2.2.2. confconfig.audiomix

 The <audiomix> element contains the general audio mixer configuration
 using the following attributes.
 Attributes:
    id: as defined by <audiomix> element in MSML Conference Core
    Package.
    samplerate: as defined by <audiomix> element in MSML Conference
    Core Package.

Saleem, et al. Informational [Page 103] RFC 5707 Media Server Markup Language February 2010

10.2.2.3. confconfig.audiomix.asn

 The <asn> element contains the current ASN setting of an audio mixer,
 if ASN is enabled.  The state values are included in the following
 attributes.
 Attributes:
    ri: as defined by <asn> element in MSML Conference Core Package.
    asth: as defined by <asn> element in MSML Conference Core Package.

10.2.2.4. confconfig.audiomix.n-loudest

 The <n-loudest> element contains the current n-loudest setting of the
 audio mixer.  The state values are included in the following
 attributes.
 Attributes:
    n: as defined by <n-loudest> element in MSML Conference Core
    Package.

10.2.2.5. confconfig.videolayout

 The <videolayout> element contains the general video layout
 configuration using the following attributes.
 Attributes:
    id: as defined by <videolayout> in MSML Conference Core Package.
    type: as defined by <videolayout> in MSML Conference Core Package.

10.2.2.6. confconfig.videolayout.root

 The <root> element is used to contain root window settings.
 Attributes:
    size: as defined by <root> element in MSML Conference Core
    Package.
    backgroundcolor: as defined by <root> element in MSML Conference
    Core Package.
    Backgroundimage: as defined by <root> element in MSML Conference
    Core Package.

Saleem, et al. Informational [Page 104] RFC 5707 Media Server Markup Language February 2010

10.2.2.7. confconfig.videolayout.selector

 The <selector> element is used to contain selector settings.
 Attributes:
    id: as defined by <selector> element in MSML Conference Core
    Package.
    method: as defined by <selector> element in MSML Conference Core
    Package.
    status: as defined by <selector> element in MSML Conference Core
    Package.
    blankothers: as defined by <selector> element in MSML Conference
    Core Package.
    si: as defined by <selector> element in MSML Conference Core
    Package when selector method is "vas".
    speakersees: as defined by <selector> element in MSML Conference
    Core Package when selector method is "vas".

10.2.2.8. confconfig.controller

 The <controller> element is used to return the conference controller
 id in its content.  The conference controller is the SIP dialog that
 carries the <createconference> request.  The return value is the MSML
 connection id.

10.2.2.9. dialog

 If conference dialog state is queried, the audit result is returned
 using the <dialog> element as specified in the MSML Audit Dialog
 Package.

10.2.2.10. stream

 If conference stream state is queried, the audit result is returned
 using the <stream> element as specified in the MSML Audit Stream
 Package.

Saleem, et al. Informational [Page 105] RFC 5707 Media Server Markup Language February 2010

10.3. MSML Audit Connection Package

 This section describes the MSML Audit Connection Package that MAY be
 implemented to support auditing connection services.  The MSML Audit
 Connection Package follows the framework specified by the MSML Audit
 Core Package.  This package defines the state parameter list and
 audit result for connection auditing.

10.3.1. State Parameters

 Connection state parameter names are prefixed by "audit.conn".
    sipdialog: queries the identifier of the SIP dialog with which the
    connection is associated.
    sipdialog.localseq: queries one of the SIP dialog states - local
    sequence number.
    sipdialog.remoteseq: queries one of the SIP dialog states - remote
    sequence number.
    sipdialog.localURI: queries one of the SIP dialog states - local
    URI.
    sipdialog.remoteURI: queries one of the SIP dialog states - remote
    URI.
    sipdialog.remotetarget: queries one of the SIP dialog states -
    remote target.
    sipdialog.routeset: queries one of the SIP dialog states - route
    set.
    localsdp: queries the local SDP body of the connection.
    remotesdp: queries the remote SDP body of the connection.
    dialog: queries the active dialog information on the connection.
    See MSML Audit Dialog Package for details.
    stream: queries the active stream information on the connection.
    See MSML Audit Stream Package for details.

10.3.2. <auditresult>

 The <auditresult> attribute "targetid" MUST specify a connection
 identifier for a connection result.

Saleem, et al. Informational [Page 106] RFC 5707 Media Server Markup Language February 2010

 The <auditresult> element MAY contain the following child elements
 optionally to return additional connection state information if the
 corresponding states are queried and are available.

10.3.2.1. sipdialog

 The <sipdialog> element contains the associated SIP dialog
 information.  The SIP dialog ID information is returned using the
 following attributes.
    Attributes:
       callid: call-ID value as defined in [n1].  Mandatory.
       localtag: local-tag value as defined in [n1].  Mandatory.
       remotetag: remote-tag value as defined in [n1].  Mandatory.
 This element can contain the following child elements optionally to
 return additional SIP dialog state information to the client if the
 corresponding states are queried and available.

10.3.2.2. sipdialog.localseq

 The <localseq> element contains the local sequence number.  The local
 sequence number is one of the SIP dialog states as defined in [n1].

10.3.2.3. sipdialog.remoteseq

 The <remoteseq> element contains the remote sequence number.  The
 remote sequence number is one of the SIP dialog states as defined in
 [n1].

10.3.2.4. sipdialog.localuri

 The <localuri> element contains the local URI value.  The local URI
 is one of the SIP dialog states as defined in [n1].

10.3.2.5. sipdialog.remoteuri

 The <remoteuri> element contains the remote URI value.  The remote
 URI is one of the SIP dialog states as defined in [n1].

10.3.2.6. sipdialog.remotetarget

 The <remotetarget> element contains the remote target value.  The
 remote target is one of the SIP dialog states as defined in [n1].

Saleem, et al. Informational [Page 107] RFC 5707 Media Server Markup Language February 2010

10.3.2.7. sipdialog.routeset

 The <routeset> element contains the route-set value (an ordered list
 of URIs separated by comma).  The route set is one of the SIP dialog
 states as defined in [n1].

10.3.2.8. localsdp

 The <localsdp> element contains the local SDP body.

10.3.2.9. remotesdp

 The <remotesdp> element contains the remote SDP body.

10.3.2.10. dialog

 If the connection dialog state is queried, the audit result returns
 the queried information using the <dialog> element, as specified in
 the MSML Audit Dialog Package.

10.3.2.11. stream

 If the connection stream state is queried, the audit result returns
 the queried information using the <stream> element, as specified in
 the MSML Audit Stream Package.

10.4. MSML Audit Dialog Package

 This section describes the MSML Audit Dialog Package that MAY be
 implemented to support auditing dialogs.  The MSML Audit Dialog
 Package follows the framework specified by the MSML Audit Core
 Package.
 The MSML Audit Dialog Package must be used together with either the
 MSML Audit Conference Package or MSML Audit Connection Package, since
 the dialogs are applicable to conferences or connections.

10.4.1. State Parameters

 Dialog state parameter names are prefixed by "dialog".  Since this
 package must be used together with the MSML Audit Conference Package
 or MSML Audit Connection Package, the complete dialog state name must
 be prefixed by "audit.conf.dialog" or "audit.conn.dialog", depending
 on the context within which the dialog state is queried.
 dialog: queries the number of active dialog(s) running on the target
 (a conference or connection); basic dialog information will be
 returned.

Saleem, et al. Informational [Page 108] RFC 5707 Media Server Markup Language February 2010

 dialog.duration: queries the amount of time a dialog has been
 running.
 dialog.primitive: queries the media primitive currently being
 executed by the dialog.
 dialog.controller: queries the dialog controller.

10.4.2. <dialog>

 The <dialog> element is a child element of <auditresult>, which
 contains the active dialog information on the target identified by
 the attribute "targetid" of the <audioresult> element.
 Basic dialog information is returned using the following attributes.
 Attributes:
    src: as defined by the <dialogstart> element in the MSML Dialog
    Core Package.
    type: as defined by the <dialogstart> element in the MSML Dialog
    Core Package.  Mandatory.
    name: as defined by the <dialogstart> element in the MSML Dialog
    Core Package.  Mandatory.
 This element may contain the following child elements optionally to
 return additional dialog information if the corresponding state
 parameter has been queried and the state value is available.

10.4.2.1. <duration>

 The <duration> element returns the duration that a dialog has been
 running on the specified target.  The duration value is included in
 the element content.  It is a positive integer value (in unit of
 seconds).

10.4.2.2. <primitive>

 The <primitive> element returns the currently active media primitive
 in its content.  The active media primitive is the primitive that is
 currently being executed.  Possible return values are play, dtmf,
 collect, dtmfgen, tonegen, record, or none.

Saleem, et al. Informational [Page 109] RFC 5707 Media Server Markup Language February 2010

10.4.2.3. <controller>

 The <controller> element returns the dialog controller id in its
 content.  The dialog controller is the SIP dialog that carries the
 <dialogstart> request.  The returned value is the MSML connection id.

10.5. MSML Audit Stream Package

 This section describes the MSML Audit Stream Package that MAY be
 implemented to support auditing stream.  The MSML Audit Stream
 Package follows the framework specified by the MSML Audit Core
 Package.
 The MSML Audit Stream Package MUST be used together with either the
 MSML Audit Conference Package or the MSML Audit Connection Package,
 since the stream is applicable between conferences, between
 connections, or between conferences and connections.

10.5.1. State Parameters

 Stream state parameter names are prefixed by "stream".  Since this
 package must be used together with the MSML Audit Conference Package
 or MSML Audit Connection Package, the complete stream state name must
 be prefixed by "audit.conf.stream" or "audit.conn.stream", depending
 on the context within which the stream state is queried.
 stream: queries the number of active streams created on the audited
 object; basic stream information will be returned.
 stream.clamp: queries the clamping status.
 stream.gain: queries the gain control information.
 stream.visual: queries the visual setting.

10.5.2. <stream>

 The <stream> element is a child element of <auditresult> and contains
 the active stream information on the target identified by the
 attribute "targetid" of the <audioresult> element.
 Basic stream information is returned using the following attributes.
 Attributes:
    joinwith: an identifier of either a connection or a conference
    with which the audited object is joined.  Mandatory.  Wildcard is
    not allowed.

Saleem, et al. Informational [Page 110] RFC 5707 Media Server Markup Language February 2010

    media: as defined by the <stream> element in the MSML Conference
    Core Package.  Mandatory.
    dir: direction of stream, from audited target perspective, "from"
    or "to".  Mandatory.
    compressed: as defined by the <stream> element in the MSML
    Conference Core Package.
    display: as defined by the <stream> element in the MSML Conference
    Core Package.
    override: as defined by the <stream> element in the MSML
    Conference Core Package.
    preferred: as defined by the <stream> element in the MSML
    Conference Core Package.
 This element MAY contain the following child elements that optionally
 return additional stream information, if the corresponding state
 parameter is queried and the state value is available.

10.5.2.1. <clamp>

 The <clamp> element is included if stream clamping is active.  The
 currently active clamping state values are returned using the
 attributes as defined by the <clamp> element in the MSML Conference
 Core Package.

10.5.2.2. <gain>

 The <gain> element is included if stream gain is active.  The current
 gain control state values are returned using the attributes as
 defined by the <gain> element in the MSML Conference Core Package.

10.5.2.3. <visual>

 The <visual> element is included if stream visual display is active.
 The current visual display settings are returned using the attributes
 as defined by the <visual> element in the MSML Conference Core
 Package.

11. Response Codes

 Response codes are used to indicate reasons for failures as well as
 completion status.  The appropriate code and description must be
 passed to the invoking environment on failure.

Saleem, et al. Informational [Page 111] RFC 5707 Media Server Markup Language February 2010

 The response codes defined in this section are returned as the value
 of the response attribute to the <result> element.  Some values may
 also be returned as part of a namelist to an "msml.dialog.exit" event
 generated when an executing MSML dialog fails.
 Informational (1xx)
    Reserved for future use
 Success (200)
    200  OK
 Request Error (4xx)
    400  Bad Request
    401  Unknown Element
    402  Unsupported Element
    403  Missing mandatory element content
    404  Forbidden element content
    405  Invalid element content
    406  Unknown attribute
    407  Attribute not supported
    408  Missing mandatory attribute
    409  Forbidden attribute is present
    410  Invalid attribute value
    420  Unsupported media description language
    421  Unknown media description language
    422  Ambiguous request (both URI and inline description)
    423  External document fetch error
    424  Syntax error in foreign language
    425  Semantic error in foreign language
    426  Unknown error executing foreign language
    430  Object does not exist
    431  Object instance name already used
    432  Conference name already in use
    433  reserved
    434  External document fetch error
    440  Cannot join objects of the specified class
    441  Objects have incompatible media types
    442  reserved
    443  reserved
    444  Number of media inputs exceeded

Saleem, et al. Informational [Page 112] RFC 5707 Media Server Markup Language February 2010

    450  Objects have incompatible media formats
    451  Incompatible media stream format
 Server Error (5xx)
    500  Internal media server error
    503  Service Unavailable
    510  Not in service
    511  Service Unavailable
    520  No resource to fulfill request
    521  Internal limit exceeded

12. MSML Conference Examples

 These examples focus on the MSML Conference Core Package used by a
 control agent (CA) to control services on a media server (MS).  They
 show the relationship between SIP signaling to establish media
 sessions and MSML service control commands.  For brevity, only the
 content of MSML messages is shown.  The examples assumes that the CA
 and MS use the IPv4 address and UDP port number of the audio stream
 (on the MS) to identify the MSML connection.

12.1. Establishing a Dial-In Conference

    UA                   Control Agent             Media Server
    |                         |                           |
    |                         |        INVITE F1          |
    |                         |-------------------------->|
    |                         |           200 F2          |
    |                         |<--------------------------|
    |                         |           ACK F3          |
    |                         |-------------------------->|
    |                         |                           |
    |                         |     createconference> F4  |
    |                         |-------------------------->|
    |                         |           200 F5          |
    |                         |<--------------------------|
    |    INVITE (SDP UA) F6   |                           |
    |------------------------>|                           |
    |                         |      INVITE (SDP UA) F7   |
    |                         |-------------------------->|
    |                         |        200 (SDP MS) F8    |
    |                         |<--------------------------|
    |                         |           ACK F9          |
    |                         |-------------------------->|
    |     200 (SDP MS) F10    |                           |
    |<------------------------|                           |
    |        ACK F11          |                           |

Saleem, et al. Informational [Page 113] RFC 5707 Media Server Markup Language February 2010

    |------------------------>|                           |
    |                         |     <dialogstart> F12     |
    |                         |-------------------------->|
    |                         |           200 F13         |
    |                         |<--------------------------|
    |                         |    HTTP interactions F14  |
    |                         |<------------------------->|
    |                         |  <event>(dialog.exit) F15 |
    |                         |<--------------------------|
    |                         |         <join> F16        |
    |                         |-------------------------->|
    |                         |           200 F17         |
    |                         |<--------------------------|
    |         ...             |            ...            |
    |                         |                           |
    |                         |     <dialogstart> F18     |
    |                         |-------------------------->|
    |                         |           200 F19         |
    |                         |-------------------------->|
    |                         |    HTTP interactions F20  |
    |                         |<--------------------------|
    |                         |  <event>(dialog.exit) F21 |
    |                         |-------------------------->|
    |         ...             |            ...            |
    |                         |                           |
 Steps 1-3: establish an MSML control channel for the conference.
 Alternatively, a control channel could already have been established
 that was used for all CA/MS interactions.  A control channel per
 conference is only one possible model.  Currently, MSML uses SIP INFO
 requests and responses on this SIP dialog.  There is a proposal to
 use this message exchange to establish a TCP channel for MSML similar
 to the approach used for the Media Resource Control Protocol v2
 (MRCPv2).  This approach would require that a request identifier be
 added to the <msml> element to correlate requests and responses.
 This currently relies on the SIP INFO request and response for this
 property.  MSML messages are shown without specifying the transport
 in this example, but it assumes a request/response correlation based
 on transport messages.
 Step 4: create a conference that will mix the loudest two speakers
 and report those speakers to the control agent every 10 seconds.  The
 media server will automatically terminate remaining media sessions
 and delete the conference and associated resources and when the
 control channel is terminated.

Saleem, et al. Informational [Page 114] RFC 5707 Media Server Markup Language February 2010

    <msml version="1.1">
       <createconference name="exampleConf" deletewhen="nocontrol">
           <audiomix>
              <n-loudest n="3"/>
              <asn ri="10s"/>
           </audiomix>
       </createconference>
    </msml>
 Step 5: conference created successfully
    <msml version="1.1">
       <result response="200"/>
    </msml>
 Steps 6-11: standard 3PCC establishment of a user-initiated media
 session to a media server.  This is the equivalent of a dial-in
 conference participant.  The "To:" header returned by the MS in the
 200 response of Step F8 was:
 To: <sip:msml@ms.example.com>;tag=jd87dfg4h
 Step 12: request an initial dialog with the participant to prompt for
 their name, desired conference, etc.  The dialog completes by
 informing the participant that they are joining the conference.  If
 this was not the first participant, the dialog could also announce
 the other participants.
    <msml version="1.1">
       <dialogstart target="conn:jd87dfg4h" name="12345"
           type="application/vxml+xml"
           src="http://server.example.com/scripts/initial.vxml"/>
    </msml>
 Step 13: dialog started successfully.  The dialog identifier is
 returned.
    <msml version="1.1">
       <result response="200"/>
       <dialogid>conn:jd87dfg4h/dialog:12345</dialogid>
    </msml>
 Step 14: sequence of HTTP VoiceXML dialog interactions.
 Step 15: the VoiceXML browser exits (but does not disconnect).  If a
 namelist had been specified within the VoiceXML <exit> element, it
 would have been included in the <event> sent to the CA.

Saleem, et al. Informational [Page 115] RFC 5707 Media Server Markup Language February 2010

    <msml version="1.1">
       <event name="msml.dialog.exit"
              id="conn:jd87dfg4h/dialog:12345"/>
    </msml>
 Step 16: join the participant to the conference and have the volume
 of their contributing audio automatically adjusted to a target level
 of -20 dBm0.
    <msml version="1.1">
       <join id1="conn:jd87dfg4h" id2="conf:exampleConf">
          <stream media="audio" dir="from-id1">
              <gain agc="true" tgtlvl="-20"/>
          </stream>
          <stream media="audio" dir="to-id1"/>
    </msml>
 Step 17: successfully joined to conference
    <msml version="1.1">
       <result response="200"/>
    </msml>
 Steps 6 through 17 are repeated for the second participant.
 Step 18: play a join tone or message announcing the new participant
 to the conference.
    <msml version="1.1">
       <dialogstart target="conf:exampleConf"
           type="application/vxml+xml"
           src="http://server.example.com/scripts/joinmsg.vxml"/>
    </msml>
 Step 19: dialog started successfully.  The dialog identifier is
 returned.  The media server assigned a unique identifier since name
 attribute was not specified in <dialogstart>.
    <msml version="1.1">
       <result response="200"/>
       <dialogid>conf:ExampleConf/dialog:j6fs8745</dialogid>
    </msml>
 Step 20: HTTP VoiceXML dialog interaction(s).

Saleem, et al. Informational [Page 116] RFC 5707 Media Server Markup Language February 2010

 Step 21: the VoiceXML browser exits.
    <msml version="1.1">
       <event name="msml.dialog.exit"
              id="conf:ExampleConf/dialog:j6fs8745"/>
    </msml>
 Steps 6 through 21 are repeated for the third and subsequent
 participants.

12.2. Example of a Sidebar Audio Conference

 This example assumes that a conference has already been established
 as in the previous example.  It creates a sidebar conference that
 hears the main conference as a whisper.  Three participants are moved
 to the sidebar.  After some period of time, the sidebar participants
 are returned to the main conference and the sidebar is deleted.
 Step 1: the sidebar conference is created.  It is joined half-duplex
 to the main conference and a manual gain object is inserted in the
 media stream.  Three participants are then moved from the main
 conference to the sidebar.  Although not shown, a CA could include
 the "mark" attribute in each element to allow recovery in the event
 of a mid- transaction error.
    <msml version="1.1">
       <createconference name="sidebarConf"
                         deletewhen="nomedia">
           <audiomix/>
       </createconference>
       <join id1="conf:sidebarConf" id2="conf:exampleConf">
           <stream media="audio" dir="to-id1">
               <gain amt="-20"/>
           </stream>
       </join>
       <unjoin id1="conn:gs5s4-1" id2="conf:exampleConf"/>
       <join id1="conn:gs5s4-1" id2="conf:sidebarConf"/>
       <unjoin id1="conn:hd764gr9-2" id2="conf:exampleConf"/>
       <join id1="conn:hd764gr9-2" id2="conf:sidebarConf"/>
       <unjoin id1="conn:h37frdvgs65-3" id2="conf:exampleConf"/>
       <join id1="conn:h37frdvgs65-3" id2="conf:sidebarConf"/>
    </msml>

Saleem, et al. Informational [Page 117] RFC 5707 Media Server Markup Language February 2010

 Step 2: sidebar conference created successfully and participants
 joined.
    <msml version="1.1">
       <result response="200"/>
    </msml>
 Step 3: once the sidebar conference has completed, the participants
 are rejoined to the main conference.  The sidebar is destroyed
 automatically by the MS when the last media stream is removed as
 specified when the sidebar conference was created.
    <msml version="1.1">
       <unjoin id1="conn:gs5s4-1" id2="conf:sidebarConf"/>
       <join id1="conn:gs5s4-1" id2="conf:exampleConf"/>
       <unjoin id1="conn:hd764gr9-2" id2="conf:sidebarConf"/>
       <join id1="conn:hd764gr9-2" id2="conf:exampleConf"/>
       <unjoin id1="conn:h37frdvgs65-3" id2="conf:sidebarConf"/>
       <join id1="conn:h37frdvgs65-3" id2="conf:exampleConf"/>
    </msml>
 Step 4: participants successfully moved to main conference and
 sidebar destroyed.
    <msml version="1.1">
       <result response="200"/>
    </msml>

12.3. Example of Removing a Conference

 This example assumes a conference created similar to the first
 example where there is an MSML control channel specific to the
 conference and the conference has been configured to be deleted when
 that channel is removed (using SIP).
 Steps 1-2: the CA signals BYE for the SIP dialog used to establish
 the conference control channel.
 Steps 3-6: the MS initiates terminating the media sessions for each
 participant remaining in the conference.
 The MS deletes the conference and removes all resources when the last
 participant has been removed.

12.4. Example of Modifying Video Layout

 Assume that a conference named "example" is created using the
 following mixer descriptions.

Saleem, et al. Informational [Page 118] RFC 5707 Media Server Markup Language February 2010

    +---+---+
    | 1 | 2 |
    +---+---+
    | 3 | 4 |
    +---+---+
    <createconference name="quad-split">
       <audiomix>
          <n-loudest n="3"/>
          <asn ri="10s"/>
       </audiomix>
       <videolayout>
          <root size="CIF" background="white" />
          <selector id="default" method="vas" si="500ms">
             <region id="1" left="0" top="0" relativesize="1/4"/>
          </selector>
          <region id="2" left="50%" top="0" relativesize="1/4"/>
          <region id="3" left="0%" top="50%" relativesize="1/4">
          <region id="4" left="50%" top="50%" relativesize="1/4"/>
       </videolayout>
    </createconference>
    The following would change the size of the video window to QCIF
    and the background color to the default "black".
    <modifyconference id="conf:example">
       <videolayout>
          <root size="4CIF"/>
       </videolayout>
    </modifyconference>
 The relative location of the regions does not change.  However, the
 sizes of the regions do change because they are relative to the size
 of the root window.  The result is a layout that looks identical but
 half the size.
 The following would freeze the video displayed in region "2" without
 affecting any other attributes of that region.
    <modifyconference id="conf:example">
       <videolayout>
          <region id="2" left="50%" top="0" relativesize="1/4"
                         freeze="true"/>
       </videolayout>
    </modifyconference>

Saleem, et al. Informational [Page 119] RFC 5707 Media Server Markup Language February 2010

13. MSML Dialog Examples

 These examples focus on the MSML Dialog Base Package and the MSML
 Dialog Group Package.

13.1. Announcement

 The following is a simple announcement scenario.  Two recorded audio
 files are played in sequence followed by generated speech followed by
 a variable.  The results are reported once media generation
 completes.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <dialogstart target="conn:12345" name="12345">
          <play>
             <audio uri="file://clip1.wav"/>
             <audio uri="http://host1/clip2.wav"/>
             <tts uri="http://host2/text.ssml"/>
             <var type="date" subtype="mdy" value="20030601"/>
          </play>
          <send target="source" event="done" namelist="play.amt
                                             play.end"/>
       </dialogstart>
    </msml>

13.2. Voice Mail Retrieval

 Below is an example that shows a simple voice mail retrieval
 operation consisting of playing a message and allowing the user to
 pause and resume play using '5' to toggle the state.  The operation
 would terminate when the play completed or the user entered '#'.
 During the play, the user can advance forward and backward through
 the message as well as rewinding to the beginning.

Saleem, et al. Informational [Page 120] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
      <dialogstart target="conn:12345" name="12345">
       <group topology="parallel">
          <play>
             <audio uri="file://message.wav"/>
             <playexit>
                <send target="group" event="terminate"/>
             </playexit>
          </play>
          <dtmf iterate="forever">
             <pattern digits="5">
                <send target="play" event="toggle-state"/>
             </pattern>
             <pattern digits="6">
                <send target="play" event="forward"/>
             </pattern>
             <pattern digits="7">
                <send target="play" event="backward"/>
             </pattern>
             <pattern digits="8">
                <send target="play" event="restart"/>
             </pattern>
             <pattern digits="#">
                <send target="play" event="terminate"/>
             </pattern>
          </dtmf>
       </group>
     </dialogstart>
    </msml>

Saleem, et al. Informational [Page 121] RFC 5707 Media Server Markup Language February 2010

13.3. Play and Record

 A more complex example is a play and record operation.  This sources
 and sinks media and uses voice activity DTMF detection and
 recognition to influence behavior.  Any DTMF input or voice activity
 will barge the play and cause the record to begin.  However, if the
 prompt was barged with a DTMF digit of '#', the record terminates
 without starting.  When the play terminates, it send a starttimer
 event to the VAD to allow it to recognize an initial silence
 condition.  The recording will be terminated (without starting) when
 the VAD detects an initial 3 seconds of silence.
 Once resumed (based upon voice detection), the recording may be
 terminated under several conditions.  It will terminate after 5
 seconds of silence or after 60 seconds elapses.  It will also
 terminate if a '#' key is recognized.  Every aspect of this behavior
 can be modified by changing what is recognized and the events that
 are sent.  The following example uses the MSML Dialog Group Package.

Saleem, et al. Informational [Page 122] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml  version="1.1">
     <dialogstart target="conn:12345" name="12345">
       <group topology="parallel">
          <play>
             <audio uri="file://prompt.wav"/>
             <playexit>
                <send target="vad" event="starttimer"/>
             </playexit>
          </play>
          <dtmf>
             <pattern digits="#">
                <send target="record" event="terminate.termkey"/>
             </pattern>
             <detect>
                <send target="play" event="terminate"/>
             </detect>
          </dtmf>
          <vad>
             <voice len="10ms">
                <send target="play" event="terminate"/>
                <send target="record" event="resume"/>
             </voice>
             <silence len="3s">
                <send target="record" event="nospeech"/>
             </silence>
             <tsilence len="5s">
                <send target="record" event="terminate.finalsilence"/>
             </tsilence>
          </vad>
          <record initial="suspend" maxtime="60s"
                  dest="file://record.wav" format="g729">
             <recordexit>
                <send target="group" event="terminate"/>
             </recordexit>
          </record>
          <groupexit>
             <send target="source" event="done"
                   namelist="record.len record.end"/>
          </groupexit>
       </group>
     </dialogstart>
    </msml>

Saleem, et al. Informational [Page 123] RFC 5707 Media Server Markup Language February 2010

 The following implements the same functionality, as described above,
 in using the MSML Dialog Base Package, using the <record> composite
 mechanism for the play and record operation.
 <?xml version="1.0" encoding="UTF-8"?>
 <msml  version="1.1">
  <dialogstart target="conn:12345" name="12345">
    <record prespeech="3s" postspeech="5s" maxtime="60s" termkey="#"
               dest="file://record.wav" format="g729">
       <play barge="true">
          <audio uri="file://prompt.wav"/>
       </play>
       <recordexit>
          <send target="source" event="done"
                namelist="record.len record.end"/>
       </recordexit>
    </record>
  </dialogstart>
 </msml>

Saleem, et al. Informational [Page 124] RFC 5707 Media Server Markup Language February 2010

13.4. Speech Recognition

 The following simple example requests that a user speak the name of a
 city and returns the result.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
     <dialogstart target="conn:12345" name="12345">
       <group topology="parallel">
          <play>
             <audio uri="file://prompt.wav"/>
          </play>
          <speech>
             <grammar version="1.0">
                <rule id="city" scope="public">
                   <item>
                      <one-of>
                         <item>vancouver</item>
                         <item>new york</item>
                         <item>london</item>
                      </one-of>
                   </item>
                </rule>
                <match>
                   <send target="group" event="terminate"/>
                </match>
             </grammar>
             <noinput>
                <send target="group" event="terminate"/>
             </noinput>
             <nomatch>
                <send target="group" event="terminate"/>
             </nomatch>
          </speech>
          <groupexit>
             <send target="source" event="done"
                           namelist="speech.end speech.results"/>
          </groupexit>
       </group>
     </dialogstart>
    </msml>

13.5. Play and Collect

 This example prompts a user to enter 4 DTMF digits terminated by the
 '#' key (represented by "xxxx#" below).  The prompt will be barged
 and the user has 10 seconds to begin entering input or no input will
 be indicated.

Saleem, et al. Informational [Page 125] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
     <dialogstart target="conn:12345" name="12345">
       <group topology="parallel">
          <play>
             <audio uri="file://prompt.wav"/>
             <playexit>
                <send target="dtmf" event="starttimer"/>
             </playexit>
          </play>
          <dtmf fdt="10s" idt="16s">
             <pattern digits="xxxx#">
                <send target="group" event="terminate"/>
             </pattern>
             <detect>
                <send target="play" event="terminate"/>
             </detect>
             <noinput>
                <send target="group" event="terminate"/>
             </noinput>
             <nomatch>
                <send target="group" event="terminate"/>
             </nomatch>
          </dtmf>
          <groupexit>
             <send target="source" event="done"
                   namelist="dtmf.digits dtmf.end"/>
          </groupexit>
       </group>
     </dialogstart>
    </msml>

Saleem, et al. Informational [Page 126] RFC 5707 Media Server Markup Language February 2010

 The following implements the same functionality, as described above,
 using the MSML Dialog Base Package, using the <collect> composite
 mechanism for the play and collect operation.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
     <dialogstart target="conn:12345" name="12345">
       <collect fdt="10s" idt="16s">
          <play barge="true">
             <audio uri="file://prompt.wav"/>
          </play>
          <pattern digits="xxxx#">
             <send target="source" event="done"
                   namelist="dtmf.digits dtmf.end"/>
          </pattern>
          <noinput>
             <send target="source" event="done"
                   namelist="dtmf.end"/>
          </noinput>
          <nomatch>
             <send target="source" event="done"
                   namelist="dtmf.end"/>
          </nomatch>
       </collect>
     </dialogstart>
    </msml>

Saleem, et al. Informational [Page 127] RFC 5707 Media Server Markup Language February 2010

13.6. User Controlled Gain

 This shows an example of nesting groups to create an arbitrary full-
 duplex media control.  DTMF is detected on media flowing in one
 direction and used to adjust the gain applied to media flowing in the
 opposite direction.  Additionally, the stream that is used to detect
 DTMF has DTMF removed and its gain automatically adjusted before
 leaving the group.  This widget could be used between a conference
 participant and a conference mixer.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml  version="1.0">
     <dialogstart target="conn:12345" name="12345">
       <group topology="fullduplex">
          <group topology="parallel">
             <dtmf>
                <pattern digits="1" iterate="forever">
                   <send target="gain" event="louder"/>
                </pattern>
                <pattern digits="2" iterate="forever">
                   <send target="gain" event="softer"/>
                </pattern>
             </dtmf>
             <group topology="serial">
                <clamp/>
                <agc tgtlvl="0"/>
             </group>
          </group>
          <gain amt="0" incr="5"/>
       </group>
     </dialogstart>
    </msml>

14. MSML Audit Examples

 The following examples describe the MSML Audit Conference Package and
 the MSML Audit Connection Package, and their use together with the
 MSML Audit Dialog Package or/and the MSML Audit Stream Package.

14.1. Audit All Conferences

 This example describes an audit of all active conferences on the
 media server, querying the conference configurations.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <audit queryid="conf:*" statelist="audit.conf.confconfig.*"/>
    </msml>

Saleem, et al. Informational [Page 128] RFC 5707 Media Server Markup Language February 2010

 The following result assumes two conferences currently allocated by
 the media server.  Conference "conf:1" contains both an audio mixer
 (with ASN enabled) and a video layout (vas) created, while conference
 "conf:2" contains only an audio mixer created with ASN disabled.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <result response="200">
          <auditresult targetid="conf:1">
             <confconfig deletewhen="nocontrol" term="true">
                <audiomix id="audiomix1">
                   <asn ri="5s"/>
                   <n-loudest n="16"/>
                </audiomix>
                  <videolayout id="videolayout1"
                               type="text/msml-basic-layout">
                     <selector id="selector1" method="vas" si="5s"
                               speakersees="current">
                        <root size="CIF"/>
                     </selector>
                  </videolayout>
                <controller>conn:1234</controller>
             </confconfig>
          </auditresult>
          <auditresult targetid="conf:2">
             <confconfig deletewhen="nomedia" term="true">
                <audiomix id="audiomix2">
                   <n-loudest n="1"/>
                </audiomix>
                <controller>conn:1234</controller>
             </confconfig>
          </auditresult>
       </result>
    </msml>

14.2. Audit Conference Dialogs

 This example describes an audit of active dialogs on a specific
 conference.  The request queries all available dialog states.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <audit queryid="conf:1" statelist="audit.conf.dialog.*"/>
    </msml>
 The example result assumes a single dialog running on conference
 "conf:1", which has been running for 60 seconds, and the dialog is
 currently executing a record operation.

Saleem, et al. Informational [Page 129] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <result response="200">
          <auditresult targetid="conf:1">
             <dialog name="sample">
                <duration>60</duration>
                <primitive>record</primitive>
                <controller>conn:1234</controller>
             </dialog>
          </auditresult>
       </result>
    </msml>

14.3. Audit Conference Streams

 This example request describes an audit of active streams on a
 specific conference.  The request queries all available stream
 states.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <audit queryid="conf:1" statelist="audit.conf.stream.*"/>
    </msml>
 The example result assumes three audio participants in the
 conference.  Connection "conn:1234" is a talk-listen participant with
 both clamp and gain control enabled.  Connection "conn:1235" is a
 talk-only participant.  Connection "conn:1236" is a listen-only
 participant with automatic gain control enabled.

Saleem, et al. Informational [Page 130] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <result response="200">
          <auditresult targetid="conf:1">
             <stream joinwith="conn:1234" media="audio" dir="to">
                <clamp dtmf="true" tone="false"/>
                <gain amt="-10"/>
             </stream>
             <stream joinwith="conn:1234" media="audio" dir="from">
                <gain amt="10"/>
             </stream>
             <stream joinwith="conn:1235" media="audio" dir="to">
             </stream>
             <stream joinwith="conn:1236" media="audio" dir="from">
                <gain agc="true" tgtlvl="0" maxgain="10"/>
             </stream>
          </auditresult>
       </result>
    </msml>

14.4. Audit All Connections

 This example request describes an audit of all active connections on
 the media server.  No additional state is queried.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <audit queryid="conn:*"/>
    </msml>
 The example result assumes five connections currently allocated by
 the media server.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <result response="200">
          <auditresult targetid="conn:1230"/>
          <auditresult targetid="conn:1231"/>
          <auditresult targetid="conn:1232"/>
          <auditresult targetid="conn:1233"/>
          <auditresult targetid="conn:1234"/>
       </result>
    </msml>

14.5. Audit Connection Dialogs

 This example request describes an audit of active dialogs on a
 specific connection.  No additional dialog state is queried.

Saleem, et al. Informational [Page 131] RFC 5707 Media Server Markup Language February 2010

    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <audit queryid="conn:1234" statelist="audit.conn.dialog"/>
    </msml>
 The example result assumes three dialogs running on the connection.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <result response="200">
          <auditresult targetid="conn:1234">
             <dialog name="sample1"/>
             <dialog name="sample2"/>
             <dialog name="sample3"/>
          </auditresult>
       </result>
    </msml>

14.6. Audit Connection Streams

 This example request describes an audit of active streams on a
 specific connection.  No additional stream state is queried.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <audit queryid="conn:1234" statelist="audit.conn.stream"/>
    </msml>
 The example result assumes three audio streams created between target
 connection and other MSML objects, one of which is a bidirectional
 stream between target connection and a conference, and two are
 unidirectional streams between two other connections.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <result response="200">
          <auditresult targetid="conn:1234">
             <stream joinwith="conf:1" media="audio" dir="to"/>
             <stream joinwith="conf:1" media="audio" dir="from"/>
             <stream joinwith="conn:1235" media="audio" dir="to"/>
             <stream joinwith="conn:1236" media="audio" dir="from"/>
          </auditresult>
       </result>
    </msml>

Saleem, et al. Informational [Page 132] RFC 5707 Media Server Markup Language February 2010

14.7. Audit Connection with Selective States

 This example describes an audit of a specific connection, querying
 associated SIP dialog ID and SDP info.
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <audit queryid="conn:1234" statelist="audit.conn.sipdialog
          audit.conn.localsdp audit.conn.remotesdp"/>
    </msml>
    <?xml version="1.0" encoding="UTF-8"?>
    <msml version="1.1">
       <result response="200">
          <auditresult targetid="conn:1234">
             <sipdialog callid="ABCD@10.0.0.10:5060"
                        localtag="sdfjsiodf"
                        remotetag="zvnmviuhd8"/>
             <localsdp>
                v=0
                o=- 31691 31691 IN IP4 ms5mpc11.lab.radisys.com
                s=media server session
                t=0 0
                m=audio 33794 RTP/AVP 0
                c=IN IP4 10.3.5.111
                a=rtpmap:0 PCMU/8000
                a=sendrecv
                m=video 32770 RTP/AVP 34
                c=IN IP4 10.3.5.11
                b=AS:48
                a=rtpmap:34 H263/90000
                a=fmtp:34 CIF=1
                a=sendrecv
             </localsdp>
             <remotesdp>
                v=0
                o=- 12345 12345 IN IP4 10.0.0.88
                s=RadiSys SIP Media Server session
                t=0 0
                c=IN IP4 10.0.0.126
                b=AS:128
                m=audio 10000 RTP/AVP 0
                a=rtpmap:0 PCMU/8000
                a=ptime:20
                a=sendrecv
                m=video 10002 RTP/AVP 34
                a=rtpmap:34 H263/90000
                a=fmtp:34 CIF=1

Saleem, et al. Informational [Page 133] RFC 5707 Media Server Markup Language February 2010

                a=sendrecv
             </remotesdp>
          </auditresult>
       </result>
    </msml>

15. Future Work

 The following capabilities may be added in future versions of this
 document:
 o Ability for MSML clients to audit or query the media server for
   supported set of MSML packages and profiles.
 o Ability to version MSML packages and profiles and naming scheme for
   MSML extension packages.

16. XML Schema

 MSML specification consists of a set of XML schemas, all of which may
 be used together or any sub-set of the schemas may be used for each
 MSML package.  The following sections define a complete set of
 schemas covering all MSML packages.
 Each package contains a single schema file, <package-name>-
 datatypes.xsd.  This schema file can be included by its extended
 package(s).  Every package optionally contains another schema file,
 <package_name>.xsd, which can be used directly to build or validate
 MSML scripts for a given package.
 The complete MSML schema (msml.xsd) includes all the individual MSML
 packages.
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">
  <xs:include schemaLocation="msml-core-datatypes.xsd"/>
  <xs:include schemaLocation="msml-conf-core-datatypes.xsd"/>
  <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/>
  <xs:include schemaLocation="msml-dialog-base-datatypes.xsd"/>
  <xs:include schemaLocation="msml-dialog-transform-datatypes.xsd"/>
  <xs:include schemaLocation="msml-dialog-group-datatypes.xsd"/>
  <xs:include schemaLocation="msml-dialog-speech-datatypes.xsd"/>
  <xs:include schemaLocation="msml-dialog-fax-detect-datatypes.xsd"/>
  <xs:include schemaLocation="msml-dialog-fax-sendrecv-
              datatypes.xsd"/>
  <xs:include schemaLocation="msml-audit-core-datatypes.xsd"/>

Saleem, et al. Informational [Page 134] RFC 5707 Media Server Markup Language February 2010

  <xs:include schemaLocation="msml-audit-conf-datatypes.xsd"/>
  <xs:include schemaLocation="msml-audit-conn-datatypes.xsd"/>
  <xs:include schemaLocation="msml-audit-dialog-datatypes.xsd"/>
  <xs:include schemaLocation="msml-audit-stream-datatypes.xsd"/>
  <xs:element name="msml">
   <xs:complexType>
    <xs:choice>
     <xs:group ref="msmlRequestType" maxOccurs="unbounded"/>
     <xs:element name="event">
      <xs:complexType>
       <xs:choice maxOccurs="unbounded">
        <xs:sequence>
         <xs:element name="name" type="msmlEventNameValue.datatype"/>
         <xs:element name="value">
          <xs:simpleType>
           <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-9.]+"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:element>
        </xs:sequence>
       </xs:choice>
       <xs:attribute name="name" type="msmlEventName.datatype"
                     use="required"/>
       <xs:attribute name="id" type="msmlEventSource.datatype"
                     use="required"/>
      </xs:complexType>
     </xs:element>
     <xs:element name="result">
      <xs:complexType>
       <xs:choice>
        <xs:element ref="description" minOccurs="0"/>
        <xs:sequence>
         <xs:element ref="msmlResultSimple" minOccurs="0"
                     maxOccurs="unbounded"/>
         <xs:element ref="msmlResultComplex" minOccurs="0"
                     maxOccurs="unbounded"/>
        </xs:sequence>
       </xs:choice>
       <xs:attribute name="response">
        <xs:simpleType>
         <xs:restriction base="xs:string">
          <xs:pattern value="\d{3}"/>
         </xs:restriction>
        </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="mark" type="mark.datatype"/>
      </xs:complexType>

Saleem, et al. Informational [Page 135] RFC 5707 Media Server Markup Language February 2010

     </xs:element>
    </xs:choice>
    <xs:attribute name="version" type="xs:string" use="required"
                  fixed="1.1"/>
   </xs:complexType>
  </xs:element>
 </xs:schema>

16.1. MSML Core

16.1.1. msml-core.xsd

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:include schemaLocation="msml-core-datatypes.xsd"/>
  <xs:element name="msml">
   <xs:complexType>
    <xs:choice>
     <xs:group ref="msmlRequestType" maxOccurs="unbounded"/>
     <xs:element name="event">
      <xs:complexType>
       <xs:choice maxOccurs="unbounded">
        <xs:sequence>
         <xs:element name="name" type="msmlEventNameValue.datatype"/>
         <xs:element name="value">
          <xs:simpleType>
           <xs:restriction base="xs:string">
            <xs:pattern value="[a-zA-Z0-9.]+"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:element>
        </xs:sequence>
       </xs:choice>
       <xs:attribute name="name" type="msmlEventName.datatype"
                     use="required"/>
       <xs:attribute name="id" type="msmlEventSource.datatype"
                     use="required"/>
      </xs:complexType>
     </xs:element>
     <xs:element name="result">
      <xs:complexType>
       <xs:choice>
        <xs:element ref="description" minOccurs="0"/>
        <xs:sequence>
         <xs:element ref="msmlResultSimple" minOccurs="0"
                     maxOccurs="unbounded"/>
         <xs:element ref="msmlResultComplex" minOccurs="0"

Saleem, et al. Informational [Page 136] RFC 5707 Media Server Markup Language February 2010

                     maxOccurs="unbounded"/>
        </xs:sequence>
       </xs:choice>
       <xs:attribute name="response">
        <xs:simpleType>
         <xs:restriction base="xs:string">
          <xs:pattern value="\d{3}"/>
         </xs:restriction>
        </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="mark" type="mark.datatype"/>
      </xs:complexType>
     </xs:element>
    </xs:choice>
    <xs:attribute name="version" type="xs:string" use="required"
                  fixed="1.1"/>
   </xs:complexType>
  </xs:element>
 </xs:schema>

16.1.2. msml-core-datatypes.xsd

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">
  <xs:group name="msmlRequestType">
   <xs:choice>
    <xs:element ref="msmlRequest"/>
    <xs:element name="send">
     <xs:complexType>
      <xs:complexContent>
       <xs:extension base="msmlRequestType">
        <xs:attribute name="event" type="msmlEvent.datatype"
                      use="required"/>
        <xs:attribute name="target" type="msmlTarget.datatype"
                     use="required"/>
        <xs:attribute name="valuelist" type="xs:string"/>
       </xs:extension>
      </xs:complexContent>
     </xs:complexType>
    </xs:element>
   </xs:choice>
  </xs:group>
  <xs:element name="msmlRequest" type="msmlRequestType"
              abstract="true"/>
  <xs:complexType name="msmlRequestType">
   <xs:attribute ref="mark"/>

Saleem, et al. Informational [Page 137] RFC 5707 Media Server Markup Language February 2010

  </xs:complexType>
  <xs:element name="msmlResultSimple" type="msmlResultSimpleType"
              abstract="true"/>
  <xs:element name="msmlResultComplex" type="msmlResultComplexType"
              abstract="true"/>
  <xs:simpleType name="msmlResultSimpleType">
   <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:complexType name="msmlResultComplexType"/>
  <xs:element name="description" type="xs:string"/>
  <xs:attribute name="mark" type="mark.datatype"/>
  <xs:simpleType name="msmlInstanceID.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="[a-zA-Z0-9.:\-_]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="connID.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="conn:[a-zA-Z0-9.:\-_]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="confID.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="conf:[a-zA-Z0-9.:\-_]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="dialogID.datatype">
   <xs:restriction base="xs:string">
 <xs:pattern value="conf:[a-zA-Z0-9.:\-_]+/dialog:[a-zA-Z0-9.:\-_]+"/>
 <xs:pattern value="conn:[a-zA-Z0-9.:\-_]+/dialog:[a-zA-Z0-9.:\-_]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="independentID.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="conf:[a-zA-Z0-9.:\-_]+"/>
    <xs:pattern value="conn:[a-zA-Z0-9.:\-_]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="dialogLanguage.datatype">
   <xs:restriction base="xs:string">
    <xs:enumeration value="application/moml+xml"/>
    <xs:enumeration value="application/voicexml+xml"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="msmlEvent.datatype">
   <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="msmlSend.datatype">

Saleem, et al. Informational [Page 138] RFC 5707 Media Server Markup Language February 2010

   <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="msmlEventName.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="msml.dialog.exit"/>
    <xs:pattern value="msml.conf.asn"/>
    <xs:pattern value="msml.conf.nomedia"/>
    <xs:pattern value="msml.dialog.exit"/>
    <xs:pattern value="[a-zA-Z0-9.:_\-]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="msmlTarget.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern
 value="conf:[a-zA-Z0-9.:_\-]+(/oper:[a-zA-Z0-9.:_\-]+|\*)*"/>
    <xs:pattern
 value="conn:[a-zA-Z0-9.:_\-]+(/oper:[a-zA-Z0-9.:_\-]+|\*)+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="msmlEventSource.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="conf:[a-zA-Z0-9.:_\-]+"/>
    <xs:pattern value="(conf:[a-zA-Z0-9.:_\-]+|conn:[a-zA-Z0-9.:_\-
    ]+)/dialog:[a-zA-Z0-9.:_\-]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="msmlEventNameValue.datatype">
   <xs:restriction base="xs:string"/>
  </xs:simpleType>
  <xs:simpleType name="mark.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="[a-zA-Z0-9.:\-_]+"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="boolean.datatype">
   <xs:restriction base="xs:string">
    <xs:enumeration value="true"/>
    <xs:enumeration value="false"/>
   </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="posDuration.datatype">
   <xs:restriction base="xs:string">
    <xs:pattern value="(\+)?([0-9]*\.)?[0-9]+(ms|s)"/>
   </xs:restriction>
  </xs:simpleType>
 </xs:schema>

Saleem, et al. Informational [Page 139] RFC 5707 Media Server Markup Language February 2010

16.2. MSML Conference Core Package

16.2.1. msml-conf-core.xsd

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">
    <xs:include schemaLocation="msml-core.xsd"/>
    <xs:include schemaLocation="msml-conf-core-datatypes.xsd"/>
 </xs:schema>

16.2.2. msml-conf-core-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core-datatypes.xsd"/> <xs:element name="createconference" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:all>
    <xs:element name="audiomix" type="audioMixType" minOccurs="0"/>
    <xs:element name="videolayout" type="videoLayoutType"
                minOccurs="0"/>
    <xs:element name="reserve" minOccurs="0">
     <xs:complexType>
      <xs:sequence>
       <xs:element name="resource" maxOccurs="unbounded">
        <xs:complexType>
         <xs:sequence>
          <xs:any namespace="##other" processContents="lax"
                  minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="n" type="xs:positiveInteger"
                      default="1"/>
         <xs:anyAttribute namespace="##any"/>
        </xs:complexType>
       </xs:element>
      </xs:sequence>
      <xs:attribute name="required" type="boolean.datatype"
                    default="true"/>
     </xs:complexType>
    </xs:element>
   </xs:all>
   <xs:attribute name="name" type="msmlInstanceID.datatype"/>

Saleem, et al. Informational [Page 140] RFC 5707 Media Server Markup Language February 2010

   <xs:attribute name="deletewhen" default="never">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="nomedia"/>
      <xs:enumeration value="nocontrol"/>
      <xs:enumeration value="never"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="term" type="boolean.datatype" default="true"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="modifyconference" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:all>
    <xs:element name="audiomix" type="audioMixType" minOccurs="0"/>
    <xs:element name="videolayout" type="videoLayoutType"
                minOccurs="0"/>
   </xs:all>
   <xs:attribute name="id" type="confID.datatype" use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="destroyconference" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:all>
    <xs:element name="audiomix" type="basicAudioMixType"
                minOccurs="0"/>
    <xs:element name="videolayout" type="basicVideoLayoutType"
                minOccurs="0"/>
   </xs:all>
   <xs:attribute name="id" type="confID.datatype" use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="join" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:sequence>

Saleem, et al. Informational [Page 141] RFC 5707 Media Server Markup Language February 2010

    <xs:element name="stream" type="streamType" minOccurs="0"
                maxOccurs="4"/>
   </xs:sequence>
   <xs:attribute name="id1" type="independentID.datatype"
                 use="required"/>
   <xs:attribute name="id2" type="independentID.datatype"
                 use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="modifystream" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:sequence>
    <xs:element name="stream" type="streamType" maxOccurs="4"/>
   </xs:sequence>
   <xs:attribute name="id1" type="independentID.datatype"
                 use="required"/>
   <xs:attribute name="id2" type="independentID.datatype"
                 use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="unjoin" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:sequence>
    <xs:element name="stream" type="basicStreamType" minOccurs="0"
                maxOccurs="4"/>
   </xs:sequence>
   <xs:attribute name="id1" type="independentID.datatype"
                 use="required"/>
   <xs:attribute name="id2" type="independentID.datatype"
                 use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="monitor" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:attribute name="id1" type="connID.datatype" use="required"/>
   <xs:attribute name="id2" type="independentID.datatype"

Saleem, et al. Informational [Page 142] RFC 5707 Media Server Markup Language February 2010

                 use="required"/>
   <xs:attribute name="compressed" type="boolean.datatype"
                 default="false"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="confid" type="msmlResultSimpleType"

           substitutionGroup="msmlResultSimple"/>

<xs:complexType name="basicStreamType">

<xs:attribute name="dir">
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="to-id1"/>
   <xs:enumeration value="from-id1"/>
  </xs:restriction>
 </xs:simpleType>
</xs:attribute>
<xs:attribute name="media">
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="audio"/>
   <xs:enumeration value="video"/>
  </xs:restriction>
 </xs:simpleType>
</xs:attribute>
<xs:attribute name="compressed" type="boolean.datatype"/>

</xs:complexType> <xs:complexType name="streamType">

<xs:complexContent>
 <xs:extension base="basicStreamType">
  <xs:choice minOccurs="0" maxOccurs="unbounded">
   <xs:element name="gain">
    <xs:complexType>
     <xs:attribute name="amt" use="optional">
      <xs:simpleType>
       <xs:restriction base="xs:integer">
        <xs:minInclusive value="-96"/>
        <xs:maxInclusive value="96"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
     <xs:attribute name="agc" type="boolean.datatype"/>
     <xs:attribute name="tgtlvl" use="optional">
      <xs:simpleType>
       <xs:restriction base="xs:nonPositiveInteger">
        <xs:minInclusive value="-40"/>
        <xs:maxInclusive value="0"/>

Saleem, et al. Informational [Page 143] RFC 5707 Media Server Markup Language February 2010

       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
     <xs:attribute name="maxgain" default="10">
      <xs:simpleType>
       <xs:restriction base="xs:nonNegativeInteger">
        <xs:minInclusive value="0"/>
        <xs:maxInclusive value="40"/>
       </xs:restriction>
      </xs:simpleType>
     </xs:attribute>
    </xs:complexType>
   </xs:element>
   <xs:element name="clamp">
    <xs:complexType>
     <xs:attribute name="dtmf" type="boolean.datatype"/>
     <xs:attribute name="tones" type="boolean.datatype"/>
    </xs:complexType>
   </xs:element>
   <xs:element name="visual"/>
  </xs:choice>
  <xs:attribute name="preferred" type="boolean.datatype"
                default="false"/>
  <xs:attribute name="display" type="xs:string"/>
  <xs:attribute name="override" type="boolean.datatype"
                default="false"/>
 </xs:extension>
</xs:complexContent>

</xs:complexType> <xs:complexType name="basicAudioMixType">

<xs:attribute name="id" type="xs:string" use="optional"/>
<xs:attribute name="samplerate" type="xs:positiveInteger"
              use="optional" default="8000"/>

</xs:complexType> <xs:complexType name="audioMixType">

<xs:complexContent>
 <xs:extension base="basicAudioMixType">
  <xs:all>
   <xs:element name="asn" minOccurs="0">
    <xs:complexType>
     <xs:attribute name="ri" type="posDuration.datatype"/>
     <xs:attribute name="asth" default="-96">
      <xs:simpleType>
       <xs:restriction base="xs:nonPositiveInteger">
        <xs:minInclusive value="-96"/>
        <xs:maxInclusive value="0"/>
       </xs:restriction>
      </xs:simpleType>

Saleem, et al. Informational [Page 144] RFC 5707 Media Server Markup Language February 2010

     </xs:attribute>
    </xs:complexType>
   </xs:element>
   <xs:element name="n-loudest" minOccurs="0">
    <xs:complexType>
     <xs:attribute name="n" type="xs:positiveInteger" use="required"/>
    </xs:complexType>
   </xs:element>
  </xs:all>
 </xs:extension>
</xs:complexContent>

</xs:complexType> <xs:complexType name="basicVideoLayoutType">

<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="type" type="xs:string" use="required"
              fixed="text/msml-basic-layout"/>

</xs:complexType> <xs:complexType name="videoLayoutType">

<xs:complexContent>
 <xs:extension base="basicVideoLayoutType">
  <xs:choice>
   <xs:element name="selector">
    <xs:complexType>
     <xs:complexContent>
      <xs:extension base="selectorType">
       <xs:choice>
        <xs:element name="root" type="rootType" minOccurs="0"/>
        <xs:element name="region" minOccurs="0">
         <xs:complexType>
          <xs:attribute name="id" type="xs:string" use="required"/>
          <xs:attribute name="left" type="xs:positiveInteger"/>
          <xs:attribute name="top" type="xs:positiveInteger"/>
          <xs:attribute name="relativeSize">
           <xs:simpleType>
            <xs:restriction base="xs:string">
             <xs:enumeration value="1/4"/>
             <xs:enumeration value="1/3"/>
             <xs:enumeration value="2/3"/>
             <xs:enumeration value="3/4"/>
             <xs:enumeration value="1"/>
            </xs:restriction>
           </xs:simpleType>
          </xs:attribute>
          <xs:attribute name="priority">
           <xs:simpleType>
            <xs:restriction base="xs:float">
             <xs:minInclusive value="0"/>
             <xs:maxExclusive value="1"/>

Saleem, et al. Informational [Page 145] RFC 5707 Media Server Markup Language February 2010

            </xs:restriction>
           </xs:simpleType>
          </xs:attribute>
          <xs:attribute name="title" type="xs:string"/>
          <xs:attribute name="titleTextColor" type="xs:string"/>
          <xs:attribute name="titleBackgroundColor" type="xs:string"/>
          <xs:attribute name="borderColor" type="xs:string"/>
          <xs:attribute name="borderWidth" type="xs:positiveInteger"/>
          <xs:attribute name="logo" type="xs:anyURI"/>
         </xs:complexType>
        </xs:element>
       </xs:choice>
      </xs:extension>
     </xs:complexContent>
    </xs:complexType>
   </xs:element>
   <xs:element name="root" type="rootType"/>
   <xs:element name="region" minOccurs="0" maxOccurs="unbounded">
    <xs:complexType>
     <xs:complexContent>
      <xs:extension base="regionType"/>
     </xs:complexContent>
    </xs:complexType>
   </xs:element>
  </xs:choice>
 </xs:extension>
</xs:complexContent>

</xs:complexType> <xs:complexType name="regionType">

<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="left" type="xs:positiveInteger"/>
<xs:attribute name="top" type="xs:positiveInteger"/>
<xs:attribute name="relativeSize">
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="1/4"/>
   <xs:enumeration value="1/3"/>
   <xs:enumeration value="2/3"/>
   <xs:enumeration value="3/4"/>
   <xs:enumeration value="1"/>
  </xs:restriction>
 </xs:simpleType>
</xs:attribute>
<xs:attribute name="priority">
 <xs:simpleType>
  <xs:restriction base="xs:float">
   <xs:minInclusive value="0"/>
   <xs:maxExclusive value="1"/>

Saleem, et al. Informational [Page 146] RFC 5707 Media Server Markup Language February 2010

  </xs:restriction>
 </xs:simpleType>
</xs:attribute>
<xs:attribute name="title" type="xs:string"/>
<xs:attribute name="titleTextColor" type="xs:string"/>
<xs:attribute name="titleBackgroundColor" type="xs:string"/>
<xs:attribute name="borderColor" type="xs:string"/>
<xs:attribute name="borderWidth" type="xs:positiveInteger"/>
<xs:attribute name="logo" type="xs:anyURI"/>

</xs:complexType> <xs:complexType name="selectorType">

<xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="method" use="required">
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="vas"/>
   <xs:enumeration value="sequence"/>
  </xs:restriction>
 </xs:simpleType>
</xs:attribute>
<xs:attribute name="status" default="active">
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="active"/>
   <xs:enumeration value="disabled"/>
  </xs:restriction>
 </xs:simpleType>
</xs:attribute>
<xs:attribute name="si" type="posDuration.datatype" default="1s"/>
<xs:attribute name="blankothers" type="xs:boolean" default="false"/>
<xs:attribute name="speakersees" default="current">
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="current"/>
   <xs:enumeration value="previous"/>
  </xs:restriction>
 </xs:simpleType>
</xs:attribute>

</xs:complexType> <xs:complexType name="rootType">

<xs:attribute name="size" default="CIF">
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="16CIF"/>
   <xs:enumeration value="4CIF"/>
   <xs:enumeration value="CIF"/>
   <xs:enumeration value="QCIF"/>
  </xs:restriction>

Saleem, et al. Informational [Page 147] RFC 5707 Media Server Markup Language February 2010

 </xs:simpleType>
</xs:attribute>
<xs:attribute name="backgroundcolor" type="xs:string"
              default="black"/>
<xs:attribute name="backgroundimage" type="xs:anyURI"/>

</xs:complexType> <xs:simpleType name="confclass.datatype">

<xs:restriction base="xs:string">
 <xs:enumeration value="standard"/>
 <xs:enumeration value="preferred"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="conferenceType.datatype">

<xs:restriction base="xs:string">
 <xs:enumeration value="audio.basic"/>
 <xs:enumeration value="audio.advanced"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="duplex.datatype">

<xs:restriction base="xs:string">
 <xs:enumeration value="half"/>
 <xs:enumeration value="full"/>
</xs:restriction>

</xs:simpleType> </xs:schema>

16.3. MSML Dialog Packages

16.3.1. msml-dialog-core.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> </xs:schema>

16.3.2. msml-dialog-core-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core-datatypes.xsd"/> <xs:group name="momlRequest">

<xs:choice>
 <xs:group ref="executeType"/>

Saleem, et al. Informational [Page 148] RFC 5707 Media Server Markup Language February 2010

 <xs:group ref="sendType"/>
</xs:choice>

</xs:group> <xs:element name="dialogstart" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:choice>
    <xs:group ref="momlRequest" minOccurs="0"/>
   </xs:choice>
   <xs:attribute name="target" type="independentID.datatype"
                 use="required"/>
   <xs:attribute name="type" type="dialogLanguage.datatype"
                 use="required"/>
   <xs:attribute name="name" type="msmlInstanceID.datatype"/>
   <xs:attribute name="src" type="xs:anyURI" use="optional"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="dialogend" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:attribute name="id" type="dialogID.datatype" use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="dialogid" type="msmlResultSimpleType"

           substitutionGroup="msmlResultSimple"/>

<xs:group name="executeType">

<xs:choice>
 <xs:element ref="primitive" maxOccurs="unbounded"/>
 <xs:element ref="control" maxOccurs="unbounded"/>
</xs:choice>

</xs:group> <xs:element name="primitive" type="primitiveType" abstract="true"/> <xs:complexType name="primitiveType">

<xs:attribute name="id" type="momlID.datatype"/>

</xs:complexType> <xs:element name="control" abstract="true"/> <xs:group name="sendType">

<xs:choice>
 <xs:choice>
  <xs:element name="exit" type="exitType"/>
  <xs:element name="disconnect" type="exitType"/>
 </xs:choice>

Saleem, et al. Informational [Page 149] RFC 5707 Media Server Markup Language February 2010

 <xs:sequence>
  <xs:element ref="send" maxOccurs="unbounded"/>
  <xs:choice minOccurs="0">
   <xs:element name="exit" type="exitType"/>
   <xs:element name="disconnect" type="exitType"/>
  </xs:choice>
 </xs:sequence>
</xs:choice>

</xs:group> <xs:element name="send">

<xs:complexType>
 <xs:attribute name="event" type="momlEvent.datatype" use="required"/>
 <xs:attribute name="target" type="momlTarget.datatype"
               use="required"/>
 <xs:attribute name="namelist" type="momlNamelist.datatype"/>
</xs:complexType>

</xs:element> <xs:complexType name="exitType">

<xs:attribute name="namelist" type="momlNamelist.datatype"/>

</xs:complexType> <xs:simpleType name="momlID.datatype">

<xs:restriction base="xs:string">
 <xs:pattern value="[a-zA-Z0-9][a-zA-Z0-9._\-]*"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="momlEvent.datatype">

<xs:restriction base="xs:string">
 <xs:pattern value="[a-zA-Z0-9][a-zA-Z0-9._\-]*"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="momlNamelist.datatype">

<xs:restriction base="xs:string"/>

</xs:simpleType> <xs:simpleType name="dtmfDigits.datatype">

<xs:restriction base="xs:string">
 <xs:pattern value="[0-9#*]+"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="iterate.datatype">

<xs:union memberTypes="xs:positiveInteger">
 <xs:simpleType>
  <xs:restriction base="xs:negativeInteger">
   <xs:minInclusive value="-1"/>
  </xs:restriction>
 </xs:simpleType>
 <xs:simpleType>
  <xs:restriction base="xs:string">
   <xs:enumeration value="forever"/>

Saleem, et al. Informational [Page 150] RFC 5707 Media Server Markup Language February 2010

  </xs:restriction>
 </xs:simpleType>
</xs:union>

</xs:simpleType> <xs:simpleType name="momlTarget.datatype">

<xs:restriction base="xs:string">
 <xs:pattern value="[a-zA-Z0-9][a-zA-Z0-9._\-]*"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="duration.datatype">

<xs:restriction base="xs:string">
 <xs:pattern value="(\+|\-)?([0-9]*\.)?[0-9]+(ms|s)"/>
</xs:restriction>

</xs:simpleType> </xs:schema>

16.3.3. msml-dialog-base.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="unqualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-base-datatypes.xsd"/> </xs:schema>

16.3.4. msml-dialog-base-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="unqualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace"

          schemaLocation="http://www.w3.org/2001/xml.xsd"/>

<xs:element name="play" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:sequence>
    <xs:choice maxOccurs="unbounded">
     <xs:element name="audio" minOccurs="0" maxOccurs="unbounded">
      <xs:complexType>
       <xs:attribute name="uri" type="xs:anyURI" use="required"/>
       <xs:attribute name="iterate" type="iterate.datatype"
                     default="1"/>
       <xs:attribute name="format" type="xs:string" use="optional"/>

Saleem, et al. Informational [Page 151] RFC 5707 Media Server Markup Language February 2010

       <xs:attribute name="audiosamplerate" type="xs:positiveInteger"
                     use="optional"/>
       <xs:attribute name="audiosamplesize" type="xs:positiveInteger"
                     use="optional"/>
       <xs:attribute ref="xml:lang"/>
      </xs:complexType>
     </xs:element>
     <xs:element name="video" minOccurs="0" maxOccurs="unbounded">
      <xs:complexType>
       <xs:attribute name="uri" type="xs:anyURI" use="required"/>
       <xs:attribute name="iterate" type="iterate.datatype"
                     use="optional" default="1"/>
       <xs:attribute name="format" type="xs:string" use="optional"/>
       <xs:attribute name="audiosamplerate" type="xs:positiveInteger"
                     use="optional"/>
       <xs:attribute name="audiosamplesize" type="xs:positiveInteger"
                     use="optional"/>
       <xs:attribute name="codecconfig" type="xs:string"
                     use="optional"/>
       <xs:attribute name="profile" type="xs:string" use="optional"/>
       <xs:attribute name="level" type="xs:string" use="optional"/>
       <xs:attribute name="imagewidth" type="xs:positiveInteger"
                     use="optional"/>
       <xs:attribute name="imageheight" type="xs:positiveInteger"
                     use="optional"/>
       <xs:attribute name="maxbitrate" type="xs:positiveInteger"
                     use="optional"/>
       <xs:attribute name="framerate" type="xs:positiveInteger"
                     use="optional"/>
      </xs:complexType>
     </xs:element>
     <xs:element name="media" minOccurs="0" maxOccurs="unbounded">
      <xs:complexType>
       <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element name="audio" minOccurs="0">
         <xs:complexType>
          <xs:attribute name="uri" type="xs:anyURI" use="required"/>
          <xs:attribute name="iterate" type="iterate.datatype"
                        default="1"/>
          <xs:attribute name="format" type="xs:string"
                        use="optional"/>
          <xs:attribute name="audiosamplerate"
                        type="xs:positiveInteger" use="optional"/>
          <xs:attribute name="audiosamplesize"
                        type="xs:positiveInteger" use="optional"/>
          <xs:attribute ref="xml:lang"/>
         </xs:complexType>
        </xs:element>

Saleem, et al. Informational [Page 152] RFC 5707 Media Server Markup Language February 2010

        <xs:element name="video" minOccurs="0">
         <xs:complexType>
          <xs:attribute name="uri" type="xs:anyURI" use="required"/>
          <xs:attribute name="iterate" type="iterate.datatype"
                        use="optional" default="1"/>
          <xs:attribute name="format" type="xs:string"
                        use="optional"/>
          <xs:attribute name="audiosamplerate"
                        type="xs:positiveInteger" use="optional"/>
          <xs:attribute name="audiosamplesize"
                        type="xs:positiveInteger" use="optional"/>
          <xs:attribute name="codecconfig" type="xs:string"
                        use="optional"/>
          <xs:attribute name="profile" type="xs:string"
                        use="optional"/>
          <xs:attribute name="level" type="xs:string" use="optional"/>
          <xs:attribute name="imagewidth" type="xs:positiveInteger"
                        use="optional"/>
          <xs:attribute name="imageheight" type="xs:positiveInteger"
                        use="optional"/>
          <xs:attribute name="maxbitrate" type="xs:positiveInteger"
                        use="optional"/>
          <xs:attribute name="framerate" type="xs:positiveInteger"
                        use="optional"/>
         </xs:complexType>
        </xs:element>
       </xs:choice>
      </xs:complexType>
     </xs:element>
     <xs:element ref="smedia" minOccurs="0" maxOccurs="unbounded"/>
    </xs:choice>
    <xs:choice minOccurs="0">
     <xs:element name="playexit">
      <xs:complexType>
       <xs:group ref="sendType"/>
      </xs:complexType>
     </xs:element>
    </xs:choice>
   </xs:sequence>
   <xs:attribute name="interval" type="posDuration.datatype"
                 use="optional"/>
   <xs:attribute name="iterate" type="iterate.datatype" use="optional"
                 default="1"/>
   <xs:attribute name="offset" type="duration.datatype"
                 use="optional"/>
   <xs:attribute name="initial" use="optional" default="generate">
    <xs:simpleType>
     <xs:restriction base="xs:string">

Saleem, et al. Informational [Page 153] RFC 5707 Media Server Markup Language February 2010

      <xs:enumeration value="generate"/>
      <xs:enumeration value="suspend"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="maxtime" type="posDuration.datatype"
                 use="optional"/>
   <xs:attribute name="skip" type="duration.datatype" use="optional"
                 default="3s"/>
   <xs:attribute name="barge" type="boolean.datatype" use="optional"
                 default="false"/>
   <xs:attribute name="cleardb" type="boolean.datatype" use="optional"
                 default="false"/>
   <xs:attribute ref="xml:lang"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="record" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:choice minOccurs="0">
    <xs:element ref="play" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element ref="tonegen" minOccurs="0" maxOccurs="unbounded"/>
    <xs:element name="recordexit">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
   </xs:choice>
   <xs:attribute name="append" type="boolean.datatype" use="optional"
                 default="false"/>
   <xs:attribute name="dest" type="xs:anyURI" use="optional"/>
   <xs:attribute name="audiodest" type="xs:anyURI" use="optional"/>
   <xs:attribute name="videodest" type="xs:anyURI" use="optional"/>
   <xs:attribute name="format" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="codecconfig" use="optional">
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="audiosamplerate" type="xs:positiveInteger"
                 use="optional"/>

Saleem, et al. Informational [Page 154] RFC 5707 Media Server Markup Language February 2010

   <xs:attribute name="audiosamplesize" type="xs:positiveInteger"
                 use="optional"/>
   <xs:attribute name="profile" use="optional">
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="level" use="optional">
    <xs:simpleType>
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="imagewidth" type="xs:positiveInteger"
                 use="optional"/>
   <xs:attribute name="imageheight" type="xs:positiveInteger"
                 use="optional"/>
   <xs:attribute name="maxbitrate" type="xs:positiveInteger"
                 use="optional"/>
   <xs:attribute name="framerate" type="xs:positiveInteger"
                 use="optional"/>
   <xs:attribute name="maxtime" type="posDuration.datatype"
                 use="required"/>
   <xs:attribute name="initial" use="optional" default="create">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="create"/>
      <xs:enumeration value="suspend"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="prespeech" type="posDuration.datatype"
                 use="optional" default="0s"/>
   <xs:attribute name="postspeech" type="posDuration.datatype"
                 use="optional" default="0s"/>
   <xs:attribute name="termkey" use="optional">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:pattern value="[0-9#*ABCD]"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="dtmf" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>

Saleem, et al. Informational [Page 155] RFC 5707 Media Server Markup Language February 2010

  <xs:extension base="primitiveType">
   <xs:sequence>
    <xs:element name="pattern" maxOccurs="unbounded">
     <xs:complexType>
      <xs:group ref="sendType"/>
      <xs:attribute name="digits" type="xs:string" use="required"/>
      <xs:attribute name="format">
       <xs:simpleType>
        <xs:restriction base="xs:string">
         <xs:enumeration value="mgcp"/>
         <xs:enumeration value="megaco"/>
         <xs:enumeration value="moml+digits"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="iterate" type="iterate.datatype"
                    default="1"/>
     </xs:complexType>
    </xs:element>
    <xs:element name="detect" minOccurs="0">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
    <xs:element name="noinput" type="iterateSendType" minOccurs="0"/>
    <xs:element name="nomatch" type="iterateSendType" minOccurs="0"/>
    <xs:element name="dtmfexit" minOccurs="0">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
    <xs:element ref="play" minOccurs="0"/>
   </xs:sequence>
   <xs:attribute name="cleardb" type="boolean.datatype"
                 default="true"/>
   <xs:attribute name="fdt" type="posDuration.datatype" default="0s"/>
   <xs:attribute name="idt" type="posDuration.datatype" default="4s"/>
   <xs:attribute name="edt" type="posDuration.datatype" default="4s"/>
   <xs:attribute name="starttimer" type="boolean.datatype"
                 default="false"/>
   <xs:attribute name="iterate" type="iterate.datatype" default="1"/>
   <xs:attribute name="ldd" type="posDuration.datatype" default="0s"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="collect" substitutionGroup="primitive">

<xs:complexType>

Saleem, et al. Informational [Page 156] RFC 5707 Media Server Markup Language February 2010

 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:sequence>
    <xs:element name="pattern" maxOccurs="unbounded">
     <xs:complexType>
      <xs:group ref="sendType"/>
      <xs:attribute name="digits" type="xs:string" use="required"/>
      <xs:attribute name="format">
       <xs:simpleType>
        <xs:restriction base="xs:string">
         <xs:enumeration value="mgcp"/>
         <xs:enumeration value="megaco"/>
         <xs:enumeration value="moml+digits"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="iterate" type="iterate.datatype"
                    default="1"/>
     </xs:complexType>
    </xs:element>
    <xs:element name="detect" minOccurs="0">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
    <xs:element name="noinput" type="iterateSendType" minOccurs="0"/>
    <xs:element name="nomatch" type="iterateSendType" minOccurs="0"/>
    <xs:element name="dtmfexit" minOccurs="0">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
    <xs:element ref="play" minOccurs="0"/>
   </xs:sequence>
   <xs:attribute name="cleardb" type="boolean.datatype"
                 default="true"/>
   <xs:attribute name="fdt" type="posDuration.datatype" default="0s"/>
   <xs:attribute name="idt" type="posDuration.datatype" default="4s"/>
   <xs:attribute name="edt" type="posDuration.datatype" default="4s"/>
   <xs:attribute name="starttimer" type="boolean.datatype"
                 default="false"/>
   <xs:attribute name="iterate" type="iterate.datatype" default="1"/>
   <xs:attribute name="ldd" type="posDuration.datatype"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="dtmfgen" substitutionGroup="primitive">

Saleem, et al. Informational [Page 157] RFC 5707 Media Server Markup Language February 2010

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:choice minOccurs="0">
    <xs:element name="dtmfgenexit">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
   </xs:choice>
   <xs:attribute name="level" use="optional" default="-6">
    <xs:simpleType>
     <xs:restriction base="xs:nonPositiveInteger">
      <xs:maxInclusive value="0"/>
      <xs:minInclusive value="-96"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="digits" type="dtmfDigits.datatype"
                 use="required"/>
   <xs:attribute name="dur" type="posDuration.datatype" use="optional"
                 default="100ms"/>
   <xs:attribute name="interval" type="posDuration.datatype"
                 use="optional" default="100ms"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="tonegen" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:choice minOccurs="0">
    <xs:element name="tonegenexit" minOccurs="0">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
    <xs:element name="tone" maxOccurs="unbounded">
     <xs:complexType>
      <xs:sequence>
       <xs:element name="tone1">
        <xs:complexType>
         <xs:attribute name="freq" use="required">
          <xs:simpleType>
           <xs:restriction base="xs:unsignedInt">
            <xs:minInclusive value="0"/>
            <xs:maxInclusive value="3999"/>

Saleem, et al. Informational [Page 158] RFC 5707 Media Server Markup Language February 2010

           </xs:restriction>
          </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="atten" use="required">
          <xs:simpleType>
           <xs:restriction base="xs:nonPositiveInteger">
            <xs:minInclusive value="-96"/>
            <xs:maxInclusive value="0"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:attribute>
        </xs:complexType>
       </xs:element>
       <xs:element name="tone2">
        <xs:complexType>
         <xs:attribute name="freq" use="required">
          <xs:simpleType>
           <xs:restriction base="xs:unsignedInt">
            <xs:minInclusive value="0"/>
            <xs:maxInclusive value="3999"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="atten" use="required">
          <xs:simpleType>
           <xs:restriction base="xs:nonPositiveInteger">
            <xs:minInclusive value="-96"/>
            <xs:maxInclusive value="0"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:attribute>
        </xs:complexType>
       </xs:element>
       <xs:element name="silence" minOccurs="0" maxOccurs="unbounded">
        <xs:complexType>
         <xs:attribute name="duration" type="duration.datatype"
                       use="required"/>
        </xs:complexType>
       </xs:element>
      </xs:sequence>
      <xs:attribute name="duration" use="required">
       <xs:simpleType>
        <xs:restriction base="duration.datatype"/>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="iterate" type="iterate.datatype"
                    use="optional" default="1"/>
     </xs:complexType>

Saleem, et al. Informational [Page 159] RFC 5707 Media Server Markup Language February 2010

    </xs:element>
    <xs:element name="silence" minOccurs="0" maxOccurs="unbounded">
     <xs:complexType>
      <xs:attribute name="duration" type="duration.datatype"
                    use="required"/>
     </xs:complexType>
    </xs:element>
   </xs:choice>
   <xs:attribute name="iterate" type="iterate.datatype" use="optional"
                 default="1"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:complexType name="iterateSendType">

<xs:group ref="sendType"/>
<xs:attribute name="iterate" type="iterate.datatype" default="1"/>

</xs:complexType> <xs:element name="smedia" type="smediaType" abstract="true"/> <xs:complexType name="smediaType">

<xs:attribute ref="xml:lang"/>
<xs:attribute name="iterate" type="iterate.datatype"/>

</xs:complexType> <xs:element name="var" substitutionGroup="smedia">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="smediaType">
   <xs:attribute name="type" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="date"/>
      <xs:enumeration value="digits"/>
      <xs:enumeration value="duration"/>
      <xs:enumeration value="month"/>
      <xs:enumeration value="money"/>
      <xs:enumeration value="number"/>
      <xs:enumeration value="silence"/>
      <xs:enumeration value="time"/>
      <xs:enumeration value="weekday"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="subtype" type="xs:string" use="optional"/>
   <xs:attribute name="value" type="xs:string" use="required"/>
  </xs:extension>
 </xs:complexContent>

Saleem, et al. Informational [Page 160] RFC 5707 Media Server Markup Language February 2010

</xs:complexType>

</xs:element> </xs:schema>

16.3.5. msml-dialog-transform.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="unqualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-transform-datatypes.xsd"/> </xs:schema>

16.3.6. msml-dialog-transform-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="unqualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:import namespace="http://www.w3.org/XML/1998/namespace"

          schemaLocation="http://www.w3.org/2001/xml.xsd"/>

<xs:element name="vad" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:all>
    <xs:element name="voice" type="vadPatternType" minOccurs="0"/>
    <xs:element name="silence" type="vadPatternType" minOccurs="0"/>
    <xs:element name="tvoice" type="vadPatternType" minOccurs="0"/>
    <xs:element name="tsilence" type="vadPatternType" minOccurs="0"/>
   </xs:all>
   <xs:attribute name="starttimer" type="boolean.datatype"
                 default="false"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="gain" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:attribute name="incr" default="3">
    <xs:simpleType>
     <xs:restriction base="xs:positiveInteger">
      <xs:maxInclusive value="96"/>

Saleem, et al. Informational [Page 161] RFC 5707 Media Server Markup Language February 2010

     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="amt" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:integer">
      <xs:minInclusive value="-96"/>
      <xs:maxInclusive value="96"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="agc" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:attribute name="tgtlvl" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:nonPositiveInteger">
      <xs:minInclusive value="-40"/>
      <xs:maxInclusive value="0"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="maxgain" default="10">
    <xs:simpleType>
     <xs:restriction base="xs:nonNegativeInteger">
      <xs:minInclusive value="0"/>
      <xs:maxInclusive value="40"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="gate" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:attribute name="initial" default="pass">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="pass"/>
      <xs:enumeration value="halt"/>

Saleem, et al. Informational [Page 162] RFC 5707 Media Server Markup Language February 2010

     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="clamp" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType"/>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="relay" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType"/>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:complexType name="vadPatternType">

<xs:group ref="sendType"/>
<xs:attribute name="iterate" type="iterate.datatype" default="1"/>
<xs:attribute name="len" type="posDuration.datatype" use="required"/>
<xs:attribute name="sen" type="posDuration.datatype" use="optional"/>

</xs:complexType> </xs:schema>

16.3.7. msml-dialog-group.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="unqualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-base-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-group-datatypes.xsd"/> </xs:schema>

16.3.8. msml-dialog-group-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="unqualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core-datatypes.xsd"/>

Saleem, et al. Informational [Page 163] RFC 5707 Media Server Markup Language February 2010

<xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-base-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-transform-datatypes.xsd"/> <xs:element name="group" substitutionGroup="control">

<xs:complexType>
 <xs:sequence>
  <xs:group ref="executeType"/>
  <xs:element name="groupexit" minOccurs="0">
   <xs:complexType>
    <xs:group ref="sendType"/>
   </xs:complexType>
  </xs:element>
 </xs:sequence>
 <xs:attribute name="id" type="momlID.datatype"/>
 <xs:attribute name="topology" use="required">
  <xs:simpleType>
   <xs:restriction base="xs:string">
    <xs:enumeration value="serial"/>
    <xs:enumeration value="parallel"/>
    <xs:enumeration value="fullduplex"/>
   </xs:restriction>
  </xs:simpleType>
 </xs:attribute>
</xs:complexType>

</xs:element> </xs:schema>

16.3.9. msml-dialog-speech.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-base-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-speech-datatypes.xsd"/> </xs:schema>

16.3.10. msml-dialog-speech-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-base-datatypes.xsd"/> <xs:include schemaLocation="http://www.w3.org/TR/2002/WD-speech-

Saleem, et al. Informational [Page 164] RFC 5707 Media Server Markup Language February 2010

           synthesis-20020405/synthesis-core.xsd"/>

<xs:include schemaLocation="http://www.w3.org/TR/speech-

           grammar/grammar-core.xsd"/>

<xs:element name="speech" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:sequence>
    <xs:element name="grammar" maxOccurs="unbounded">
     <xs:complexType>
      <xs:complexContent>
       <xs:extension base="grammar">
        <xs:choice>
         <xs:element name="match" type="iterateSendType"
                     minOccurs="0"/>
        </xs:choice>
        <xs:attribute name="uri" type="xs:anyURI"/>
        <xs:attribute name="iterate" type="iterate.datatype"
                      default="1"/>
       </xs:extension>
      </xs:complexContent>
     </xs:complexType>
    </xs:element>
    <xs:element name="noinput" type="iterateSendType" minOccurs="0"/>
    <xs:element name="nomatch" type="iterateSendType" minOccurs="0"/>
    <xs:element name="speechexit" minOccurs="0">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
   </xs:sequence>
   <xs:attribute name="noint" type="posDuration.datatype"/>
   <xs:attribute name="norect" type="posDuration.datatype"/>
   <xs:attribute name="spcmplt" type="posDuration.datatype"/>
   <xs:attribute name="confidence">
    <xs:simpleType>
     <xs:restriction base="xs:positiveInteger">
      <xs:maxInclusive value="100"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="sens" type="xs:positiveInteger"/>
   <xs:attribute name="starttimer" type="boolean.datatype"
                 default="false"/>
   <xs:attribute name="iterate" type="iterate.datatype" default="1"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

Saleem, et al. Informational [Page 165] RFC 5707 Media Server Markup Language February 2010

</xs:element> <xs:element name="tts" type="smediaType" substitutionGroup="smedia"/> </xs:schema>

16.3.11. msml-dialog-fax-detect.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-fax-detect-datatypes.xsd"/> </xs:schema>

16.3.12. msml-dialog-fax-detect-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:element name="faxdetect" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:choice minOccurs="0">
    <xs:element name="faxdetectexit">
     <xs:complexType>
      <xs:group ref="sendType"/>
     </xs:complexType>
    </xs:element>
   </xs:choice>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> </xs:schema>

16.3.13. msml-dialog-fax-sendrecv.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:include schemaLocation="msml-dialog-fax-sendrecv-datatypes.xsd"/>

Saleem, et al. Informational [Page 166] RFC 5707 Media Server Markup Language February 2010

</xs:schema>

16.3.14. msml-dialog-fax-sendrecv-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-dialog-core-datatypes.xsd"/> <xs:element name="faxsend" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:sequence>
    <xs:element name="sendobj" type="sendobjType" minOccurs="0"
        maxOccurs="unbounded"/>
    <xs:element name="hdrfooter" type="hdrfooterType" minOccurs="0"/>
    <xs:element name="rxpoll" minOccurs="0">
     <xs:complexType>
      <xs:sequence>
       <xs:element name="rcvobj" type="rcvobjType"
                   maxOccurs="unbounded"/>
       <xs:element name="hdrfooter" type="hdrfooterType"
                   minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="rmtid" type="faxid.datatype"
                    use="required"/>
     </xs:complexType>
    </xs:element>
    <xs:group ref="faxstatusrequest"/>
   </xs:sequence>
   <xs:attribute name="lclid" type="faxid.datatype" use="optional"/>
   <xs:attribute name="minspeed" type="faxspeed.datatype"
                 use="optional"/>
   <xs:attribute name="maxspeed" type="faxspeed.datatype"
                 use="optional"/>
   <xs:attribute name="ecm" type="boolean.datatype" use="optional"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="faxrecv" substitutionGroup="primitive">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="primitiveType">
   <xs:sequence>
    <xs:element name="rcvobj" type="rcvobjType" minOccurs="0"
                maxOccurs="unbounded"/>

Saleem, et al. Informational [Page 167] RFC 5707 Media Server Markup Language February 2010

    <xs:element name="hdrfooter" type="hdrfooterType" minOccurs="0"/>
    <xs:element name="txpoll" minOccurs="0">
     <xs:complexType>
      <xs:sequence>
       <xs:element name="sendobj" type="sendobjType"
                   maxOccurs="unbounded"/>
       <xs:element name="hdrfooter" type="hdrfooterType"
                   minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="rmtid" type="faxid.datatype"/>
     </xs:complexType>
    </xs:element>
    <xs:group ref="faxstatusrequest"/>
   </xs:sequence>
   <xs:attribute name="lclid" type="faxid.datatype" use="optional"/>
   <xs:attribute name="ecm" type="boolean.datatype" default="true"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:group name="faxstatusrequest">

<xs:sequence>
 <xs:element name="faxstart" minOccurs="0"/>
 <xs:element name="faxnegotiate" minOccurs="0"/>
 <xs:element name="faxpagedone" minOccurs="0"/>
 <xs:element name="faxobjectdone" minOccurs="0"/>
 <xs:element name="faxopcomplete" minOccurs="0"/>
 <xs:element name="faxpollstart" minOccurs="0"/>
</xs:sequence>

</xs:group> <xs:complexType name="hdrfooterType">

<xs:choice>
 <xs:element name="format" type="xs:string" minOccurs="0"
             maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="type" type="hdrfooter.datatype"/>
<xs:attribute name="style" type="hdrfooterstyle.datatype"/>

</xs:complexType> <xs:complexType name="formatType">

<xs:simpleContent>
 <xs:extension base="xs:string">
  <xs:attribute name="style">
   <xs:simpleType>
    <xs:restriction base="xs:string">
     <xs:enumeration value="append"/>
     <xs:enumeration value="overlay"/>
     <xs:enumeration value="replace"/>
    </xs:restriction>

Saleem, et al. Informational [Page 168] RFC 5707 Media Server Markup Language February 2010

   </xs:simpleType>
  </xs:attribute>
 </xs:extension>
</xs:simpleContent>

</xs:complexType> <xs:complexType name="rcvobjType">

<xs:attribute name="objuri" type="xs:anyURI" use="required"/>
<xs:attribute name="maxpages" type="xs:positiveInteger"/>

</xs:complexType> <xs:complexType name="sendobjType">

<xs:attribute name="objuri" type="xs:anyURI" use="required"/>
<xs:attribute name="startpage" type="xs:positiveInteger"/>
<xs:attribute name="pagecount" type="xs:positiveInteger"/>

</xs:complexType> <xs:simpleType name="faxid.datatype">

<xs:restriction base="xs:string">
 <xs:pattern value="[0-9+*- ]{20}"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="faxspeed.datatype">

<xs:restriction base="xs:string">
 <xs:enumeration value="2400"/>
 <xs:enumeration value="4800"/>
 <xs:enumeration value="7200"/>
 <xs:enumeration value="9600"/>
 <xs:enumeration value="12000"/>
 <xs:enumeration value="14400"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="hdrfooter.datatype">

<xs:restriction base="xs:string">
 <xs:enumeration value="header"/>
 <xs:enumeration value="footer"/>
 <xs:enumeration value="autohdr"/>
 <xs:enumeration value="nohdr"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="hdrfooterstyle.datatype">

<xs:restriction base="xs:string">
 <xs:enumeration value="append"/>
 <xs:enumeration value="overlay"/>
 <xs:enumeration value="replace"/>
</xs:restriction>

</xs:simpleType> </xs:schema>

Saleem, et al. Informational [Page 169] RFC 5707 Media Server Markup Language February 2010

16.4. MSML Audit Packages

16.4.1. msml-audit-core.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-core-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-core-datatypes.xsd"/> </xs:schema>

16.4.2. msml-audit-core-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core-datatypes.xsd"/> <xs:element name="audit" substitutionGroup="msmlRequest">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlRequestType">
   <xs:attribute name="queryid" type="auditQueryId.datatype"
                 use="required"/>
   <xs:attribute name="statelist" type="auditStateList.datatype"
                 use="optional"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="auditresult" substitutionGroup="msmlResultComplex">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="msmlResultComplexType">
  <xs:choice maxOccurs="unbounded">
   <xs:element ref="stateParameter"/>
   <xs:element ref="stateParameterSimple"/>
   </xs:choice>
   <xs:attribute name="targetid" type="independentID.datatype"
                 use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="stateParameter" type="stateParameterType"

           abstract="true"/>

Saleem, et al. Informational [Page 170] RFC 5707 Media Server Markup Language February 2010

<xs:element name="stateParameterSimple" type="stateParameterSimpleType"

           abstract="true"/>

<xs:complexType name="stateParameterType"/> <xs:simpleType name="stateParameterSimpleType">

<xs:restriction base="xs:string"/>

</xs:simpleType> <xs:simpleType name="auditQueryId.datatype">

<xs:restriction base="xs:string">
 <xs:pattern value="conf:[a-zA-Z0-9.:\-_]+"/>
 <xs:pattern value="conn:[a-zA-Z0-9.:\-_]+"/>
 <xs:pattern value="conf:\*"/>
 <xs:pattern value="conn:\*"/>
</xs:restriction>

</xs:simpleType> <xs:simpleType name="auditStateList.datatype">

<xs:restriction base="xs:string"/>

</xs:simpleType> </xs:schema>

16.4.3. msml-audit-conf.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-core-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-core-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-dialog-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-stream-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-conf-datatypes.xsd"/> </xs:schema>

16.4.4. msml-audit-conf-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-conf-core-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-core-datatypes.xsd"/> <xs:element name="confconfig" substitutionGroup="stateParameter">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="stateParameterType">
   <xs:sequence>
    <xs:element name="audiomix" type="audioMixType" minOccurs="0"
                maxOccurs="unbounded"/>

Saleem, et al. Informational [Page 171] RFC 5707 Media Server Markup Language February 2010

    <xs:element name="videolayout" type="videoLayoutType"
                minOccurs="0" maxOccurs="unbounded"/>
    <xs:element name="controller" type="connID.datatype"
                minOccurs="0"/>
   </xs:sequence>
   <xs:attribute name="deletewhen" use="optional" default="never">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="nomedia"/>
      <xs:enumeration value="nocontrol"/>
      <xs:enumeration value="never"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="term" type="boolean.datatype" use="optional"
                 default="true"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> </xs:schema>

16.4.5. msml-audit-conn.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-core.xsd"/> <xs:include schemaLocation="msml-audit-core-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-dialog-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-stream-datatypes.xsd"/> <xs:include schemaLocation="msml-audit-conn-datatypes.xsd"/> </xs:schema>

16.4.6. msml-audit-conn-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

         elementFormDefault="qualified"
         attributeFormDefault="unqualified">

<xs:include schemaLocation="msml-audit-core-datatypes.xsd"/> <xs:element name="sipdialog" substitutionGroup="stateParameter">

<xs:complexType>
 <xs:complexContent>
  <xs:extension base="stateParameterType">
   <xs:sequence>
    <xs:element name="localseq" type="xs:integer" minOccurs="0"/>

Saleem, et al. Informational [Page 172] RFC 5707 Media Server Markup Language February 2010

    <xs:element name="remoteseq" type="xs:int" minOccurs="0"/>
    <xs:element name="localuri" type="xs:string" minOccurs="0"/>
    <xs:element name="remoteuri" type="xs:string" minOccurs="0"/>
    <xs:element name="remotetarget" type="xs:string" minOccurs="0"/>
    <xs:element name="routeset" type="xs:string" minOccurs="0"/>
   </xs:sequence>
   <xs:attribute name="callid" type="xs:string" use="required"/>
   <xs:attribute name="localtag" type="xs:string" use="required"/>
   <xs:attribute name="remotetag" type="xs:string" use="required"/>
  </xs:extension>
 </xs:complexContent>
</xs:complexType>

</xs:element> <xs:element name="localsdp" type="stateParameterSimpleType"

           substitutionGroup="stateParameterSimple"/>

<xs:element name="remotesdp" type="stateParameterSimpleType"

           substitutionGroup="stateParameterSimple"/>

</xs:schema>

16.4.7. msml-audit-dialog-datatypes.xsd

 Audit Dialog functionality requires use of either the Audit Conf
 Package or the Audit Conn Package.
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">
  <xs:include schemaLocation="msml-audit-core-datatypes.xsd"/>
  <xs:element name="dialog" substitutionGroup="stateParameter">
   <xs:complexType>
    <xs:complexContent>
     <xs:extension base="stateParameterType">
      <xs:sequence>
       <xs:element name="duration" type="xs:positiveInteger"
                   minOccurs="0"/>
       <xs:element name="primitive" minOccurs="0">
        <xs:simpleType>
         <xs:restriction base="xs:string">
          <xs:pattern value="play"/>
          <xs:pattern value="dtmf"/>
          <xs:pattern value="collect"/>
          <xs:pattern value="dtmfgen"/>
          <xs:pattern value="tonegen"/>
          <xs:pattern value="record"/>
          <xs:pattern value="none"/>
         </xs:restriction>
        </xs:simpleType>

Saleem, et al. Informational [Page 173] RFC 5707 Media Server Markup Language February 2010

       </xs:element>
       <xs:element name="controller" type="connID.datatype"
                   minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="name" type="msmlInstanceID.datatype"
                    use="required"/>
      <xs:attribute name="src" type="xs:anyURI" use="optional"/>
      <xs:attribute name="type" type="dialogLanguage.datatype"
                    use="required"/>
     </xs:extension>
    </xs:complexContent>
   </xs:complexType>
  </xs:element>
 </xs:schema>

16.4.8. msml-audit-stream-datatypes.xsd

 Audit Stream functionality requires use of either the Audit Conf
 Package or the Audit Conn Package.
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">
  <xs:include schemaLocation="msml-audit-core-datatypes.xsd"/>
  <xs:element name="stream" substitutionGroup="stateParameter">
   <xs:complexType>
    <xs:complexContent>
     <xs:extension base="stateParameterType">
      <xs:all>
       <xs:element name="clamp" minOccurs="0">
        <xs:complexType>
         <xs:attribute name="dtmf" type="boolean.datatype"/>
         <xs:attribute name="tones" type="boolean.datatype"/>
        </xs:complexType>
       </xs:element>
       <xs:element name="gain" minOccurs="0">
        <xs:complexType>
         <xs:attribute name="amt" use="optional">
          <xs:simpleType>
           <xs:restriction base="xs:integer">
            <xs:minInclusive value="-96"/>
            <xs:maxInclusive value="96"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="agc" type="boolean.datatype"/>
         <xs:attribute name="tgtlvl" use="optional">

Saleem, et al. Informational [Page 174] RFC 5707 Media Server Markup Language February 2010

          <xs:simpleType>
           <xs:restriction base="xs:nonPositiveInteger">
            <xs:minInclusive value="-40"/>
            <xs:maxInclusive value="0"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="maxgain" default="10">
          <xs:simpleType>
           <xs:restriction base="xs:nonNegativeInteger">
            <xs:minInclusive value="0"/>
            <xs:maxInclusive value="40"/>
           </xs:restriction>
          </xs:simpleType>
         </xs:attribute>
        </xs:complexType>
       </xs:element>
       <xs:element name="visual" minOccurs="0"/>
      </xs:all>
      <xs:attribute name="joinwith" type="independentID.datatype"
                    use="required"/>
      <xs:attribute name="media" use="required">
       <xs:simpleType>
        <xs:restriction base="xs:string">
         <xs:pattern value="audio"/>
         <xs:pattern value="video"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="dir" use="required">
       <xs:simpleType>
        <xs:restriction base="xs:string">
         <xs:pattern value="from"/>
         <xs:pattern value="to"/>
        </xs:restriction>
       </xs:simpleType>
      </xs:attribute>
      <xs:attribute name="compressed" type="boolean.datatype"/>
      <xs:attribute name="preferred" type="boolean.datatype"
                    default="false"/>
      <xs:attribute name="display" type="xs:string"/>
      <xs:attribute name="override" type="boolean.datatype"
                    default="false"/>
     </xs:extension>
    </xs:complexContent>
   </xs:complexType>
  </xs:element>
 </xs:schema>

Saleem, et al. Informational [Page 175] RFC 5707 Media Server Markup Language February 2010

17. Security Considerations

 MSML being an XML-based language, security considerations as defined
 by RFC 3023 [i2] are applicable.
 Media server interfaces driven using MSML are under the explicit
 control of a SIP application server.  SIP call legs are used to
 deliver XML-based MSML transactions to the media server.  The
 security and integrity of MSML transactions, whenever required,
 SHOULD use sips: and TLS for encryption and authentication of the SIP
 control channel used to carry MSML payloads.  Further information
 related to security, privacy, and integrity of MSML media types is
 described in the IANA Considerations section.
 Media streams, such as audio/video, MAY optionally be protected,
 encrypted/decrypted, and authenticated, utilizing Secure Real Time
 Protocol (SRTP), wherever media stream security is required.  Media
 negotiation establishes the required level of security and is
 initiated by the clients, which is outside the scope of the control
 interface specified by MSML.

18. IANA Considerations

18.1. IANA Registrations for 'application' MIME Media Type

 The following registrations have been made:
 Type Name: "application"
 Subtype names:
    'application/vnd.radisys.msml+xml',
    'application/vnd.radisys.moml+xml',
    'application/vnd.radisys.msml-conf+xml',
    'application/vnd.radisys.msml-dialog+xml',
    'application/vnd.radisys.msml-dialog-base+xml',
    'application/vnd.radisys.msml-dialog-group+xml',
    'application/vnd.radisys.msml-dialog-speech+xml',
    'application/vnd.radisys.msml-dialog-transform+xml',
    'application/vnd.radisys.msml-dialog-fax-detect+xml',

Saleem, et al. Informational [Page 176] RFC 5707 Media Server Markup Language February 2010

    'application/vnd.radisys.msml-dialog-fax-sendrecv+xml',
    'application/vnd.radisys.msml-audit+xml',
    'application/vnd.radisys.msml-audit-conf+xml',
    'application/vnd.radisys.msml-audit-conn+xml',
    'application/vnd.radisys.msml-audit-dialog+xml',
    'application/vnd.radisys.msml-audit-stream+xml'
 Required parameters: none
 Optional parameters: charset
    charset semantics as specified in RFC 3023 [i2] for
    "application/xml" media type.
 Encoding considerations:
    As specified in RFC 3023 [i2].
 Security Considerations:
    Media types included in this section are XML based, and therefore
    security considerations as defined by RFC 3023 [i10] are
    applicable.
    These media types do not contain active or executable content as
    the content itself merely provides control of the underlying media
    streams.
    Secure exchange of content associated with these media types for
    purposes of authentication and privacy, whenever applicable, shall
    require the establishment of a secure control channel using sips:
    and TLS.
    Privacy and integrity of media content associated with these media
    types shall be considered when applications using these media
    types are exchanging personal information such as personal
    identification codes or conference access codes.  Whenever such
    content is deemed to require secure transport and authentication,
    a secure channel using sips: and TLS MUST be used, as these media
    types themselves provide no such inherent mechanisms for security.

Saleem, et al. Informational [Page 177] RFC 5707 Media Server Markup Language February 2010

 Interoperability considerations:
    As specified in RFC 3023 [i2] and as specified within this
    document.
 Published specification: RFC 5707
 Intended applications for these media types:
    Multimedia Conferencing, Interactive Voice Response systems
 Additional information:
    Magic number(s): None
    File extension(s): None
    Macintosh file type code(s): None
 Person & email address to contact for further information:
    Adnan Saleem <adnan.saleem@radisys.com>
 Intended usage: COMMON

18.2. IANA Registrations for 'text' MIME Media Type

 The following registrations are planned:
    'text/vnd.radisys.msml-basic-layout'
 Required parameters: none
 Optional parameters: charset
    charset semantics as specified in RFC 3023 [i2] for "text/xml"
    media type.
 Encoding considerations: As specified in RFC 3023 [i2].
 Security Considerations:
    Media types included in this section are XML based, and therefore
    security considerations as defined by RFC 3023 [i10] are
    applicable.

Saleem, et al. Informational [Page 178] RFC 5707 Media Server Markup Language February 2010

    The media type defined in this section does not contain active or
    executable content.  The media type defines only a visual layout
    scheme of a video conference.  Establishment of active connections
    associated with the video conference are outside the scope of this
    media type.
    Since this media type only defines a visual layout scheme, with no
    reference or information about client connections or participants
    within the conference, privacy and integrity concerns are not
    applicable to this media type.
 Interoperability considerations:
    As specified in RFC 3023 [i2] and as specified within this
    document.
 Published specification: RFC 5707
 Intended applications for these media types:
    Multimedia Conferencing, Interactive Voice Response systems
 Additional information:
    Magic number(s): None
    File extension(s): None
    Macintosh file type code(s): None
 Person & email address to contact for further information:
    Adnan Saleem <adnan.saleem@radisys.com>
 Intended usage: COMMON

18.3. URN Sub-Namespace Registration

 The namespace URI for elements defined within this specification is a
 URN [i8].  It uses the namespace identifier 'ietf' defined by [i9]
 and extended by RFC 3688 [i10].
 The following registrations of URN Sub-Namespaces are planned:
 XML namespace: urn:ietf:params:xml:ns:msml

Saleem, et al. Informational [Page 179] RFC 5707 Media Server Markup Language February 2010

 XML:
 BEGIN
 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
 "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
       <meta http-equiv="content-type"
             content="text/html;charset=iso-8859-1"/>
       <title>Media Server Markup Language Namespace</title>
   </head>
   <body>
      <h1>Namespace for Media Server Markup Language</h1>
      <h2>urn:ietf:params:xml:ns:msml</h2>
      <p>See MSML <a
     href="http://www.rfc-editor.org/rfc/rfc5707.txt">RFC 5707</a></p>
   </body>
 </html>
 END

18.4. XML Schema Registration

 This section registers an XML schema per the procedures in [i10].
 URI: urn:ietf:params:xml:schema:msml
 Registrant Contact:
    Adnan Saleem (adnan.saleem@radisys.com) and authors listed
    within this document.

Saleem, et al. Informational [Page 180] RFC 5707 Media Server Markup Language February 2010

 The XML for this schema can be found as the sole content of Section
 16.

19. References

19.1. Normative References

 [n1]  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.
 [n2]  Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
       "Extensible Markup Language (XML) 1.0 (Second Edition)," W3C
       First Edition REC-xml-20001006, October 2000.
 [n3]  World Wide Web Consortium, "Speech Recognition Grammar
       Specification Version 1.0" (SRGS), W3C Candidate
       Recommendation, March 16, 2004
 [n4]  World Wide Web Consortium, "Natural Language Semantics Markup
       Language (NLSML) for the Speech Interface Framework", W3C
       Working Draft 20, November 2000.
 [n5]  World Wide Web Consortium, "Voice Extensible Markup Language
       (VoiceXML) Version 2.0, W3C Candidate Recommendation, March 16,
       2004.
 [n6]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
       Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
       January 2005.
 [n7]  Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic Network
       Media Services with SIP", RFC 4240, December 2005.
 [n8]  Levinson, E., "Content-ID and Message-ID Uniform Resource
       Locators", RFC 2392, August 1998.
 [n9]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
       Description Protocol", RFC 4566, July 2006.
 [n10] Bos, B., Lie, H., Tantek, C., and Hickson, I., "Cascading Style
       Sheets, level 2 (CSS2) Specification," W3C REC CR-CSS21-, July
       2007.
 [n11] Burnett, D., Walker, M., and Hunt, A., "Speech Synthesis Markup
       Language (SSML) Version 1.0", W3C Recommendation, 7 September
       2004.

Saleem, et al. Informational [Page 181] RFC 5707 Media Server Markup Language February 2010

19.2. Informative References

 [i1]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
       User Agent Capabilities in the Session Initiation Protocol
       (SIP)", RFC 3840, August 2004.
 [i2]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
       RFC 3023, January 2001.
 [i3]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
       "RTP: A Transport Protocol for Real-Time Applications", STD 64,
       RFC 3550, July 2003.
 [i4]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
       "Best Current Practices for Third Party Call Control (3pcc) in
       the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
       2004.
 [i5]  Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
 [i6]  Ossenbruggen, J., Rutledge, L., Saccocio, B., Schmitz, P.,
       Kate, W., Ayars, J., Bulterman, D., Cohen, A., Day, K., Hodge,
       E., Hoschka, P., Hyche, E., Jourdan, M., Kubota, K., Lanphier,
       R., Laya'da, N., Michel, T., and D. Newman, "Synchronized
       Multimedia Integration Language (SMIL 2.0) Specification," W3C
       REC REC-smil2-20050107, January 2005.
 [i7]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part Two: Media Types", RFC 2046, November
       1996.
 [i8]  Moats, R., "URN Syntax", RFC 2141, May 1997.
 [i9]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
       August 1999.
 [i10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
       January 2004.
 [i11] Boulton, C., Melanchuk, T., McGlashan, S., and A. Shiratzky, "A
       Control Framework for the Session Initiation Protocol (SIP)",
       Work in Progress, February 2007.

Saleem, et al. Informational [Page 182] RFC 5707 Media Server Markup Language February 2010

Acknowledgments

 Sergiu Stambolian of RadiSys provided key insights, both theoretic
 and through development experience, on several versions of the
 document.
 Stephen Buko and George Raskulinec of Intel made numerous valuable
 contributions towards enhancements of multimedia playback and record
 operations.  Gene Shtirmer of Intel provided review feedback on
 several revisions and feature enhancement suggestions.
 David Asher of NMS Communications provided valuable insights towards
 creation of standard profiles and a modularization scheme based on
 packages for better interoperability.
 Gilles Compienne of Ubiquity Software has provided feedback on
 several earlier versions of this document.
 Chris Boulton and Ben Smith, both of Ubiquity, and Michael Rice of
 VocalData helped clarify several issues, while Bruce Walsh and Kevin
 Fitzgerald, both of Spectel/Avaya, provided important feedback.
 Cliff Schornak of Commetrex significantly contributed to the
 facsimile work.  Peter Danielsen of Lucent has contributed thoughtful
 and detailed reviews for several earlier versions of the document.

Saleem, et al. Informational [Page 183] RFC 5707 Media Server Markup Language February 2010

Authors' Addresses

 Adnan Saleem
 RadiSys
 4190 Still Creek Drive, Suite 300
 Burnaby, BC, V5C 6C6
 Canada
 Phone: +1 604 918 6376
 EMail : adnan.saleem@radisys.com
 Yong Xin
 RadiSys
 4190 Still Creek Drive, Suite 300
 Burnaby, BC, V5C 6C6
 Canada
 Phone: +1 604 918 6383
 EMail: yong.xin@radiSys.com
 Garland Sharratt
 Consultant
 Vancouver, BC
 Canada
 EMail: garland.sharratt@gmail.com

Saleem, et al. Informational [Page 184]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5707.txt · Last modified: 2010/02/04 01:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki