MEDIACTRL meeting – IETF 76

 

Working Group Home Page

 

Chairs:

Eric Burger <eburger@standardstrack.com>

Spencer Dawkins <spencer@wonderhamster.org>

 

Scribe:

Leon Portman <leon.portman@nice.com>

 

Jabber Scribe:

            Jim McEachern <jmce@nortel.com>

Agenda Bash

 

Spencer and Eric made a fairly dramatic change in the agenda – doing call flows first, showing the updated call flows to summarize changes resulting from recent changes to the Control Framework draft (m-line using “tcp” as the protocol, connection-id token ), and then moving on to MRB discussions.

Call Flows

Lorenzo Miniero

 

http://tools.ietf.org/html/draft-ietf-mediactrl-call-flows-02

 

This document is current with Control Framework and the IVR and MIXER packages, including latest changes to m-line and connection-id token, and the authors have added section on MRB, but this part isn’t current with the most recent MRB draft. The call flows draft will be updated again after development of the MRB consumer interface.

 

Lorenzo pointed out that the MRB draft doesn’t include a mechanism to STOP receiving notifications – suggest that the MRB draft change to provide such a mechanism.

 

No questions for the authors.

 

IVR & Mixer

 

Eric Burger – anything for IVR and Mixer? No comments.

MRB

 

Lorenzo Miniero.  Want to achieve complete definition of the interfaces. Working on the consumer interface. Waiting for feedback from the mailing list.

 

Publish interface: defined the control package. Already implemented. Question from Lorenzo Miniero:  only generic subscription. Is complete information always required?

 

Question. Who read the draft? Couple of hands (chairs mostly)

 

Eric Burger: Who will build MRB? Alan Johnson: not sure

 

Do we need to filter events? Gary doesn’t think so. Lorenzo thinks it might be useful. Chris thinks it would be useful, but not pushing. Leave it as is?

 

Spencer – we should not add anything without requirements from the group.

 

Filters are not needed from the publishing interface. Lorenzo Miniero – might be useful.

 

Eric Burger: complex syntax will be required

 

Eric Burger: Chris Boulton says nice to have (filters) but happy to move on if no desire from the group. Agreed by the group

 

Lorenzo Miniero: it is a technical question for the future discussions

 

Lorenzo Miniero. Looking to close open issues in the publisher protocol.

 

<Mixing-modes> – audio and video.

 

Is it OK to support for video only for layout? Default layouts? Any questions?

 

Spencer – any reason not to reuse mixer package?

 

Roni Even: why not to do the same? We’re reporting the same resource as the mixer. Not supposed to be different.

 

Everybody agreed to reuse.

 

<Supported-tones>

 

 Media server to support different characteristics of the tones (different countries etc.).  Who has expertise?

 

Eric Burger: We need to find volunteer with expertise. Supporting country specific tones is mandatory requirement. Will keep it open (will not be addressed in this meeting). Will ask who has the expertise on the mailing list. Chair Action.

 

<asr-tts-support>

 

Which languages? Expert volunteer? ISO 639-1 codes proposed?

 

Chairs: right thing to do is to support ISO 639-1. Separate ASR&TTS languages sets.

 

<media-server-location>

 

Country/State codes proposed. Need volunteer to write this up.

 

Need finer support (civic address path). Like in Geopriv for location object (for reuse). Chris Boulton asked : who is the contact. Robert will broker this discussion. Chair Action.

 

<encryption>

 

Indicates that MS supports encryption. Is a Boolean sufficient to indicate support for SRTP? Or state actual keying mechanism?

 

Eric Burger: anybody cares? Silence

 

Spencer: cost of doing simple indicator is small. Or we need to plan for the date when it will be wrong answer? SRTP as media encryption solution for foreseeable future?

 

Jon: Boolean support is fine, that’s what we have in SDP (the underlying protocol) anyway.

 

Eric Burger – for simplicity we will say yes.

 

Spencer – we should not be more specific than underlying protocol.

 

Decided for simple solution (bool)

 

Consumer Interface

 

Publishing interface as input.

 

What is missing?

 

Consumer interface with <requires> and <optional> elements for query.

 

Does everybody agree?

 

Chris Boulton says – approach looks good

 

Everybody agrees.

 

Required packages

 

Is it OK? Do we need more information?

 

Looks fine to the room.

 

<session-info>

 

Provides optional session information. Lorenzo Miniero recommends adding it.

 

Spencer: it is mandatory to support session management interface.

 

