MEDIATRL Working Group - IETF 71 Meeting Minutes

Working Group Home Page

Chairs
        Eric Burger <eburger@bea.com>
        Spencer Dawkins <spencer@wonderhamster.org>

Scribes: James Rafferty, Keith Drage, Dan York (Jabber)

Minutes corrections by Roni Even.

Audio Archive

Jabber Archive

- Meeting Summary

We spent a lot more time on the MEDIACTRL Control Framework this time than in previous meetings, because we were expecting SIP to complete this specification (as a SIP usage), but after discussions with SIP, SIPPING, MMUSIC and relevant ADs, the specification will remain in MEDIACTRL.

The IVR package is quite solid (based on implementor experience). The conferencing package isn't as solid (not suprising, given the amount of working group time that has gone into both). The chairs will approve both documents as working group deliverables when they are revised.

Working group participants discussed holding an interoperability test as part of an upcoming MEDIACTRL working group event.

- Meeting Hums

The only hums taken were guiding the chairs on adopting the IVR package and conference package drafts as working group items.

- Agenda bash (Chairs)

We did a minor rearrangement at the end of the meeting, moving the Chair discussion of IETF 72 work plan up to ensure that we could complete the conversation face-to-face, but nothing was "squeezed out" of the meeting agenda.

- MEDIACTRL Control Framework (Scott McGlashan)      
(http://tools.ietf.org/html/draft-ietf-mediactrl-sip-control-framework-01)

Now that we're looking more seriously at this draft, we're getting better feedback...

Lorenzo has raised an issue with the 423 response and clarification on the transaction ID in the draft.

This is the first version of the draft to include a Security Considerations section - please review this section carefully.

Dan York talked about issues around multiple Media Servers and security concerns around interaction with multiple channels (especially involving hijack and misuse). Dan will send specific concerns to the list.

Lorenzo supports removal of the separate event mechanism but is concerned that we may have problems with MS starvation - do we need to add some kind of keepalive mechanism?

There are a number of references to "Transaction-Time" in the draft, but we don't have a suggested value for this. Scott suggested 10 seconds as a starting point, and then begged for working group inputs, which seemed to tend toward 5 seconds. Keith pointed out that the choice of a value depends on the action you expect to take when the timeout expires.

Simon pointed out that in the draft, the transaction timeout has the right definition at beginning, but later there is a recursive definition.

Spencer made snarky comments about the interaction between really long TCP retry behavior and much shorter application-level timers - in HTTP, we also have (user-supplied) timeouts, when the user gives up and hits "reload", so that's fine, we just need to be clear that application-level timeouts will require a TCP connection close and reopen to "clear the pipe".

We had a similar conversation around "Upper-Limit" for recommended value to be included in the 'Timeout' header of a REPORT message - the strawman suggestion was 15 seconds.

Scott asked for input from the group about "holdconn".

We removed SIP Identity and S/MIME from the framework - there are no framework-specific security requirements beyond what SIP provides.

We will confirm on-list, but the sense of the room is that we should request a default port (for convenience of firewall administrators and network troubleshooters).

We have a sense that there may be audit capabilities that would span packages (so would be lovely to add to the control framework), but we don't know what those requirements are, and we're pretty sure that packages are likely to need additional audit capabilities, anyway.

This is the biggest open issue remaining for the draft - we need to make a decision quickly (which could be to put all the audit capabilities in the packages, for now).

The authors expect to provide an updated draft within a couple of weeks, reflecting discussions at this IETF.

Jonathan pointed out that the mechanism provided in this draft does not address NAT traversal. Our on-list consensus was to address this in a separate specification.

Roni also raised an issue that we're working with the call flow documents, which are very helpful, but aren't normative, and we need to give more normative guidance about the order of messages. The specific issue Roni raised on the mailing list was whether the AS would wait for the MS to respond to its INVITE before sending a JOIN or STARTDIALOG request. This is the current text. The other option is for the AS to first send JOIN or STARTDIALOG and then the INVITE. This was discussed on the list and there was a consensus for the current text, and for making the second option illegal, but Roni still had concerns.

Roni also said that audit requirements as well as some text explaining what the MS sends in its response to the initial INVITE (since MS does not know the purpose of the INVITE), should be specified with this call flow.

- IVR (Scott McGlashan)                                                                                                          
(http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-06.txt)

Roni has been raising issues on the mailing list on a concern involving the interaction of the IVR package and SIP SDP-less INVITEs (when the AS gets to 200 OK without knowing the purpose of the INVITE).

Spencer asked the working group to carefully review Roni's concerns - as Lorenzo pointed out, there has been a long discussion on the mailing list, but it hasn't converged yet. Spencer also asked Scott and Roni to discuss in more detail, while we're in the same time zone.

We're considering adding iterations/duration to <basicivr> - if we do (and it looks like we will), can we remove this from <prompt>? If there's a use case that requires it, please say so very soon.

Dan York asked if music on hold would be an example of use case where iteration of prompt and dialog would be different.

The sense of the room supports the chairs adopting the next version of this draft as a working group item (this doesn't actually require working group consensus).

- Mixer (Scott McGlashan)                                                                                                      
(http://www.ietf.org/internet-drafts/draft-boulton-conference-control-package-04.txt)

Support for Real-Time Text is still an open issue for this package. Mary Barnes asked for quick input to XCON because XCON is close to completing their data model - if we need it, it's important that it appears in the XCON data model.

The authors would like to be pointing to XCON templates - Alan Johnston asked the authors to bring this topic to XCON, very soon.

Simon pointed out that the document should also mention interaction with the conference control package and conference control protocol.

With the exception of Real-Time Text, there aren't many remaining issues for this draft.  The sense of the room supports the chairs adopting the next version of this draft as a working group item (again, this doesn't actually require working group consensus).

- Call Flow Examples (Simon Romano)
(http://tools.ietf.org/wg/mediactrl/draft-miniero-mediactrl-escs-01.txt)

Simon was presenting the -01 version of the draft (which wasn't completed until after the Internet Draft cutoff - it was submitted during the IETF meeting).

We discussed having a separate VCR XML control element as part of IVR, and decided to ignore this possibility for now...

This turned into a very detailed discussion comparing what the package authors think the specifications say, to what the call flow authors think they say.

Scott understood the need for clarification on several points.

Is there a specific order for <prompt>, <collect>, <record>? If so, please say so soon.

The chairs are really glad we have this feedback loop... please keep implementation experience coming.

- BFCP Control Package (Lorenzo Miniero)
(http://www.ietf.org/internet-drafts/draft-miniero-bfcp-control-package-00.txt)

Lorenzo actually used his timeslot for another demonstration of the University of Napoli implementation (http://mediactrl.sourceforge.net/)  - as in Vancouver, very well received.

- IETF 72 work plan (Chairs)

In reviewing the charter milestones, we're not doing too badly. The biggest source of movement is the insertion of the MEDIACTRL Control Framework - we rely on it for the packages, but it's not a MEDIACTRL milestone.

There's a knock-on schedule effect - we've made a lot of progress on the packages, but the packages will have a normative dependency on the MEDIACTRL Control Framework, so we can't actually FINISH the packages until we FINISH the Control Framework.

The chairs will discuss with Jon-the-AD, but the way it's looking after IETF 71 is:
Spencer is still somewhat nervous about making these dates - in his opinion, we must do one of the following to make these dates:
Of these choices, the first two are preferable.