Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4722

Media Server Control Markup Language (MSCML) and Protocol

Pages: 81
Obsoleted by:  5022
Part 3 of 3 – Pages 56 to 81
First   Prev   None

ToP   noToC   RFC4722 - Page 56   prevText

10. MSCML Response Attributes and Elements

10.1. Mechanism

The media server acknowledges receipt of a client MSCML request sent in a SIP INVITE by sending a response of either 200 OK or 415 Bad Media Type. The media server responds with 415 when the SIP request contains a content type other than "application/sdp" or "application/ mediaservercontrol+xml". The media server acknowledges receipt of a client MSCML request sent in a SIP INFO with a 200 OK or 415 Bad Media Type. The media server responds with 415 if the INFO request contains a content type other than "application/mediaservercontrol+xml". The media server transports the MSCML <response> message in a SIP INFO request. If there is an error in the request or the media server cannot complete the request, the media server sends the <response> message very shortly after receiving the request. If the request is able to proceed, the <response> contains final status information as described below.

10.2. Base <response> Attributes

All MSCML responses have the basic attributes defined in the list below. Basic MSCML Response Attributes: o id - optional, no default value: Echoes the client-defined ID contained in the request. o request - required, no default value: Specifies the MSCML request type that generated the response. Allowable values are "configure_conference", "configure_leg", "play", "playcollect", "playrecord", "stop", "faxplay", "faxrecord", and "managecontent".
ToP   noToC   RFC4722 - Page 57
   o  code - required, no default value: The final status code for the
      request.  MSCML uses a subset of the status classes defined in RFC
      3261 [4].  In MSCML, 2XX responses indicate success, 4XX responses
      indicate client error, and 5XX responses indicate an error on the
      media server.  There are no 1XX, 3XX, or 6XX status codes in
      MSCML.

   o  text - required, no default value: The human readable reason
      phrase associated with the status code.

   Responses to <configure_conference> and <stop> requests contain only
   the attributes above.  MSCML responses to other requests MAY contain
   additional request-specific attributes and elements.  These are
   described in the following sections.

10.3. Response Attributes and Elements for <configure_leg>

Responses to <configure_leg> requests have only the base response attributes defined in Section 10.2. However, when the request contains a <configure_team> element, the response includes a <team> element describing the teammate configuration for that leg. The attributes of the <team> element are shown in the list below. Attributes of <team>: o id - required, no default value: The client-defined unique identifier for the conference leg. o numteam - required, no default value: The number of team members for the leg. Additional information on each team member is conveyed by child <teammate> elements contained within <team>. Each teammate is represented by a single element in the list. The <teammate> element has a single attribute, as described below. Attributes of <teammate>: o id - required, no default value: The client-defined unique identifier for the teammate leg.

10.4. Response Attributes and Elements for <play>

In addition to the base response attributes defined in Section 10.2, responses to <play> requests have the additional attributes described in the list below.
ToP   noToC   RFC4722 - Page 58
   MSCML Response Attributes for <play>:

   o  reason - optional, no default value: For requests that are not
      completed immediately, the "reason" attribute conveys additional
      information regarding why the command was completed.  Possible
      values are "stopped", indicating that an explicit or implicit
      <stop> request was received, and "EOF", indicating that the end of
      the specified sequence of URLs was reached.

   o  playduration - required, no default value: A time value (Section
      4.2.1) that returns the duration of the associated content
      playout.

   o  playoffset - required, no default value: A time value (Section
      4.2.1) that returns the time offset into the specified content
      sequence where play was terminated.  If the initial "offset" value
      in the sequence was "0", then "playduration" and "playoffset" are
      equal.  However, if the initial offset had some other value,
      "playoffset" serves as a bookmark for the client to resume play in
      a subsequent request.

10.4.1. Reporting Content Retrieval Errors

If the associated request set "stoponerror=yes" in <prompt> and an error occurred while retrieving the specified content the response will include an <error_info> element detailing the problem. This element contains the response information received from the remote content server. The <error_info> element has the attributes described in the list below. Attributes of <error_info>: o code - required, no default value: The status code returned by the remote content server. For example, a web server might return 404 to indicate that the requested content was not found. o text - required, no default value: The human-readable reason phrase returned by the remote content server. For example, the reason phrase "Not Found" would be returned if the requested content was not found. o context - required, no default value: Contains the content URL that was being fetched when the retrieval error occurred. This enables the client to know precisely which URL in a sequence caused the problem. An <error_info> element MAY be present in the response to any request that contains a child <prompt> element.
ToP   noToC   RFC4722 - Page 59

10.5. Response Attributes and Elements for <playcollect>

