MEDIACTRL IETF 70 Minutes

Working Group Home Page - http://tools.ietf.org/wg/mediactrl/

Co-chairs
    Eric Burger <mailto:eburger@bea.com>
    Spencer Dawkins <mailto:spencer@mcsr-labs.org>

Reading List
    http://tools.ietf.org/id/draft-ietf-mediactrl-requirements-01.txt
    http://tools.ietf.org/id/draft-ietf-mediactrl-architecture-01.txt
    http://tools.ietf.org/id/draft-ietf-mediactrl-vxml-00.txt
    http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-05.txt
    http://tools.ietf.org/wg/mediactrl/draft-miniero-mediactrl-escs-00.txt

These minutes were taken from Ted Hardie's minutes and Dan York's Jabber Log. The chairs appreciate their assistance to the working group.

Chair Status - chairs

Spencer reviewed working group mechanics, focusing especially on topics that have come up during the shepherding process for the Requirements and Architecture drafts on their way to the IETF.

Finishing Requirements - chairs

Jon has provided comments on the document, and the chairs have sent these comments to the list. Most are straightforward, but a couple require working group attention.

The document says "at least one control channel, and may be more", but doesn't say why more than one control channel would be useful. Roni correctly captured the sense of the working group, but this was an effort to be agnostic in a religious war - not enough, as Jon points out.

Spencer and Eric can think of two reasons - you have one control channel per session, or you have two control channels in a multihoming environment for redundancy.

Since Jon has also asked about transport independence. Spencer encouraged the group to consider SCTP to support redundent control channels (in contrast to "transport independence", which the draft currently specifies), but please "pick one way". Is everyone OK if we use SCTP for redundancy? (CHAIRS: to poll on-list).

Jon asked the working group to consider whether we NEED transport independence. (CHAIRS: to poll on-list)

Roni and Dan York pointed out that these topics could be deferred into the architecture draft. The chairs agree.

Eric as individual noted that the draft talks about a reliable channel/secure channel between application server and media server.  There are some issues to think through in distinguishing between failover case and inappropriate transition, and authentication to control a session needs to be addressed in order to manage access control.

We discussed co-location of the FCS  with the AS vs. MS. We noted that 3gpp is heading toward co-locating FCS with MS, but there's also a request in the room to describe the FCS-colocated-with-AS case (even if that is simpler than the FCS-MS case).

Dan York noted that multiple-to-multiple relationships complicated the security considerations.

The sense of the room is that the architecture draft needs to go back for a second WGLC, based on additional security considerations.

Discussion of draft-miniero-mediactrl-escs-00.txt - Simon Romano

Simon gave a very useful presentation on the state machine that his group used in implementing a pre-MEDIACTRL demonstration, and demonstrated (with call flows and with a prototype implementation) several scenarios.

These are the questions that came up during implementation:

Is 202 needed, as it always followed by a report?

Is there an ambiguity between notify/update, given the possible states in REPORT messages?

Should notify/update events be possible *after* a terminate?

Since error messages cannot carry any payload, how are package-specific errors notified?  Should they use the 200 message or the report/terminate message for this?  Chris notes that the logic intended was that the package error semantics were meant to be separate; so a 200 ok can go back with a high-layer error, and Spencer stated that we need to distinguish clearly between transport success/failure and application success/failure.  The room agreed that the language may need clean-up here.

The working group applauded the effort of bringing the work forward ("this is invaluable work").

Since the call flows in this document have to match the protocol docs, and the content of the protocol docs will be a moving target for some time to come, the chairs encouraged the draft authors to continue their work, but we will not poll the workgroup on adopting this draft as a working group draft.

The demo code will be at http://mediactrl.sourceforge.net/.

IVR Package - Scott McGlashan

The group reviewed the IVR basic package  (prompts, dtmf, recording, rather than voicexml, asr, tts, fax, meda). 

Remainging issues were reviewed:  some are xml issues; some are questions of scope (should custom dtmf grammar be supported?
should video playback be supported?)

Dan York asked whether there was a benefit to having this being an independent flavor of XML,
 
There were several scope questions discussed:
Brian Rosen says "as a practical matter" this must be supported. 

Roni asks if we have the mechanism to query whether a media server supports specific media?  That is,  do we need to have a mechanism for discovering support for non mandatory media.

Spencer asked if it was sufficient to support these media types in signaling and simply "don't offer/don't accept" media types you don't support.

There was some discussion about whether we've added enough complexity to the basic IVR package that people should simply use VXML. The consensus in the room is that we haven't added that much complexity.

Lorenzo asked if we can have a single prepared dialog that is reused multiple times. This was the reason for the "prepare" model in the document.
 
The chairs asked for a sense of the room on making this a working group deliverable as the basis for the relevant deliverable.  There was discussion in the room about the implementation complexity of voiceXML vs. this subset.  Several speakers noted that they are already supporting voiceXML and that the perceived gains in implementation simplicity were not that large.

Next Steps - all

The working group reviewed the committed milestone dates. We corrected one error and updated a small number of milestones, but the chairs believe the working group is still on track and making progress.

MEDIACTRL discussed holding an interim meeting, and decided that this will not be necessary between IETF 70 and IETF 71 (especially due to the short interval between these two IETFs - by Spencer's count, there are 10 weeks until 00 cutoff, and that's including a large number of holidays).