tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5707

 Errata 
Informational
Pages: 184
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     No Next: Highest Number in Group     Group: ~msml

Media Server Markup Language (MSML)

Part 1 of 6, p. 1 to 19
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Page 2 
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

Top      ToC       Page 3 
      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

Top      ToC       Page 4 
   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.

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
   "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.

Top      ToC       Page 11 
         <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.

Top      ToC       Page 12 
         <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

Top      ToC       Page 13 
         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.

Top      ToC       Page 14 
         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).

Top      ToC       Page 15 
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.

Top      ToC       Page 16 
           +--------------------------------------------------------+
           |                     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)

Top      ToC       Page 17 
      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)

Top      ToC       Page 18 
      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.

Top      ToC       Page 19 
   The package scheme described earlier allows MSML functionality to be
   functionally grouped, relying on the MSML core package.  This scheme
   allows a portion of the complete MSML specification to be
   implemented, on a per-package basis, and also creates a framework for
   future extension packages.  However, within a given package, in some
   cases, only a subset of the package functionality may be required.
   In order to support subsets of packages, with greater degree of
   granularity than at the package level, a profile scheme is required.

   MSML package profiles would identify a subset of a given MSML package
   with specific definitions of elements and attributes.  Each MSML
   package profile MUST be accompanied by one or more corresponding
   schemas.  To use the examples above, there could be an audio
   announcements profile of the MSML Dialog Base Package, an audio
   simple conferencing profile of the MSML Conference Core Package, and
   a multimedia IVR profile of the MSML Dialog Base Package.

   MSML package profiles MUST be published separately from the MSML
   specification, in one or more standards documents (e.g., Internet
   Drafts or RFCs) dedicated to MSML package profiles.  Profiles would
   not be registered with IANA and any organization would additionally
   be free to create its own profile(s) if required.



(page 19 continued on part 2)

Next RFC Part