In addition to the base response attributes defined in Section 10.2, responses to <playcollect> requests have the additional attributes described in the list below. MSCML Response Attributes for <playcollect>: o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "match", meaning that a DTMF grammar was matched; "timeout", indicating that no DTMF input was received before one of the collection timers expired; and "returnkey" or "escapekey", meaning the DTMF digit mapped to that key was detected and the return key or escape key terminated the operation, respectively. o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event. o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request. If the caller barged the prompt this value will reflect the time offset at which barge-in occurred. o digits - required, no default value: Contains the collected DTMF input characters. If no DTMF input was collected, this attribute is set to the empty string (""). o name - required (see note), no default value: The client-defined name of the DTMF grammar that was matched. Note: This attribute is required if the "name" attribute was set in the matching DTMF grammar. Responses to <playcollect> requests MAY include an <error_info> element, as described in Section 10.4.1.
ToP   noToC   RFC4722 - Page 60

10.6. Response Attributes and Elements for <playrecord>

In addition to the base response attributes defined in Section 10.2, responses to <playrecord> requests have the additional attributes described in the list below. o reason - optional, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "digit", meaning that a DTMF digit was detected and that the prompt phase was barged; "init_silence", meaning the recording terminated because of no input; "end_silence", meaning that the recording was terminated because the "endsilence" timer elapsed; "max_duration", indicating that the maximum time for the recording was reached; "escapekey", indicating that the DTMF input mapped to "escapekey" was detected, thus terminating the recording; and "error", indicating a general operation failure. o playduration - required, no default value: A time value (Section 4.2.1) that returns the duration of the associated content playout. If the caller barged the prompt, this value will reflect the play duration up to that event. o playoffset - required, no default value: A time value (Section 4.2.1) that returns the time offset into the specified content sequence where play was terminated. If the initial "offset" value in the sequence was "0", then "playduration" and "playoffset" are equal. However, if the initial offset had some other value, "playoffset" serves as a bookmark for the client to resume play in a subsequent request. If the caller barged the prompt this value will reflect the time offset at which barge-in occurred. o digits - required, no default value: Contains the DTMF digit that terminated the recording. If no DTMF input was detected, this attribute is set to the empty string (""). o reclength - required, no default value: The length of the recorded content, in bytes. o recduration - required, no default value: A time value (Section 4.2.1) indicating the elapsed duration of the recording. Responses to <playrecord> requests MAY include an <error_info> element, as described in Section 10.4.1.
ToP   noToC   RFC4722 - Page 61

10.7. Response Attributes and Elements for <managecontent>

Responses to <managecontent> requests have only the base response attributes defined in Section 10.2. If a content transfer error occurs while executing the request the response will also contain an <error_info> element as described in Section 10.4.1.

10.8. Response Attributes and Elements for <faxplay> and <faxrecord>

In addition to the base response attributes defined in Section 10.2, responses to <faxplay> and <faxrecord> requests have the additional attributes described in the list below. o reason - required, no default value: For requests that are not completed immediately, the "reason" attribute conveys additional information regarding why the command was completed. Possible values are "stopped", indicating that an explicit or implicit <stop> request was received; "complete", indicating successful completion, even if there were bad lines or minor negotiation problems (e.g., a DCN was received); "disconnect", meaning that the session was disconnected; and "notfax", indicating that no DIS or DCS was received on the connection. o pages_received - required (see note), no default value: Indicates the number of fax pages received. Note: This attribute is required if any pages were received. o pages_sent - required (see note), no default value: Indicates the number of fax pages sent. Note: This attribute is required if any pages were sent. o faxcode - required, no default value: The value of the "faxcode" attribute is the binary-or of the bit patterns defined in Table 6.
ToP   noToC   RFC4722 - Page 62
              +------+--------------------------------------+
              | Mask | description                          |
              +------+--------------------------------------+
              | 0    | Operation Failed                     |
              | 1    | Operation Succeeded                  |
              | 2    | Partial Success                      |
              | 4    | Image received and placed in recurl  |
              | 8    | Image sent from specified source URL |
              | 16   | rmtid did not match                  |
              | 32   | Error reading source URL             |
              | 64   | Error writing recurl                 |
              | 128  | Negotiation failure on send phase    |
              | 256  | Negotiation failure on receive phase |
              | 512  | Reserved                             |
              | 1024 | Irrecoverable IP packet loss         |
              | 2048 | Line errors in received image        |
              +------+--------------------------------------+

                           Table 6: Faxcode Mask

   Responses to <faxplay> and <faxrecord> requests MAY include an
   <error_info> element, as described in Section 10.4.1.

11. Formal Syntax

The following syntax specification uses XML Schema as described in XML [7].

