DRAFT    DRAFT    DRAFT     DRAFT
8 November 2006



Media Control BOF Minutes
8 November 2006
IETF 67


Chair: Eric Burger <eburger@cantata.com>
Minutes: Spencer Dawkins <spencer@mcsr-labs.org>

* Agenda Bashing
No bashing noted


* Brief History of IETF Work in this space
One RFC published (RFC 4240), one to be announced (RFC 4722), three other drafts for SIP-control of media servers.  Ad hoc working group formed just before XCON in 2003.  Meeting face-to-face at every IETF since IETF 62.  There are 11 drafts currently active.


* Requirements Draft - Martin Dolly

Have ruled out H.248 because of real-time, interactive nature of applications.

Major components are application server and media server.


* Control Framework Draft - Chris Boulton

Using inherent SIP protocol mechanisms - session agnostic, security mechanisms, service location, connection establishment/maintenance

Current SIP-based proposals use SIP INFO, not intended use of this message. Commands traverse signaling path, UDP is default, MTU conversion on large payloads is not ideal.

MEDIACTRL model is based on control channel model of MRCPv2.


* Charter Discussion

Charter posted for about a month.  See http://flyingfox.cantata.com/i-d/mediactrl

Dave Oran - is this a schema effort or a transaction protocol effort (redoing SOAP, etc.)?

Eric - 90 percent schema, 10 percent choosing existing transaction protocol.

Dave (with IAB hat on) - would be very helpful if charter was explicit about how far you can go with protocols. Don't want to get wrapped up in an existing SOAP/XML mess - was wrong once, with MSRP, really dangerous.

Eric - no futher than MRCP

Dave - MRCPv2 went pretty far, but unfortunately a necessity.

Eric - Not looking at distributed media processing or control protocols. Will not modify existing standard protocols (send requirements to other groups if needed).

Roni - BFCP toward media server?

Eric - typically go to media server

Dave - can you make the statement that hijacking this as a playout replacement for RTSP is out of scope?

Eric looks like a fish.

Roni - nothing can prevent IMS guys from showing up.

Dave - concern that room will fill with those people and you will fail to do your job, concern that IMS policy stuff will fill the room.

Roni - always an application server that sits on top of this. Media server itself does not do this directly.

Jonathan - See what Dave is saying, but SIP is there. If IMS phone works, not sure what to do about that.  Can't NOT do the work just because someone might misuse it for IMS-TV.

Clint Chaplin - don't you want audio video to come to the endpoint as well? Charter language is confused.

Eric thinks charter is clear, Clint does not. Eric noted issue.

Eric - Why are we in the IETF? Desire to build Internet protocol, not in walled garden, have to care about security, privacy, etc.

Jonathan - why is this an Internet protocol? Components are probably in the same rack.

Eric - efficient for service provider wanting to do call control - two administrative domains.

Jonathan - still don't get this. Cardinality, but not going across the Internet.

Eric - not a deliverable to discover media server

Jonathan - assume app server is configured for its media server

Eric - Application server lives in enterprise domain, media server lives in service provider domain, need protocol to cross domains.

Roni - have to figure out what the user wants - media server isn't conference server, etc.

Roni - Also enterprise domains with failover concerns.

Jonathan- could see call coming to Enterprise, to IVR. This is master-slave, where one guy is stupid. Doesn't seem like you'd cross adminisrative domains - large databases haven't done this successfully.

Eric - IVR logic lives in enterprise, media processing lives in network.  Systems installed today that do that.

Eric - First deliverable is requirements document - most, not all, from XCON - also 3GPP2 SA2 and CT1.

Deliverable - framework document, candidate exists.

Deliverable - protocol suite. Several candidates exist.

Deliverable? - discovery, etc. (may be part of previous deliverable).

Clearly related to XCON. If SIP extensions are needed, goes to SIP working group.

Expect to liaise with 3GPP IMS ISC/Mr interface. May be of interest to ITU-T as an next-gen H.248.

Colin Perkins - AVT not mentioned? We have a history of problems when coordination doesn't happen - should think about this as well.

Milestones are "aggressive" for anyone thinking clearly. Requirements document mostly baked, framework document is cooking.

Cullen - what's the broker protocol? Eric - it's deliverable #4.

Andrew - perhaps discovery protocols are part of #3.

Eric - missing ATIS as external group we should coordinate with ("Media Resource Broker", MRB).

Questions...

Are there people here with expertise and interest? something like 60-90 hands to read documents and comments. serious contributors? maybe 12 hands - add a couple from jabber.

Cullen - Dave has concern about scoping down from IPTV. Other concerns we should discuss? Market is maybe $400 M/year, people want a protocol to unify them all.

Cullen - constraining is important. Assume that happens. Who wants to see a charter? Humms generally in favor, no hums against noted.