Will use a lease mechanism with explicit removal and timer removal.

 

Agreement in the room

 

<Required-ivr-session>

 

Is it useful? Do we need more information?

 

Eric Burger: question about selection of type of audio codec and impact on capacity - to the manufacturers…

 

Roni – no problem with audio codecs for impact on capacity in products I’ve worked on.

 

Group agrees

 

<Required file format>

 

Client asking for specific client format. Is it OK?

 

Group agrees with suggested approach

 

<required-dtmf-type>

 

Group agrees with suggested approach

 

<required-tones>

 

Depends on the corresponding decision on publish interface. It will be the same decision

 

<required-asr-tts>

 

Also depends on the corresponding decision on publish interface. It will be the same decision

 

<required-vxml>

 

Suggested approach is a Boolean. Group agrees.

 

<required-location>

 

Should match the corresponding publisher interface element.

 

<required-encryption>

 

This is Boolean. Suggested approach is fine.

 

<application-data>

 

Application data to supply application data.

 

Suggested approach is fine.

 

<required-max-prepared-duration>

 

This is per-package. Suggested approach is fine.

 

<Required-stream-mode>

 

Suggested approach is fine.

 

<requires-mixes>

 

Should match the corresponding IVR attribute.

 

Spencer: The idea is it all possible combinations of the codecs or only codecs list?

 

Is it one-dimension or multi-dimensional? Which audio codecs with which video codecs?

 

Eric Burger: With today’s processing capacity no need to such combinations

 

Jim McEchern hopes it’s one-dimensional.

 

Chris Boulton agreed as well.

 

No one in the room spoke up for multi-dimensional.

 

Agreed for one-dimensional list without any combinations

 

<required-mix-mode>

 

Spencer: For the publisher interface then they should match and not one of each

 

Rename to <required-mixing-modes>, but otherwise suggested approach is fine.

 

Question Why not put all elements under <required> element and not part of the name.

 

Corresponding elements should be exactly same in Publishing and Consumer Interface. There will be specific elements for the Consumer Interface that do not have corresponding elements for the Publishing Interface

 

Agreed

 

Next steps?

 

Accumulate feedback for the consumer interface. Next version of MRB will have consolidated version of the publisher interface.

 

No more questions?

 

Eric Burger: we have to be done!

Work plan for IETF 77 and shutdown

 

Chair slides (slide 11)

 

Spencer: red dates on this slide are bad (late). Need to go forward. Have already forwarded Control Framework and IVR for publication, and Robert is already reviewing the revised Control Framework. Next is Mixer going to IESG.

 

Next item on our charter is WGLC (broker protocol). Call flows were always intended to be submitted last, so they will match everything we agreed on.

 

Eric Burger: Do we need the MRB specification? Should we shut down the working group and progress MRB as an individual draft?

 

Spencer: in order to justify working group more than one person needs to work on it.

 

Eric Burger: anybody here care? No hands. Chris Boulton and Lorenzo Miniero care.

 

Spencer: People aren’t here who care (3GPP CT working groups are also meeting this week, plus generally difficult attendance at this IETF).

 

Document can be ready in a few months with the right feedback.

 

Eric Burger: if we can do it quickly, let’s finish it.

 

Spencer: How many revision cycles do we need?

 

One could be enough but it would be a big revision. Is the next revision the version that gets WGLCed?

 

Discussion back to working group on mailing list. Two more revision cycles on this document.

 

Chris Boulton claims two weeks.

 

Spencer: revision before Thanksgiving, WGLC. Agreed. Author Action

 

Chris Boulton in jabber room: Need answer to GeoPriv question on Location but that’s the remaining open issue. Can be done.

 

Spencer: will drop tones if no expertise becomes available.

 

Mixer - to IESG December 2009

 

Media Resource Broker Protocol – WGLC December 2009

 

Media Resource Broker Protocol – to IESG February 2010

 

How much MRB work needs to be done for Call Flows? MRB has already been implemented – Simon says “a couple of hours after we forward MRB for publication”. J

 

Call Flows – WGLC Jan 2010

 

Call Flows – to IESG Feb 2010

 

Who will actually review these documents? Chairs will ask for reviewers on-list. Chair Action.

 

We concluded the meeting, but gave the mike and projector to Zhipeng Zhou, who has a proposal for an adaptive decomposed media server, since the right experts were in this room. The proposal is outside the scope of MEDIACTRL and needs to go to DISPATCH – he’s just collecting feedback and looking for other participants who may be interested in collaborating.