11.1. Schema

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="MediaServerControl"> <xs:complexType> <xs:choice> <xs:element name="request"> <xs:complexType> <xs:choice> <xs:element name="configure_conference" type="configure_conferenceRequestType"/> <xs:element name="configure_leg" type="configure_legRequestType"/> <xs:element name="play" type="playRequestType"/> <xs:element name="playcollect" type="playcollectRequestType"/> <xs:element name="playrecord" type="playrecordRequestType"/>
ToP   noToC   RFC4722 - Page 63
                 <xs:element name="managecontent"
                   type="managecontentRequestType"/>
                 <xs:element name="faxplay"
                   type="faxRequestType"/>
                 <xs:element name="faxrecord"
                   type="faxRequestType"/>
                 <xs:element name="stop" type="stopRequestType"/>
               </xs:choice>
             </xs:complexType>
           </xs:element>
           <xs:element name="response" type="responseType"/>
           <xs:element name="notification">
             <xs:complexType>
               <xs:choice>
                 <xs:element name="conference"
                   type="conferenceNotificationType"/>
                 <xs:element name="keypress"
                   type="keypressNotificationType"/>
                 <xs:element name="signal"
                   type="signalNotificationType"/>
               </xs:choice>
             </xs:complexType>
           </xs:element>
         </xs:choice>
         <xs:attribute name="version" use="required"/>
       </xs:complexType>
     </xs:element>
     <!-- Definitions for base and concrete MSCML requests -->
     <!-- and embedded types. -->
     <xs:complexType name="base_requestType" abstract="true">
       <xs:attribute name="id" type="xs:string"/>
     </xs:complexType>
     <xs:complexType name="playRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType">
           <xs:sequence>
             <xs:element name="prompt" type="promptType"
               minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="prompturl" type="xs:string"/>
           <xs:attribute name="offset" type="xs:string"/>
           <xs:attribute name="promptencoding" type="xs:string"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="configure_conferenceRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType">
ToP   noToC   RFC4722 - Page 64
           <xs:sequence>
             <xs:element name="subscribe"
               type="conference_eventsubscriptionType" minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="reservedtalkers"
             type="xs:positiveInteger"/>
           <xs:attribute name="reserveconfmedia" type="yesnoType"
             default="yes"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="configure_legRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType">
           <xs:sequence>
             <xs:element name="inputgain" type="gainType"
               minOccurs="0"/>
             <xs:element name="outputgain" type="gainType"
               minOccurs="0"/>
             <xs:element name="configure_team"
               type="configure_teamType" minOccurs="0"/>
             <xs:element name="subscribe"
               type="leg_eventsubscriptionType" minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="type">
             <xs:simpleType>
               <xs:restriction base="xs:NMTOKEN">
                 <xs:enumeration value="talker"/>
                 <xs:enumeration value="listener"/>
               </xs:restriction>
             </xs:simpleType>
           </xs:attribute>
           <xs:attribute name="mixmode">
             <xs:simpleType>
               <xs:restriction base="xs:NMTOKEN">
                 <xs:enumeration value="full"/>
                 <xs:enumeration value="mute"/>
                 <xs:enumeration value="preferred"/>
                 <xs:enumeration value="parked"/>
                 <xs:enumeration value="private"/>
               </xs:restriction>
             </xs:simpleType>
           </xs:attribute>
           <xs:attribute name="dtmfclamp" type="yesnoType"/>
           <xs:attribute name="toneclamp" type="yesnoType"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
ToP   noToC   RFC4722 - Page 65
     <xs:complexType name="configure_teamType">
       <xs:sequence>
         <xs:element name="teammate" type="teammateType" minOccurs="0"
           maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="id" type="xs:string"/>
       <xs:attribute name="action" use="required">
         <xs:simpleType>
           <xs:restriction base="xs:string">
             <xs:enumeration value="add"/>
             <xs:enumeration value="delete"/>
             <xs:enumeration value="query"/>
             <xs:enumeration value="set"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>
     </xs:complexType>
     <xs:complexType name="teammateType">
       <xs:attribute name="id" type="xs:string" use="required"/>
     </xs:complexType>
     <xs:complexType name="playcollectRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType">
           <xs:sequence>
             <xs:element name="prompt" type="promptType"
               minOccurs="0"/>
             <xs:element name="pattern" type="dtmfGrammarType"
               minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="prompturl" type="xs:string"/>
           <xs:attribute name="offset" type="xs:string"/>
           <xs:attribute name="barge" type="yesnoType" default="yes"/>
           <xs:attribute name="promptencoding" type="xs:string"/>
           <xs:attribute name="cleardigits" type="yesnoType"
             default="no"/>
           <xs:attribute name="maxdigits" type="xs:string"/>
           <xs:attribute name="firstdigittimer" type="xs:string"
             default="5000ms"/>
           <xs:attribute name="interdigittimer" type="xs:string"
             default="2000ms"/>
           <xs:attribute name="extradigittimer" type="xs:string"
             default="1000ms"/>
           <xs:attribute name="interdigitcriticaltimer"
             type="xs:string"/>
           <xs:attribute name="skipinterval" type="xs:string"
             default="6s"/>
           <xs:attribute name="ffkey" type="DTMFkeyType"/>
           <xs:attribute name="rwkey" type="DTMFkeyType"/>
