Subject: [mediactrl] notes from Wednesday meeting

From: Keith Lantz <[email-masked]>
Date: Wed, 5 Jan 2005 16:44:45 GMT

Here are my "notes" from the meeting. Send me comments/corrections/addenda 
and I'm game to try to turn these in to bona fide "minutes". ;-)

-----------
Attendees: Roni Even, Cullen Jennings, Chris Boulton, Mary Barnes, Keith 
Lantz, Eric Burger, Alan Johnston, Tim Melanchuk, Orit Levin, Adam Roach, 
Dave Morgan, Henning Schulzrinne

Suggested topics:
	- Scope
	- Requirements
	- How do in the IETF?
	- Architecture
	- Next steps
Cullen: One of the biggest questions is whether or not to address all the 
IVR functionality (the first issue on Roni's list). Hard to imagine having 
all this media server support without doing IVR.

Eric: In the ideal world, if you want to do IVR, re-invite to a Voice XML 
session. But in the "real world" a simple MCU -- one that just wants to ask 
for a PIN code -- shouldn't have deal with all that overhead. ...

Roni: It's too early to focus exclusively on SIP. Need to address H.248, 
for example, explicitly rule it in or out and explain why (not).

Cullen: At Cisco, we already had SIP support in place or being developed on 
all platforms, so no one could get too interested in implementing a whole 
other protocol stack. As for scope, my original thinking was that we would 
focus only on how to specify how things should be mixed, not how sessions 
should be established, etc. Supporting IVR functionality mitigates against 
this (simple) view, however, by introducing the need for player-recorders 
that are inserted and removed on the fly, etc.

Various: No one wants to go through the overhead of re-INVITES ... whether 
the participants/clients are involved are not. (General consensus that 
clients are unaware/uninvolved in most, if not all, of the signaling 
involved with mixing, switching, etc. That is, the user-AS signaling and 
the AS-MS signaling are separable.)

Cullen: At least 3 major problems:
	1. How to establish media flows with individual participants and
          the "conference mix".
	2. How to play and record prompts.
	3. How to specify the media mixes.
These problems (and their solutions) should be separable.
Eric: I've always like this model ... in part because it models connections 
between participants and the media server as call legs vs. RTP streams (?).

Roni opined that vendors are using H.248 for IVR. Others expressed 
skepticism, including Mary, who indicated that Nortel was abandoning that 
approach (?).

Roni: Need to provide the flexibility to support multiple architectures.
Eric: I don't understand the fixation on signaling agnosticism. Why can't 
we say we're just doing SIP and anything else is supported via gateways? 
(Question would seem to apply to XCON as a whole, as well.)

Keith (echoing an earlier question by Tim and trying to regain some focus): 
So what's the question being answered (above)? And the proposed answer? ;-)

Cullen: Question is "Should this effort address IVR functionality?" The 
answer is "We need to ascertain the multiple different ways that IVR is 
support, describe how they fit into the model and describe how the AS can 
'discover' how IVR is supported and adjust its operation accordingly."

Keith, Mary, et al.: Sounds too complicated -- either to do this "on the 
fly" or even to expect an AS vendor to accommodate multiple different ways 
to implement an IVR!

Resolution (?): Leave this open. [Editorial comment: "Hmmm..."]
That, then, is the erstwhile "answer" to the first of the issues on Roni's 
list -- "Are we addressing mixer control or media server control (mixing + 
announcement + IVR)?" -- and the 2nd of Cullen's supposedly separable 
problems above.

EXPECTED SCOPE OF EFFORT
Roni & Cullen: Up to five documents:
	- Requirements
	- Scenarios
	- Framework
	- Protocol
	- Best practices (?)
1, 2, 3 & 5 could be IDs forever, with only 4 being an RFC. Hence, no need 
for a new working group?

Regardless, this effort is dependent on XCON. In particular, it cannot 
finish until the media policy work in XCON is finished. So could logically 
become an XCON work item, but that would require a change in XCON's charter.

Adam: This looks like a reasonably sizable effort. Could probably spin up a 
new working group in the same time frame as required to get this on XCON's 
plate -- 1 year or so. Cullen to talk to Alison about that possibility.

IS THE FLOOR CONTROL SERVER PART OF THE MEDIA SERVER?
Answer: ???
WHAT IS THE RELATIONSHIP BETWEEN THIS WORK AND THE MRFP IN 3GPP?
Answer: Need to convince 3GPP folks they need to solve the same problem -- 
and give them our solution (whatever it is).

DO WE ADDRESS MS PROVISIONING IN THE WORK?
Answer: No.
DO WE DEAL WITH ANYTHING BUT SIP?
Answer: Not really. Per the previous discussion, everything will be 
architected in the context of SIP ... but "in such a way as to not make it 
impossible to work with other signaling protocols".

Moving on to the "architecture issues" on Roni's list ...
HOW DO WE FIND THE RIGHT MS -- USE DIRECT CONNECTION BETWEEN AS AND MS OR 
GO THROUGH A PROXY?

Clarification: This is important, for example, when some MSs are audio-only 
and others support audio/video, with dramatically different costs per session.

Keith, et al.: The answer to the secondary question -- direct connection 
vs. proxy -- depends in part on whether or not multiple application servers 
can use the same media server. If so, then some sort of intermediary would 
seem to be required. The majority opinion appears to be that we need to 
allow multiple application servers to use the same media server, so ... an 
intermediary is required. (Yes? No? Maybe so?)

The harder question relates to resource discovery, a principal point of 
debate being whether or not it was possible to provide a higher level of 
abstraction for "ports". Roni, in particular, would like to be able to 
select an MS based on something more abstract than availability defined in 
terms of specific codecs, bandwidths, resolution, etc. Keith, Henning, et 
al. were very skeptical as to our ability to come up with suitable, higher 
level abstractions.

Appropriately enough for a conversation associated with time-based 
resources, we then ran out of time, with Roni volunteering to update the 
requirements document and re-post ... and Cullen volunteering, I think, to 
lead at BOF in Minneapolis.

Comments?
Keith

--------------------------
Ubiquity Software does not control or endorse the content, messages or information found in this mail list and it specifically disclaims any liability with regard to these communications.
Ubiquity Software reserves the right the restrict access to any communications in violation of the Terms and Conditions of Use for this website or as otherwise deemed improper.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 9 Jan 2005 17:35:09 GMT

I was just comparing Keith's notes my notes :-) Need I say anymore :-)

Keith, thank you kindly for the great notes.

Cullen

On 1/5/05 12:13 PM, "Keith Lantz" <[email-masked]> wrote:

> Ubiquity Software does not control or endorse the content, messages or
> information found in this mail list and it specifically disclaims any
> liability with regard to these communications.
> Ubiquity Software reserves the right the restrict access to any communications
> in violation of the Terms and Conditions of Use for this website or as
> otherwise deemed improper.