Subject: RE: [XCON] Concerns about mahy-xcon-media-policy-control

From: "Eric Burger" <[email-masked]>
Date: Sat, 8 Nov 2003 16:05:25 -0500

Chiming in, I would offer that for the "easy cases", it would be better to say what we mean.  E.g., rather than arbitrary graphs at the RTP/DSP level, just say, "I want a sidebar" or "record this"?

I really don't like the idea of replicating H.284.1 in XML :-)

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Tue, November 04, 2003 4:46 AM
> To: Cullen Jennings
> Cc: XCON-IETF
> Subject: Re: [XCON] Concerns about mahy-xcon-media-policy-control
> 
> 
> Cullen,
> 
> I agree, your example scarce me as well. I don't think media 
> graphs are 
> helpful in most of the cases. Naturally, there are some very 
> specific case 
> where it might make sense.
> 
> Marcus
> 
> --On Montag, 3. November 2003 21:25 -0800 Cullen Jennings 
> <[email-masked]> wrote:
> 
> >
> > I'm concerned that it will be incredibly difficult to build 
> clients that
> > read the current media flow graph and can decided what 
> needs to be changed
> > to perform some operation. I'm also concerted it will be 
> very difficult to
> > build media processors that receive some graph and 
> understand what they
> > need to actual do on the DSPs in a way that is efficient on the DSP
> > resources.
> >
> > Let me give an example. Alice has phoned a call center and is in a
> > conference that includes a call center agent Bob. Bob has 
> conference in a
> > third party, called Carla, that validates that Alice said 
> something was ok
> > to Bob. Bob supervisor, Doug, is listening to the call and 
> can whisper to
> > Bob but currently has himself muted. A recording system is recording
> > everything Bob hears (including the whisper) and another 
> recording system
> > monitor system records the stuff Carla hears and says. 
> Carla's supervisor,
> > Zoe, joins the call and tries to form a sidebar with Carla 
> and Bob but
> > Doug would still need to hear this sidebar since he hears 
> everything Bob
> > hears.
> >
> > There are an infinite number of ways of forming a media 
> graph that does
> > this conference.
> >
> > I have a hard time figuring out how Zoe's client is going to get the
> > current media graph and figure out what change it needs to 
> make to this
> > media graph to form the sidebar and not violate the other 
> constraints
> > about the what the recording systems need to record. I 
> don't even know
> > how Zoe's client is going to present a user interface for 
> what it can
> > change about this conference.
> >
> > Let's say that it did figure this all out and sent back a 
> new media graph.
> > This new media graph needs to be run on a DSP platform that 
> has several
> > DSPs. There are constraints to what can be cascaded. There 
> are constraints
> > on how much can be run on a single DSP. There are other conferences
> > running on the same DSPs at the same time. There is highly 
> optimized code
> > for some common situations.
> >
> > I don't know how the media graph is going to be compiled 
> into a highly
> > optimized version of the conference that takes optimal use 
> of the DSP and
> > does not violate any of the constraints. I worked on a 
> compiler for a data
> > flow language that ran on a VLIW processor in a past life. 
> The state of
> > the art in data flow optimizations is not all that great.
> >
> > It's not that any of this is impossible, it's just that it 
> seems very hard
> > to implement. Perhaps I am just being dense and not seeing 
> how all of this
> > would be done. I think I need some convincing that either 
> 1) it actually
> > fairly easy to do or 2) it's only hard in really weird 
> cases and we don't
> > care about those. I would like to hear from other people that might
> > actually implement such a system on how hard it would be 
> and what tweaks
> > could be made that make it simpler.
> >
> > I was initially fairly keen on media graphs as a way of describing
> > conferences but the more I think about implementing them, the less
> > convinced I am that they are practical.
> >
> > Cullen
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/xcon
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> Phone: +49 (0) 6221 905 11 29
> Mobile: +49 (0) 163 275 17 43
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 10 Nov 2003 07:56:41 -0800

Hi,

I'm sorry that I have not had time to issue a complete response to 
Cullen's post.  However, in response to Eric's comment, I'd just like 
to understate the main difference between an approach like H.248 and an 
approach like the one in draft-mahy-xcon-media-policy...

In H.248 if you want to mix in a person who has the floor you have to 
modify the connection parameters every time a different person gets the 
floor (first Alice, then Bob, the Zach...).  In the media policy 
approach you ask that the logical holder(s) of floor foo are mixed in 
and the mixer takes care of the rest.

We really have a meta issue to settle in XCON about what level of 
abstraction meets our requirements without being hideously complex. I 
will try to explain our choices in a balanced way on this issue when I 
present media policy open issues to XCON on Wednesday.  If you'd like 
to contribute a slide or other material for this discussion, please 
send me a short mail or find me in Minneapolis.

thanks,
-rohan

On Saturday, November 8, 2003, at 01:05 PM, Eric Burger wrote:

> Chiming in, I would offer that for the "easy cases", it would be 
> better to say what we mean.  E.g., rather than arbitrary graphs at the 
> RTP/DSP level, just say, "I want a sidebar" or "record this"?
>