ToP   noToC   RFC4722 - Page 66
           <xs:attribute name="returnkey" type="DTMFkeyType"
             default="#"/>
           <xs:attribute name="escapekey" type="DTMFkeyType"
             default="*"/>
           <xs:attribute name="maskdigits" type="yesnoType"
             default="no"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="playrecordRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType">
           <xs:sequence>
             <xs:element name="prompt" type="promptType"
               minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="prompturl" type="xs:string"/>
           <xs:attribute name="promptencoding" type="xs:string"/>
           <xs:attribute name="offset" type="xs:string" default="0"/>
           <xs:attribute name="barge" type="yesnoType" default="yes"/>
           <xs:attribute name="cleardigits" type="yesnoType"
             default="no"/>
           <xs:attribute name="escapekey" type="xs:string" default="*"/>
           <xs:attribute name="recurl" type="xs:string" use="required"/>
           <xs:attribute name="mode" default="overwrite">
             <xs:simpleType>
               <xs:restriction base="xs:NMTOKEN">
                 <xs:enumeration value="append"/>
                 <xs:enumeration value="overwrite"/>
               </xs:restriction>
             </xs:simpleType>
           </xs:attribute>
           <xs:attribute name="recencoding" type="xs:string"/>
           <xs:attribute name="initsilence" type="xs:string"/>
           <xs:attribute name="endsilence" type="xs:string"/>
           <xs:attribute name="duration" type="xs:string"/>
           <xs:attribute name="beep" type="yesnoType" default="yes"/>
           <xs:attribute name="recstopmask" type="xs:string"
             default="01234567890*#"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="managecontentRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType">
           <xs:attribute name="fetchtimeout" type="xs:string"
             default="10000"/>
           <xs:attribute name="mimetype" type="xs:string"/>
ToP   noToC   RFC4722 - Page 67
           <xs:attribute name="name" type="xs:string"/>
           <xs:attribute name="httpmethod">
             <xs:simpleType>
               <xs:restriction base="xs:NMTOKEN">
                 <xs:enumeration value="put"/>
                 <xs:enumeration value="post"/>
               </xs:restriction>
             </xs:simpleType>
           </xs:attribute>
           <xs:attribute name="action">
             <xs:simpleType>
               <xs:restriction base="xs:NMTOKEN">
                 <xs:enumeration value="move"/>
                 <xs:enumeration value="delete"/>
               </xs:restriction>
             </xs:simpleType>
           </xs:attribute>
           <xs:attribute name="dest" type="xs:string"/>
           <xs:attribute name="src" type="xs:string" use="required"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="stopRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType"/>
       </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="faxRequestType">
       <xs:complexContent>
         <xs:extension base="base_requestType">
           <xs:sequence>
             <xs:element name="prompt" type="promptType" minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="lclid" type="xs:string"/>
           <xs:attribute name="prompturl" type="xs:string"/>
           <xs:attribute name="recurl" type="xs:string"/>
           <xs:attribute name="rmtid" type="xs:string"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="dtmfGrammarType">
       <xs:choice>
         <xs:element name="regex" type="dtmfPatternType"
           maxOccurs="unbounded"/>
         <xs:element name="mgcpdigitmap" type="dtmfPatternType"/>
         <xs:element name="megacodigitmap" type="dtmfPatternType"/>
       </xs:choice>
     </xs:complexType>
ToP   noToC   RFC4722 - Page 68
     <xs:complexType name="dtmfPatternType">
       <xs:attribute name="value" type="xs:string" use="required"/>
       <xs:attribute name="name" type="xs:string"/>
     </xs:complexType>
     <!-- Definitions for base and concrete MSCML responses -->
     <!-- and embedded types. -->
     <xs:complexType name="base_responseType" abstract="true">
       <xs:attribute name="request" use="required">
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
             <xs:enumeration value="configure_conference"/>
             <xs:enumeration value="configure_leg"/>
             <xs:enumeration value="play"/>
             <xs:enumeration value="playcollect"/>
             <xs:enumeration value="playrecord"/>
             <xs:enumeration value="managecontent"/>
             <xs:enumeration value="faxplay"/>
             <xs:enumeration value="faxrecord"/>
             <xs:enumeration value="stop"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="id" type="xs:string"/>
       <xs:attribute name="code" type="xs:string" use="required"/>
       <xs:attribute name="text" type="xs:string" use="required"/>
     </xs:complexType>
     <xs:complexType name="responseType">
       <xs:complexContent>
         <xs:extension base="base_responseType">
           <xs:sequence>
             <xs:element name="error_info"
               type="stoponerrorResponseType" minOccurs="0"/>
             <xs:element name="team" type="configure_teamResponseType"
               minOccurs="0"/>
           </xs:sequence>
           <xs:attribute name="reason" type="xs:string"/>
           <xs:attribute name="reclength" type="xs:string"/>
           <xs:attribute name="recduration" type="xs:string"/>
           <xs:attribute name="digits" type="xs:string"/>
           <xs:attribute name="name" type="xs:string"/>
           <xs:attribute name="playduration" type="xs:string"/>
           <xs:attribute name="playoffset" type="xs:string"/>
           <xs:attribute name="faxcode" type="xs:string"/>
           <xs:attribute name="pages_sent" type="xs:string"/>
           <xs:attribute name="pages_recv" type="xs:string"/>
         </xs:extension>
       </xs:complexContent>
     </xs:complexType>
