MEDIACTRL Minutes
IETF 73,
Thursday, 9:00am - 11:30am CT
Eric Burger and Spencer Dawkins, Chairs
Adam Uzelac and Keith Drage, Scribes
ACTIONS
=======
Dan or Steve to post how to do fallback video in a VoiceXML script to the list.
Participants MUST send text to the list for RFC 2119 language where we today have SHOULD and you would like to keep the SHOULD. The document editors MAY choose what to do with existing RECOMMENDED/SHOULD/MAY in the text if they do not hear from you soon.
Framework, IVR, and Mixer documents' editors need to update the respective document's Security Considerations to cover issues raised in Dan's e-mail, such as protecting transport and issues surrounding audit. Moreover, framework document needs to identify issues that packages need to address.
Framework needs to clarify what happens if the control channel fails, if the framework document does not specify that already.
Revise MRB; chose a proposal for state updates and query mechanism.
Reminders
=========
Interim in
SIPit 24 in
Detailed Notes
==============
Control Framework - Shepherd's review
-------------------------------------
IVR Control presented by Chris Boulton
--------------------------------------
Open Issue 'fallback video' - Chris is looking for a yes or no, looking for decision. Steve Buko - he's ok with this, but would like to think it through more clearly. Feels much more thought. This sentiment agrees with the previous speaker.
Steve: Adds complexity beyond what is worth it.
Alan: If put this in, could add a lot of non-determinism.
Chris generally agrees, and wondered if there is a need for the control agent to know when the MS fails back.
Lorenzo agrees with Steve, needs more thinking.
Scott (via jabber) states that a feedback element is needed.
Stephan from Broadsoft - states that this has been part of their solution currently.
Stephan is strongly in favor.
Dan York notes that we are in WGLC, and adding this now would delay the release.
Steve Buko - this is reviewing the basic IVR package. There is not a need to include everything at this time. Can add feature functionality at a later point in time.
Scott points out that this is achieveable via XML.
Spencer wants this to go to mailing list for ultimate decision.
Spencer asks for a hum - those in favor of delaying. NO hums to delay. Continuation on the mailing list on how this will need to be achieved.
Chris - Conformance language next - the language was changed to be more explicit. Any objections?
Lorenzo asks for clarification about the MUST around 'support parallel recording. of different media'
Dan York, Keith Drage make the point that SHOULDs should be removed. - take to the list slide 6 from the PPT.
Scott - points out that this data is already on the list - folks should read and reply.
Mary Barnes points out that Gen-ART points out that you need to be careful using with 'MUSTS'.
Keith points out that we need to be careful with both 'SHOULDs' and 'MUSTs', but generally speaking SHOULDs are a cop-out.
Martin Dolly echoes the sentiment that we need MUSTS
Mary - counters that SHOULDs have a place and purpose.
Dan York points out that we need more stringent requirements for interop.
WG Chairs - as much as possible, you must use MUST.
Keith Drage - if there really are other options, then just use MAY, instead of SHOULDs.
Mary - needs to be careful with MUSTS. We need to have flexibility where we _really_ need it.
Next slide - Security review - do we really need this?
Dan York states the major issues - really need to emphasize that transport needs to be protected and authenticated.
Scott - how many are these are the framework level?
Dan York - can be at the framework level, as well as generally about SIP.
Mary - based on past experience, you need to be very explicit in this document.
Keith Drage - the template should contain some of these considerations.
Lorenzo - there are situations where some of the circumstances that the security mechanisms would prevent functionality.
Dan - agrees, with Lorenzo, but need to provide guidlines
Mary - maybe request an early review from Security Director on the IVR package.
Spencer agrees and notes that this was done for the Control Framework.
- Lorenzo presents 'Implementation Reports'
============================================
As a result of some interop tests, there is some ambiguity, and proposes a changes in the framework to the spec.
Chris Boulton believes this is already in the latest update of the framework.
Lorenzo states that this interop was done on previous versions.
Steve Buko - states that when the TCP connection is destroyed in this interop, the call wasn't brought down. There is clarification needed in the Control Framework.
Stephan has the same issue.
WE need to clarify what happens if the transport for the control channel fails- needs to be discussed on the list.
Chris Boulton - feels there's already text covering this, but may need to be changed a bit.
Stephan notes that implemenation is be planned on Broadsoft for the spring.
Alan notes that Ditech is also planning an implementation.
Lorenzo - Interop event could be useful.
- Chris Boulton on MRB. Media Resource Brokering
=========================================================
Need to include a sentence on SNMP, anticipating the question later on.
There should be some consideration to using REST.
Alan likes that it's good due to it being light. He's in favor.
Simon - why not use UDDI for this.
HTTP versus REST - the fact that a proxy might be in the mix might cause some problems.
Alan - it's always a consideration, but it's typically going to be used in a controlled environment. But these are for the most part, have already been considered.
Overall, this should be discussed more on the mailing list.
Eric at the mic - this will already have a SIP stack and Control Framework, so it really needs to be considered.
Must be taken to the list!
Eric - need to consider making the audit capabilities in an independent way.
Eric - this is a WG item. Deliverable #4. Question - is this document ready to be the basis for this WG item?
Eric - of the people that have read it, in the light of gathering input, who's OK with using this as a starting point for the WG item?
Scott via jabber thinks it's good.
Eric - would like to see one more round as an Individual draft before making a WG item.
- Interop and testing at Interim
=========================================
Eric - there is a chance that it might meltdown - just a chance.
Interop event BEFORE/After the
meeting, in
Another option could be SIPit in
May (
Feel in the room - will folks have stuff to Interop? The question will be posed on the list. Looking for more implementations.
Lorenzo points out that partial implementations would still be helpful.
Decision that the Broker Protcol/MRB - will be a standards track document.
Voice XML draft - the WG Chair (Eric) needs to write a paragraph, and it's on his todo list.
It's the opinion of the chairs that this WG will be complete by the end of IETF 74.
Steve Buko - there were some issue with the call flow document.
Eric - DOH! that's right. This should be a deliverable, over mild chair objection.
We would like to take a 'hum' to add a milestone of call flows. All in favor, none opposed.
Dan York asked about addressing new extensions, etc once the WG closes
Eric - points out that RAI works a little different then then the others areas.
Mary - after the RAI Open Meeting, RAI will probably work more like the other areas where this WG will close, and a new WG would get done.
Keith - no consensus was met at the RAI Open meeting.
Mary - the intention was there and the ADs wouldn't be upset if this was closed.
Eric - proposes that we will target closing the WG after 75 due to the call flow doc. He points out that the once the WG is closed, mailing list would still be open.