A Basic IVR Control Package for Media Control Channel Framework Chris Boulton, Tim Melanchuk, Scott McGlashan draft-boulton-ivr-control-package-06 IETF 71 Philadelphia, PA, US

12 March 2008IETF 71 - Philadelphia, PA, USA2 Overview A Media Control Channel Package providing basic IVR functionality –Play prompts, collect DTMF input, record input –Out of scope: VoiceXML, ASR, TTS, fax, media transformations Version 06 released February 2008: applied changes discussed at IETF 70 and on mailing list –see Change Summary in draft-boulton-ivr-control-package-06 Version 07 to be released April 2008 addressing outstanding issues Author request this I-D to become a MediaCtrl Work Item

12 March 2008IETF 71 - Philadelphia, PA, USA3 [IVR01] AS response to CONTROL event MS generates CONTROL message for notification events. In current spec, AS could generate framework 200 or use extended transaction framework Proposal: AS sends mandatory 200 response only

12 March 2008IETF 71 - Philadelphia, PA, USA4 [IVR21] conference/connection valid before operation Does a connection/conference id need to be valid on the MS before an operation can be performed on it? 1.Change nothing: it is an implementation issue. 2.Explicitly state that an error is raised if a join/dialogstart command contains a connectionid which is not already connected. 3.Clarify that an MS MAY implement dialogstart/join so that if a connection is not already available, execution of the operation may be queued for a short time prior to the connection being connected. 4.Clarify that an MS MUST implement dialogstart/join so that if a connection is not already available, execution of the operation is queued for a short time prior to the connection being connected. List consensus is for option 2 – any objections? We probably need to clarify (in the framework?) that media negotiation in SIP and media requirements for MS Control Package services are independent but can be addressed by other techniques (e.g. SIP SDP-less INVITEs, MS policy on connection URIs – e.g. SIP re-INVITE,

12 March 2008IETF 71 - Philadelphia, PA, USA5 [IVR02] multiple dialogs on same connection/conference Undefined behavior when more than one dialog is started on the same connection or conference. Options: 1.reject: only one dialog per connection or conference 2.replace: the current dialog is stopped and the new one started 3.queue: the new dialog is queued for starting after current dialog 4.mix: multiple dialogs are permitted with the same connection or conference: input is passed to both dialog; and dialog output is mixed 5.Depends on media streams: input can be passed to different dialogs, but only one dialog can send output to a media stream (i.e. as above but no implicit mixing) 6.Explicitly out of scope (MS policy) WG input needed.

12 March 2008IETF 71 - Philadelphia, PA, USA6 [IVR17] iterating a dialog Current spec doesn’t allow iteration of dialog Proposal: add iterations/duration to (reporting only last result) Question: if we have this, do we still need iterations/duration on as well? –Any use cases for where we need prompt iterations independent of dialog interations? If no use cases, remove iterations/duration from

12 March 2008IETF 71 - Philadelphia, PA, USA7 [IVR05] Repeating dialog and notifying DTMF collected Use case: attaching a dialog to a connection, which itself is attached to a conference, and allowing that dialog to repeatedly collect and return matching DTMF until explicitly terminated. We could add an additional mechanism to address this case: –Generic subscribe/notify mechanism? –DTMF collect specific? WG input is needed to determined if this use case is in scope for this package and how generic the solution should be.

12 March 2008IETF 71 - Philadelphia, PA, USA8 [IVR09]/[IVR10] Do we need a gender attribute? WG input needed on type and format definitions. Which types and formats need to, or can, be specified? WG input needed on how much effort should be put into this.

12 March 2008IETF 71 - Philadelphia, PA, USA9 [IVR15] Element ordering Currently child element ordering (e.g. in ) is not significant. We could make it significant so that must occur before, etc (and an error if it does not) WG input whether ordering should be significant or not?

12 March 2008IETF 71 - Philadelphia, PA, USA10 [IVR16] MS may report when in ‘promptandcollect’ and ‘promptandrecord’ modes. Proposal: Strengthen this so that the MS MUST report on all child elements.

12 March 2008IETF 71 - Philadelphia, PA, USA11 [IVR18] direction Proposal to add an ‘inactive’ value for direction (sendrecv, sendonly, recvonly). An ‘inactive’ value indicates explicitly that a stream is not to be used. Any objections?

12 March 2008IETF 71 - Philadelphia, PA, USA12 [IVR19] multiple media instances If is not specified in, then all media streams of the connection are used. How to deal with multiple instances of the same type with respect to,, ? 1.It is an error 2.MS prompts/records/collects to/from all (and mixes depending on record format) 3.MS selects one to prompt/record/collect 4.Out of scope explicitly (MS policy) WG input required.

12 March 2008IETF 71 - Philadelphia, PA, USA13 [IVR20] duration of prepared state Currently the spec doesn’t state if there is a finite duration for a dialog to stay in a prepared state (e.g. it could remain there for one year.. ). Proposal: add a specific duration (10 minutes) for dialog prepare state and that MS MUST send a notification to the AS if the duration is exceeded (and the dialog terminated)

12 March 2008IETF 71 - Philadelphia, PA, USA14 [IVR22] Resource fetching Currently, there are on limits on the time taken to fetch a resource and, in the case of HTTP, the mode and caching model. Proposal: add fetch timeout and HTTP fetching params (maxage, maxstale, method and enctype) on dialogprepare, dialogstart, and media elements

12 March 2008IETF 71 - Philadelphia, PA, USA15 [IVR23] top-level element The spec doesn’t provide a top-level element to contain request, response and notification elements. Nor does it provide an element to contain different requests (cf. and ). Proposal: add a top-level element with dialogprepare, dialogstart, dialogterminate, response and event children

12 March 2008IETF 71 - Philadelphia, PA, USA16 [IVR06] Alignment with SMIL 3.0 attributes names could be replaced with SMIL names (e.g. volume with 'soundLevel‘) We can re-use SMIL definitions (just as VoiceXML 3.0 is doing) Proposal: align attributes

12 March 2008IETF 71 - Philadelphia, PA, USA17 [IVR07] volume scaling Should volume changes in and with VCR keys use a linear or logarithmic scaling? SMIL, SSML, VoiceXML, MS, itunes, etc moving to log scaling Proposal: use log scale

12 March 2008IETF 71 - Philadelphia, PA, USA18 [IVR12] termkeys It has been proposed to add termkeys (DTMF string value) to allow termination by multiple characters (e.g. '**'). –An additional attribute would probably also be need to control interdigit timing within this string. WG input on whether this functionality required for this package?

12 March 2008IETF 71 - Philadelphia, PA, USA19 [IVR11] speed control Do we need a speed VCR control (we already have seek, volume and pause/resume)? Proposal: Yes (if we’ve gone this far with VCR behavior in this package …).

12 March 2008IETF 71 - Philadelphia, PA, USA20 [IVR13] nesting One drawback of using with an inline custom grammar is that nested elements are needed for SRGS: i.e. custom element and inside that a element in the SRGS namespace. The alternative would be –(a) element is only for external grammars, and –(b) inline grammars are specified as children of (with suitable co-occurrence restrictions) WG feedback is required to determined if the nesting is confusing or not.

12 March 2008IETF 71 - Philadelphia, PA, USA21 [IVR03] status codes Do we need more or less status codes? Proposal: simplify syntax errors (one code for invalid elements, attributes and values). Any new codes required?

12 March 2008IETF 71 - Philadelphia, PA, USA22 [IVR04] error codes for Do we need to specify more error codes for ? Currently: 0 for terminated, 1 for success, anything else for failure. Proposal: leave failure codes undefined

12 March 2008IETF 71 - Philadelphia, PA, USA23 [IVR08] DTMF for VCR does not stop prompts Clarify that DTMF used for VCR controls does not cause playback to be stopped, but causes the appropriate operation to be applied to the playing prompts Any objections?

12 March 2008IETF 71 - Philadelphia, PA, USA24 [IVR14] RelaxNG Schema We could provide a RelaxNG schema which provides better support for co- occurrence constraints than XML schema (but less good type constraints). WG input on whether anyone wants/needs such a schema?

12 March 2008IETF 71 - Philadelphia, PA, USA25 BACKUP

12 March 2008IETF 71 - Philadelphia, PA, USA26 Examples Simple use case: 1.IVR dialog to record participant name 2.Add participant to conference 3.IVR dialog to announce participant to conference Simplifications: –AS-MS control channel has been established (and SYNCHed) with support for msc-ivr-basic/1.0 and msc-conf- audio/1.0 –Conference already created with conf-id ‘conf1’ –Participant connection-id ‘p1’ is shorthand for

12 March 2008IETF 71 - Philadelphia, PA, USA27 IVR dialog to record participants name 1/3 AS > MS SCFW transaction1 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Length: 92

12 March 2008IETF 71 - Philadelphia, PA, USA28 IVR dialog to record participants name 2/3 AS < MS SCFW transaction1 200 Content-Length: 92

12 March 2008IETF 71 - Philadelphia, PA, USA29 IVR dialog to record participants name 3/3 AS < MS SCFW transaction2 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Length: 92 AS > MS SCFW transaction2 200

12 March 2008IETF 71 - Philadelphia, PA, USA30 Add participant to conference 1/1 AS > MS SCFW transaction3 CONTROL Control-Package: msc-conf-audio/1.0 Content-Length: 42 AS < MS SCFW transaction3 200 Content-Length: 22

12 March 2008IETF 71 - Philadelphia, PA, USA31 IVR dialog to announce participant to conference 1/3 AS > MS SCFW transaction4 CONTROL Control-Package: msc-ivr-basic/1.0 Content-Length: 94

12 March 2008IETF 71 - Philadelphia, PA, USA32 IVR dialog to announce participant to conference 2/3 AS < MS SCFW transaction4 202 Timeout:10 AS < MS CFW transaction4 REPORT Status: terminate AS > MS SCFW transaction4 200

12 March 2008IETF 71 - Philadelphia, PA, USA33 IVR dialog to announce participant to conference 3/3 AS < MS SCFW transaction5 CONTROL AS > MS SCFW transaction5 200

12 March 2008IETF 71 - Philadelphia, PA, USA34 Proposal: Basic IVR as MediaCtrl WG item Implementation experience Satisfies MediaCtrl WG requirements and IVR design team requirements Satisfies Media Control Channel Framework requirements for Control Package –draft-ietf-mediactrl-sip-control-framework-01 Compatible with other proposed packages (non-WG) –VoiceXML IVR (draft-boulton-ivr-vxml-control-package-04) –Conference control (draft-boulton-conference-control- package-04) ID editors will actively revise document following WG input