ToP   noToC   RFC4722 - Page 69
     <xs:complexType name="stoponerrorResponseType">
       <xs:attribute name="code" type="xs:string" use="required"/>
       <xs:attribute name="text" type="xs:string" use="required"/>
       <xs:attribute name="context" type="xs:string" use="required"/>
     </xs:complexType>
     <xs:complexType name="configure_teamResponseType">
       <xs:sequence>
         <xs:element name="teammate" type="teammateType" minOccurs="0"
           maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:attribute name="id" type="xs:string" use="required"/>
       <xs:attribute name="numteam" type="xs:integer" use="required"/>
     </xs:complexType>
     <!-- Definitions for MSCML event subscriptions and -->
     <!-- embedded types -->
     <xs:complexType name="conference_eventsubscriptionType">
       <xs:sequence>
         <xs:element name="events">
           <xs:complexType>
             <xs:sequence>
               <xs:element name="activetalkers"
                 type="activetalkersSubscriptionType"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>
       </xs:sequence>
     </xs:complexType>
     <xs:complexType name="activetalkersSubscriptionType">
       <xs:attribute name="report" type="yesnoType" use="required"/>
       <xs:attribute name="interval" type="xs:string" default="60s"/>
     </xs:complexType>
     <xs:complexType name="leg_eventsubscriptionType">
       <xs:sequence>
         <xs:element name="events">
           <xs:complexType>
             <xs:sequence>
               <xs:element name="keypress"
                 type="keypressSubscriptionType" minOccurs="0"
                   maxOccurs="1"/>
               <xs:element name="signal" type="signalSubscriptionType"
                 minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>
       </xs:sequence>
     </xs:complexType>
     <xs:complexType name="keypressSubscriptionType">
       <xs:attribute name="report" use="required">
ToP   noToC   RFC4722 - Page 70
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
             <xs:enumeration value="standard"/>
             <xs:enumeration value="long"/>
             <xs:enumeration value="both"/>
             <xs:enumeration value="none"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="maskdigits" type="yesnoType" default="no"/>
     </xs:complexType>
     <xs:complexType name="signalSubscriptionType">
       <xs:attribute name="type" type="xs:NMTOKEN" use="required"/>
       <xs:attribute name="report" type="yesnoType" use="required"/>
     </xs:complexType>
     <!-- Definitions for MSCML event notifications and -->
     <!-- embedded types. -->
     <xs:complexType name="conferenceNotificationType">
       <xs:sequence>
         <xs:element name="activetalkers"
           type="activetalkersNotificationType" minOccurs="0"/>
       </xs:sequence>
       <xs:attribute name="uniqueid" type="xs:string" use="required"/>
       <xs:attribute name="numtalkers" type="xs:string"
         use="required"/>
     </xs:complexType>
     <xs:complexType name="activetalkersNotificationType">
       <xs:sequence minOccurs="0">
         <xs:element name="talker" maxOccurs="unbounded">
           <xs:complexType>
             <xs:attribute name="callid" type="xs:string"
              use="required"/>
           </xs:complexType>
         </xs:element>
       </xs:sequence>
     </xs:complexType>
     <xs:complexType name="keypressNotificationType">
       <xs:sequence>
         <xs:element name="status" type="statusType"/>
       </xs:sequence>
       <xs:attribute name="digit" type="DTMFkeyType" use="required"/>
       <xs:attribute name="length" use="required">
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
             <xs:enumeration value="standard"/>
             <xs:enumeration value="long"/>
           </xs:restriction>
         </xs:simpleType>
