DRAFT DRAFT DRAFT DRAFT DRAFT MEDIACTRL Work Group IETF 68, 22 March 2007, 1PM - 3PM CET Karlin II Room Supplemental Web Page: http://www.standardstrack.com/ietf/mediactrl NOTES ===== 1 Agenda Bashing (Eric) No changes to agenda Thanks given to Shida for jabber scribe and Steve for note taker; also thanks to Spenser Dawkins for supplemental notes. 2 Brief Introduction to IETF Standards Process (Eric) Clint Chaplin indicated that RFC4677 should also be read 3 Charter Review See slides: limited to SIP-controlled voice media server Participants need to be aware of other SDO work in this area: 3GPP, ATIS, ETSI/TISPAN, & JCP (JSR 309 Java API for media server control) History - unofficial group met for 3 years and built up a series of requirements and they have been available in the internet-draft repository for some time. Keith Drage indicated that the IMS architecture wont be changed here however they are keen to adopt any protocol solution this group comes up with. 4 Requirements Document (Roni/Martin) Introduction form Roni There were two documents, draft-dolly-xcon-mediacntrlframe and draft-even-media-server-req. Both documents result in requirements that are almost identical - will merge after this IETF. Architecture (see slide) shows the connection from user to proxy to media server that also has connections to application servers. Christer Holmberg Indicated that the definition of a media server is missing from charter. ACTION ITEM: Enumerate definition of a media server in framework document. Lorenzo: XCON protocol question? indicated that this is part of the application server not the media server General Requirements Discussion Cullen: does this include text to speech? Answer: Yes, but at AS-MS level, not MRCPv2 level. Scott: does this include video? Answer: Yes, all real-time multimedia: audio and video. Text / data well covered by T.120 and MSRP. Christer: MS is the combination of the MRFP and MRFC? Answer: Yes, term-of-art is MRF. Christer: can use DNS to find media server h248 solution knows where it is. Answer: True, but H.248 does not route across administrative domains. Keith want to establish this (requirements draft) as WG item by merging the two drafts as the basis for a 00 draft. ACTION ITEM: Eric agreed Question: Hum on adding text regarding ability to do queing. Option [1. Queing 2. One or more 3. No req.] ACTION ITEM: Strong Consensus to change req 1 to say "The AS shall be able to instruct the MS to play one or more announcements." Scott: consider VCR controls and recording to the list of IVR requirements ACTION ITEM: this was inadvertently left off and will be included in next draft Question: what does "delay the announcement until ready" mean? Discussion: no one has a clue; hum to remove ACTION ITEM: remove requirement Collin: do we have to refer to sub-windows by number? Answer: no; will clarify text Question: requirements mention, "interrupt by DTMF" Answer: should be interrupt by, for example, DTMF; not limited to DTMF Adnan: mid call control of dialog Answer: other than "stop what you are doing now", not mid-call dialog control, outside what W3C specifies for VoiceXML, as an example. Question: Seems to be missing Security Considerations ACTION ITEM: include in next draft 5 Media Control Framework (Chris/Martin) Scott presents; SIP control framework first published in 2005 Keith: new headers and option tags goes to SIP, figure out how to split the SIP work off for them Answer: that is what charter says; this is an individual draft indicating direction; would bring requirements to SIP for solution Christer: need to explain why we're using SIP - not just SIP media servers Kert Verber: why to have to burden the media server using SIP Cullen: agree with Christer. Interesting question, having really good reasons and explaining them is important Eric (as participant): IETF runs on consensus and running code. Every commercial media server uses SIP for IP media domain. He knows of only three H.248 media processors, but they aren't media servers (by definition). People are already using SIP because SIP for media control fits the SIP model of service location, user location, and media negotiation. Also, look at H.248 negotiation process. If we don't do SIP, you have H.248 and we go home. Raphael: I'm an open source author. Media server works with SIP because it's also used in standalone mode. AS only speaks SIP, or AS and MS in one box for my products. Adnan: people are using SIP because SIP routes across administrative domains; H.248 does not Christer: I would argue that if you have media server and different data center for AS ... SIP usually either talks to humans or helps humans talk to one another. We have service location protocols. Many good reasons from product perspective but protocol perspective may be different Alberto: Separtion of the AS and MS drive the solution to sip Scott: MRCPv2 explained all of this already, we stole SIP usage from them Eric (as Chair): if you have an alternative proposal to SIP, please send text ACTION ITEM: Real framework document (not a protocol proposal) to be worked on READING LIST ============ Requirements Documents: Media Control Framework: