An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework
updated by
- rfc-6623 — IANA Registry for MEDIACTRL Interactive Voice Response Control Package
Extracted elements (30)
The IVR dialog language is intentionally a lightweight subset of VoiceXML, omitting advanced constructs such as <form>, its interpretation algorithm, and a dynamic data model. This provides a familiar foundation for IVR developers while remaining sufficient for most applications, with a clear migration path to richer languages like VoiceXML for advanced use cases.
The two-phase prepare/start model (<dialogprepare> followed by <dialogstart>) was chosen to allow pre-fetching and validation of external dialog documents and media resources before the dialog is activated on a connection or conference, reducing latency at dialog start time.
VoiceXML can be used as an external dialog language by referencing it via a src URI with type 'application/voicexml+xml'. Section 9 defines how session protocol, media stream, and parameter information are mapped to VoiceXML session variables, and how VoiceXML exit information is conveyed in the <dialogexit> event.
If an MS encounters a media type or codec it cannot process during dialog execution, the MS MUST stop further processing and report the error using the dialogexit notification.
In <dialogstart>, exactly one of the connectionid or conferenceid attributes MUST be specified. If both or neither are specified, the MS sends a <response> with a 400 status code.
The <dialogexit> event MUST be sent by the MS when the dialog exits, whether due to normal completion, a <dialogterminate> request, or an execution error.
The MS implementation MUST adhere to the dialog lifecycle shown in Figure 1. Dialog notifications MUST NOT be sent for a dialog in the TERMINATED state.
The MS MUST respond to a request message with a response message. If the MS cannot process the request, it MUST indicate the class of failure using an appropriate 4xx response code.
The MS MUST support both HTTP and HTTPS protocol schemes for fetching and uploading resources referenced by URI attributes in elements such as <dialogprepare>, <dialogstart>, <media>, <grammar>, and <record>. The MS MAY support other schemes.
The MS MUST support <dtmfsub> subscription for the IVR dialog language. It MAY support other dialog subscriptions specified using foreign namespace attributes; if unsupported, the MS sends a 431 status code.
The MS MUST support the inline IVR dialog language defined in Section 4.3. The MS MAY support other dialog languages by reference.
When multiple media streams of the same type are associated with a dialog, the AS MUST use <stream> elements to explicitly specify the configuration.
When the dialog is in the PREPARED state and the maximum preparation duration is exceeded, the MS MUST send a dialogexit notification with the appropriate error status code. A maximum preparation duration of 300s is RECOMMENDED.
When the MS sends event notifications as a Control Client, the AS MUST respond with a Control Framework 200 response.
The <audit> element requests the MS to report its capabilities and active dialogs. The <auditresponse> element returns codec support (<codecs>), package capabilities (<capabilities> including supported dialog languages, grammar types, record types, prompt types, and variable types), and active dialog information (<dialogs>).
The <collect> element configures DTMF collection, with attributes including maxdigits, timeout, interdigittimeout, termchar, and bargein. A <grammar> child element can specify an inline or external DTMF grammar. Results are reported in <collectinfo> with dtmf and termmode attributes.
The <control> element defines runtime (VCR-style) DTMF controls for prompt playback, with attributes including ffkey (fast-forward), rwkey (rewind), volupkey, voldnkey, pausekey, resumekey, and skipinterval. Results are reported in <controlinfo> with <controlmatch> child elements.
The <dialog> element is the IVR dialog execution container supporting child elements <prompt>, <control>, <collect>, and <record>. The 'repeatCount' (default 1), 'repeatDur', and 'repeatUntilComplete' (default false) attributes govern iteration behavior; repeatDur takes priority over repeatCount.
The <dialogexit> event element reports dialog termination with a mandatory 'status' attribute (0=terminated by request, 1=successful, 2=connection terminated, 3=max duration exceeded, 4=execution error). The AS MUST treat unrecognized status codes as equivalent to 4.
The <dialogprepare> element requests the MS to retrieve and validate an external dialog document or inline <dialog> element. Key attributes include src (URI), type (MIME type), fetchtimeout (default 30s), and optional dialogid. Specifying both inline <dialog> and src is a syntax error (400).
The <dialogstart> element starts a dialog on a specified connection or conference. Exactly one of src, prepareddialogid, or inline <dialog> must be specified. Optional child elements include <subscribe>, <params>, and <stream>. Specifying prepareddialogid together with dialogid is a syntax error.
The <dtmfsub> element subscribes to DTMF notifications during dialog execution. The 'matchmode' attribute (default 'all') controls whether all key presses, only collect-matched input, or only control-matched input are reported via <dtmfnotify> events bearing dtmf and timestamp attributes.
The <mscivr> root element wraps all package messages. Its mandatory 'version' attribute is fixed at '1.0'. It contains exactly one child element: a dialog management element (<dialogprepare>, <dialogstart>, <dialogterminate>, <response>, or <event>) or an audit element (<audit> or <auditresponse>).
The <record> element specifies media recording behavior with attributes including maxtime, beep, finalsilence, dtmfterm, and format. Results are reported in <recordinfo> containing one or more <mediainfo> child elements with codec and duration details.
Section 8.5 establishes the 'IVR Prompt Variable Type' IANA registry for prompt variable types (e.g., date, time, digits). New entries require Standards Action. The registry captures type name, description, and format details.
This document registers the Control Package name 'msc-ivr/1.0' in the IANA Media Control Channel Framework Control Package registry, the URN sub-namespace 'urn:ietf:params:xml:ns:msc-ivr', the XML schema, and the MIME media type 'application/msc-ivr+xml'.
Section 7 mandates that implementations address security by leveraging the Media Control Channel Framework's TLS-based transport security for control messages, and by using HTTPS for fetching external dialog documents and media resources. Authentication credentials (certificates, passwords) SHOULD be stored as part of MS configuration rather than transmitted in requests.
The package carries dialog content including media URIs and DTMF collection results; unauthorized access could expose sensitive user input (e.g., PINs). Implementations MUST adhere to the security considerations of RFC 6230 and MUST support HTTPS to protect media resource access.
Each IVR dialog follows a defined lifecycle with states IDLE, PREPARING, PREPARED, STARTING, STARTED, and TERMINATED. Transitions are triggered by <dialogprepare>, <dialogstart>, <dialogterminate> requests, 200 responses, dialogexit notifications, and error conditions. Once TERMINATED, the dialog identifier is no longer valid.
All package messages are carried as XML with the MIME media type 'application/msc-ivr+xml'. The root element is always <mscivr version='1.0' xmlns='urn:ietf:params:xml:ns:msc-ivr'>. Request bodies are sent in CONTROL messages; response and audit-response bodies in REPORT messages or 200 responses; event notifications in CONTROL messages from the MS.