ToP   noToC   RFC4722 - Page 71
       </xs:attribute>
       <xs:attribute name="method" use="required">
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
             <xs:enumeration value="standard"/>
             <xs:enumeration value="long"/>
             <xs:enumeration value="double"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="interdigittime" type="xs:string"
         use="required"/>
     </xs:complexType>
     <xs:complexType name="statusType">
       <xs:attribute name="command" use="required">
         <xs:simpleType>
           <xs:restriction base="xs:string">
             <xs:enumeration value="idle"/>
             <xs:enumeration value="play"/>
             <xs:enumeration value="collect"/>
             <xs:enumeration value="record"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="duration" type="xs:string" use="required"/>
     </xs:complexType>
     <xs:complexType name="signalNotificationType">
       <xs:attribute name="type" use="required" fixed="busy"/>
     </xs:complexType>
     <!-- Definitions for miscellaneous embedded, helper data types -->
     <xs:complexType name="promptType">
       <xs:choice maxOccurs="unbounded">
         <xs:element name="audio" type="promptcontentType"/>
         <xs:element name="variable" type="spokenvariableType"/>
       </xs:choice>
       <xs:attribute name="locale" type="xs:string"/>
       <xs:attribute name="baseurl" type="xs:string"/>
       <xs:attribute name="stoponerror" type="yesnoType" default="no"/>
       <xs:attribute name="gain" type="xs:string" default="0"/>
       <xs:attribute name="gaindelta" type="xs:string" default="0"/>
       <xs:attribute name="rate" type="xs:string" default="0"/>
       <xs:attribute name="ratedelta" type="xs:string" default="0"/>
       <xs:attribute name="repeat" type="xs:string" default="1"/>
       <xs:attribute name="duration" type="xs:string"
         default="infinite"/>
       <xs:attribute name="offset" type="xs:string" default="0"/>
       <xs:attribute name="delay" type="xs:string" default="0"/>
     </xs:complexType>
ToP   noToC   RFC4722 - Page 72
     <xs:complexType name="promptcontentType">
       <xs:attribute name="url" type="xs:string" use="required"/>
       <xs:attribute name="encoding" type="xs:string"/>
       <xs:attribute name="gain" type="xs:string" default="0"/>
       <xs:attribute name="gaindelta" type="xs:string" default="0"/>
       <xs:attribute name="rate" type="xs:string" default="0"/>
       <xs:attribute name="ratedelta" type="xs:string" default="0"/>
     </xs:complexType>
     <xs:complexType name="spokenvariableType">
       <xs:attribute name="type" use="required">
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
             <xs:enumeration value="dat"/>
             <xs:enumeration value="dig"/>
             <xs:enumeration value="dur"/>
             <xs:enumeration value="mth"/>
             <xs:enumeration value="mny"/>
             <xs:enumeration value="num"/>
             <xs:enumeration value="sil"/>
             <xs:enumeration value="str"/>
             <xs:enumeration value="tme"/>
             <xs:enumeration value="wkd"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="subtype">
         <xs:simpleType>
           <xs:restriction base="xs:NMTOKEN">
             <xs:enumeration value="mdy"/>
             <xs:enumeration value="dmy"/>
             <xs:enumeration value="ymd"/>
             <xs:enumeration value="ndn"/>
             <xs:enumeration value="t12"/>
             <xs:enumeration value="t24"/>
             <xs:enumeration value="USD"/>
             <xs:enumeration value="gen"/>
             <xs:enumeration value="ndn"/>
             <xs:enumeration value="crd"/>
             <xs:enumeration value="ord"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:attribute>
       <xs:attribute name="value" type="xs:string" use="required"/>
     </xs:complexType>
     <xs:simpleType name="yesnoType">
       <xs:restriction base="xs:NMTOKEN">
         <xs:enumeration value="yes"/>
         <xs:enumeration value="no"/>
ToP   noToC   RFC4722 - Page 73
         <xs:enumeration value="1"/>
         <xs:enumeration value="0"/>
         <xs:enumeration value="true"/>
         <xs:enumeration value="false"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="DTMFkeyType">
       <xs:restriction base="xs:string">
         <xs:pattern value="[0-9]"/>
         <xs:pattern value="[A-D]"/>
         <xs:pattern value="[a-d]"/>
         <xs:pattern value="#"/>
         <xs:pattern value="\*"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:complexType name="gainType">
       <xs:choice>
         <xs:element name="auto" type="autogainType"/>
         <xs:element name="fixed" type="fixedgainType"/>
       </xs:choice>
     </xs:complexType>
     <xs:complexType name="autogainType">
       <xs:attribute name="startlevel" type="xs:string"/>
       <xs:attribute name="targetlevel" type="xs:string"/>
       <xs:attribute name="silencethreshold" type="xs:string"/>
     </xs:complexType>
     <xs:complexType name="fixedgainType">
       <xs:attribute name="level" type="xs:string"/>
     </xs:complexType>
   </xs:schema>

12. IANA Considerations

12.1. IANA Registration of MIME Media Type application/ mediaservercontrol+xml

MIME media type name: application MIME subtype name: mediaservercontrol+xml Required parameters: none Optional parameters: charset charset This parameter has identical semantics to the charset parameter of the "application/xml" media type, as specified in XML Media Types [8]. Encoding considerations: See RFC 3023 [8]. Interoperability considerations: See RFC 2023 [8] and RFC 4722. Published specification: RFC 4722
ToP   noToC   RFC4722 - Page 74
   Applications that use this media type: Multimedia, enhanced
      conferencing and interactive applications.
   Personal and email address for further
      information: eburger@cantata.com [31]
   Intended usage: COMMON

