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 2008 IETF 71 - Philadelphia, PA, USA 2

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 2008 IETF 71 - Philadelphia, PA, USA 3

[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 2008 IETF 71 - Philadelphia, PA, USA 4

[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. audioivrprofile@ms.example, SIP re-INVITE, etc).

12 March 2008 IETF 71 - Philadelphia, PA, USA 5

[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 dialog4. 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 2008 IETF 71 - Philadelphia, PA, USA 6

[IVR17] iterating a dialog

• Current spec doesn’t allow iteration of dialog• Proposal: add iterations/duration to <basicivr>

(reporting only last result)• Question: if we have this, do we still need

iterations/duration on <prompt> as well? – Any use cases for where we need prompt

iterations independent of dialog interations?

• If no use cases, remove iterations/duration from <prompt>

12 March 2008 IETF 71 - Philadelphia, PA, USA 7

[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 2008 IETF 71 - Philadelphia, PA, USA 8

[IVR09]/[IVR10] <variable>

• 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 2008 IETF 71 - Philadelphia, PA, USA 9

[IVR15] Element ordering

• Currently child element ordering (e.g. in <basicivr>) is not significant. We could make it significant so that <prompt> must occur before <collect>, etc (and an error if it does not)

• WG input whether ordering should be significant or not?

12 March 2008 IETF 71 - Philadelphia, PA, USA 10

[IVR16] <promptinfo>

• MS may report <promptinfo> when in ‘promptandcollect’ and ‘promptandrecord’ modes.

• Proposal: Strengthen this so that the MS MUST report on all child elements.

12 March 2008 IETF 71 - Philadelphia, PA, USA 11

[IVR18] <stream> 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 2008 IETF 71 - Philadelphia, PA, USA 12

[IVR19] multiple media instances

• If <stream> is not specified in <dialogstart>, then all media streams of the connection are used. How to deal with multiple instances of the same type with respect to <prompt>, <record>, <collect>?1. It is an error2. 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 2008 IETF 71 - Philadelphia, PA, USA 13

[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 2008 IETF 71 - Philadelphia, PA, USA 14

[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 2008 IETF 71 - Philadelphia, PA, USA 15

[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. <response> and <event>).

• Proposal: add a top-level <msc-ivr-basic> element with dialogprepare, dialogstart, dialogterminate, response and event children

12 March 2008 IETF 71 - Philadelphia, PA, USA 16

[IVR06] Alignment with SMIL 3.0

• <prompt> 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 2008 IETF 71 - Philadelphia, PA, USA 17

[IVR07] volume scaling

• Should volume changes in <prompt> 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 2008 IETF 71 - Philadelphia, PA, USA 18

[IVR12] <collect> 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 2008 IETF 71 - Philadelphia, PA, USA 19

[IVR11] <collect> 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 2008 IETF 71 - Philadelphia, PA, USA 20

[IVR13] <grammar> nesting

• One drawback of using <grammar> with an inline custom grammar is that nested <grammar> elements are needed for SRGS: i.e. custom <grammar> element and inside that a <grammar> element in the SRGS namespace. The alternative would be – (a) <grammar> element is only for external grammars, and – (b) inline grammars are specified as children of <collect>

(with suitable co-occurrence restrictions)

• WG feedback is required to determined if the nesting is confusing or not.

12 March 2008 IETF 71 - Philadelphia, PA, USA 21

[IVR03] <response> status codes

• Do we need more or less <response> status codes?

• Proposal: simplify syntax errors (one code for invalid elements, attributes and values). Any new codes required?

12 March 2008 IETF 71 - Philadelphia, PA, USA 22

[IVR04] error codes for <dialogexit>

• Do we need to specify more error codes for <dialogexit>? Currently: 0 for terminated, 1 for success, anything else for failure.

• Proposal: leave failure codes undefined

12 March 2008 IETF 71 - Philadelphia, PA, USA 23

[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 2008 IETF 71 - Philadelphia, PA, USA 24

[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 2008 IETF 71 - Philadelphia, PA, USA 25

BACKUP

12 March 2008 IETF 71 - Philadelphia, PA, USA 26

Examples

• Simple use case:1. IVR dialog to record participant name2. 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

“HKJDH~8shKUHSUKHW@example.com~JJSUSHJ”

12 March 2008 IETF 71 - Philadelphia, PA, USA 27

IVR dialog to record participants name 1/3

AS --------------------------------------------------------------------------> MSSCFW transaction1 CONTROL Control-Package: msc-ivr-basic/1.0Content-Length: 92

<dialogstart connection-id=“p1"> <basicivr> <prompt> <media src="http://ex.com/sayname.wav"/> </prompt> <record dtmfterm=“true” maxtime=“30s”/> </basicivr></dialogstart>

12 March 2008 IETF 71 - Philadelphia, PA, USA 28

IVR dialog to record participants name 2/3

AS <-------------------------------------------------------------------------- MSSCFW transaction1 200Content-Length: 92

<response status=“200” dialogid=“d1”>

12 March 2008 IETF 71 - Philadelphia, PA, USA 29

IVR dialog to record participants name 3/3

AS <------------------------------------------------------------------------- MSSCFW transaction2 CONTROL Control-Package: msc-ivr-basic/1.0Content-Length: 92

<event dialogid=“d1”> <dialogexit status=“1”> <recordinfo termmode=“dtmf”

recording="http://ex.com/recording1.wav"/> </dialogexit></event>

AS -------------------------------------------------------------------------> MSSCFW transaction2 200

12 March 2008 IETF 71 - Philadelphia, PA, USA 30

Add participant to conference 1/1

AS --------------------------------------------------------------------------> MSSCFW transaction3 CONTROL Control-Package: msc-conf-audio/1.0 Content-Length: 42

<join id1=“p1” id2=“conf1”/>

AS <-------------------------------------------------------------------------- MSSCFW transaction3 200Content-Length: 22

<response status=“200” conferenceid=“conf1”/>

12 March 2008 IETF 71 - Philadelphia, PA, USA 31

IVR dialog to announce participant to conference 1/3

AS --------------------------------------------------------------------------> MSSCFW transaction4 CONTROL Control-Package: msc-ivr-basic/1.0Content-Length: 94

<dialogstart conferenceid=“conf1"> <basicivr> <prompt> <media src="http:/ex.com/recording1.wav”/> <media src=“http://ex.com/hasjoined.wav"/> </prompt> </basicivr></dialogstart>

12 March 2008 IETF 71 - Philadelphia, PA, USA 32

IVR dialog to announce participant to conference 2/3

AS <-------------------------------------------------------------------------- MSSCFW transaction4 202Timeout:10

AS <-------------------------------------------------------------------------- MSCFW transaction4 REPORT Status: terminate

<response status=“200” dialogid=“d2”/>

AS --------------------------------------------------------------------------> MSSCFW transaction4 200

12 March 2008 IETF 71 - Philadelphia, PA, USA 33

IVR dialog to announce participant to conference 3/3

AS <------------------------------------------------------------------------- MSSCFW transaction5 CONTROL

<event dialogid=“d2”> <dialogexit status="1"/></event>

AS -------------------------------------------------------------------------> MSSCFW transaction5 200

12 March 2008 IETF 71 - Philadelphia, PA, USA 34

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