13. Security Considerations

Because media flows through a media server in a conference, the media server itself MUST protect the integrity, confidentiality, and security of the sessions. It should not be possible for a conference participant, on her own behalf, to be able to "tap in" to another conference without proper authorization. Because conferencing is a high-value application, the media server SHOULD implement appropriate security measures. This includes, but is not limited to, access lists for application servers. That is, the media server only allows a select list of application or proxy servers to create conferences, to invite participants to sessions, etc. Note that the mechanisms for such security, like private networks, shared certificates, MAC white/black lists, are beyond the scope of this document. Security concerns are one important reason MSCML limits requests with conference scope to a separate control leg per conference. MSCML uses the simple, proven, Internet-scale security model of SIP to determine if a client is who they say they are (authentication) and if they are allowed to create and manipulate a conference. However, the security model to enable a control leg to manipulate arbitrary conferences on the media server is extremely difficult. Not only would one need to authenticate and authorize the basic conference primitives, but privacy considerations require policies for one client to access another client's conferences, even if the two clients are on the same host. For example, if the media server allowed any control leg to control any conference, an authorized but unrelated client could maliciously attach itself to an existing session and record or tap the conversation without the participant's knowledge or consent. Participants give implicit authorization to their applications by virtue of the INVITE to the application. However, there is no trust, explicit or implicit, between the users of one service and a distinct client of another service. All MSCML messages are sent within an INVITE-created SIP dialog. As a result, it would be difficult for an entity other than the original requestor to interfere with an established MSCML session, as this would require detailed information on the dialog state. This allows
ToP   noToC   RFC4722 - Page 75
   multiple applications to utilize the resources of a single media
   server simultaneously without interfering with one another.

   Because of the sensitive nature of collected data, such as credit
   card numbers or other identifying information, the media server MUST
   support sips: and TLS.  Clients, who presumably know the value of the
   information they collect, as well as the privacy expectations of
   their users, are free to use clear text signaling or encrypted secure
   signaling, depending on the application's needs.  Likewise, the media
   server SHOULD support Secure Realtime Transport Protocol (SRTP) [9].
   Again, the clients are free to negotiate the appropriate level of
   media security.

   The media management facilities of MSCML, such as the <managecontent>
   (Section 8) request, assume a trust relationship between the media
   server and file server.  This scenario is similar to the one
   addressed by URLAUTH [20].  Namely, the media server is acting on
   behalf of a given user, yet the media server does not have
   credentials for that user.  One might be tempted to use the user:pass
   facility of the HTTP URI to offer per-user security, but that also
   requires that the media server be secure, as the media server would
   need to know the user credentials in a form that is easily
   compromised (clear text passwords).

   The IETF is investigating methods for providing per-user or per-
   instance authorization of third-party http writing, as is needed for
   other protocols as well, such as WEBDAV [21].  However, until that
   work is completed, media server implementations MUST be prepared to
   authenticate themselves to file and web servers using appropriate
   authentication means.  At a minimum, the media server MUST support
   HTTPS basic authentication.  Implementers should note that the media
   server will need to respond appropriately to whatever authentication
   mechanism the file server requires.

   As this is an XML markup, all the security considerations of RFC 3023
   [8] apply.

14. References

14.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
ToP   noToC   RFC4722 - Page 76
   [4]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [5]   "Network call signalling protocol for the delivery of time-
         critical services over cable television networks using cable
         modems", ITU-T J.162, March 2001.

   [6]   Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
         Control Protocol Version 1", RFC 3525, June 2003.

   [7]   Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
         Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
         May 2001.

   [8]   Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
         RFC 3023, January 2001.

   [9]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
         3711, March 2004.

14.2. Informative References

[10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [11] Carter, J., Danielsen, P., Hunt, A., Ferrans, J., Lucas, B., Porter, B., Rehor, K., Tryphonas, S., McGlashan, S., and D. Burnett, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C REC REC-voicexml20-20040316, March 2004. [12] International Packet Communications Consortium, "IPCC Reference Architecture V2", June 2002. [13] European Telecommunications Standards Institute, "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 version 7.2.0 Release 7)", December 2005. [14] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [15] Jacobs, I., Lie, H., Bos, B., and C. Lilley, "Cascading Style Sheets, level 2 (CSS2) Specification", W3C REC REC-CSS2- 19980512, May 1998.
ToP   noToC   RFC4722 - Page 77
   [16]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
         Initiation Protocol (SIP) Event Package for Conference State",
         RFC 4575, August 2006.

   [17]  Cable Television Laboratories, Inc., "Audio Server Protocol",
         January 2005.

   [18]  "Procedures for document facsimile transmission in the general
         switched telephone network", Recommendation T.30, April 1999.

   [19]  "Procedures for real-time Group 3 facsimile communication over
         IP networks", Recommendation T.38, March 2002.

   [20]  Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH
         Extension", RFC 4467, May 2006.

   [21]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
         Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV",
         RFC 2518, February 1999.

   [22]  Institute of Electrical and Electronics Engineers, "Information
         Technology - Portable Operating System Interface (POSIX) - Part
         1: Base Definitions, Chapter 9", IEEE Standard 1003.1, June
         2001.

   [23]  Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
         Event Package for Key Press Stimulus (KPML)", RFC 4730,
         November 2006.

   [24]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
         2001.

   [25]  Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The
         Message Session Relay Protocol", Work in Progress, June 2006.

URIs

   [26]  <http://www.ietf.org/html.charters/sip-charter.html>

   [27]  <http://www.ietf.org/html.charters/sipping-charter.html>

   [28]  <http://www.ietf.org/html.charters/mmusic.html>

   [29]  <http://www.ietf.org/html.charters/xcon-charter.html>

   [30]  <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>

   [31]  <mailto:eburger@cantata.com>
ToP   noToC   RFC4722 - Page 78

Appendix A. Regex Grammar Syntax

The regular expression syntax used in MSCML is a telephony-oriented subset of POSIX Extended Regular Expressions (ERE) [22] termed Digit REGular EXpression (DRegex). This syntax was first described in KPML [23]. DRegex includes ordinary characters, special characters, bracket expressions, and interval expressions. These entities are defined in the list below. character matches digits 0-9, *, #, and A-D (case insensitive) * matches the * character # matches the # character [character selector] matches any character in selector [range1-range2] matches any character in range from range1 to range2, inclusive x matches any digit 0-9 {m} matches m repetitions of the previous pattern {m,} matches m or more repetitions of the previous pattern {,n} matches at most n (including zero) repetitions of the previous pattern {m,n} at least m and at most n repetitions of the previous pattern L the presence of 'L' in any regex expression causes the media server to enable "long" digit detection mode. See Section 7.1 for the definition of "long" digits. Table 7 illustrates DRegex usage through examples. +--------------+--------------------------------------------+ | Example | Description | +--------------+--------------------------------------------+ | 1 | Matches the digit 1 | | [179] | Matches 1, 7, or 9 | | [2-9] | Matches 2, 3, 4, 5, 6, 7, 8, 9 | | [02-46-9A-D] | Matches 0, 2, 3, 4, 6, 7, 8, 9, A, B, C, D | | x | Matches 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 | | *6[179#] | Matches *61, *67, *69, or *6# | | x{10} | Ten digits (0-9) | | 011x{7,15} | 011 followed by seven to fifteen digits | | L* | Long star | +--------------+--------------------------------------------+ Table 7: DRegex Examples
ToP   noToC   RFC4722 - Page 79

Appendix B. Contributors

Jeff Van Dyke and Andy Spitzer did the concept, development, documentation, and execution for MSCML at SnowShore Networks, Inc., which is now part of Cantata Technology, Inc. Andy Spitzer's original work at The Telephone Connection, Inc., influenced the IVR implementation. Mary Ann Leekley implemented the personalized mix feature and several other enhancements. Cliff Schornak of Commetrex and Jeff Van Dyke developed the facsimile service. Jai Cauvet, Rolando Herrero, Srinivas Motamarri, and Ashish Patel contributed greatly by testing MSCML.

Appendix C. Acknowledgements

The following individuals provided valuable assistance in the direction, development, or debugging of MSCML: o Brian Badger and Phil Crable from Verizon Business o Stephane Bastien from BroadSoft o Peter Danielsen of Lucent Technologies o Kevin Flemming, formerly of SnowShore Networks, Inc. o Wesley Hicks and Ravindra Kabre, formerly from Sonus Networks o Jon Hinckley from SkyWave/Sestro o Terence Lobo, formerly of SnowShore Networks, Inc. o Kunal Nawale, formerly of SnowShore Networks, Inc. o Edwina Nowicki, formerly of SnowShore Networks, Inc. o Diana Rawlins and Sharadha Vijay, formerly of WorldCom o Gaurav Srivastva and Subhash Verma from BayPackets o Kevin Summers from Sonus Networks o Tim Wong from at&t The authors would like to thank Cullen Jennings and Dan Wing from Cisco Systems for their helpful review comments. The authors would also like to thank Scotty Farber for applying her technical writing expertise to the documentation of MSCML.
ToP   noToC   RFC4722 - Page 80

Authors' Addresses

Jeff Van Dyke Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA EMail: jvandyke@cantata.com Eric Burger (editor) Cantata Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA EMail: eburger@cantata.com Andy Spitzer Pingtel Corporation 400 West Cummings Park Woburn, MA 01801 USA EMail: woof@pingtel.com
ToP   noToC   RFC4722 - Page 81
Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.