Subject: [MEDIACTRL] BFCP and MediaCtrl

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 13 Nov 2006 13:32:31 +0100

Hi,

I've found two ML regarding MediaCtrl: I'm sending this mail to the ietf 
one, even if its archive is still empty (probably since the BoF has just 
been approved), let me know if I have to send a copy to the old one too.

I've been thinking about the BoF discussions in San Diego, particularly 
about the matter of whether having or not BFCP signaling towards the 
Media Server.
I personally don't like the idea very much: how would it be done? 
probably through a forwarding of each FloorStatus/FloorRequestStatus 
received by the FCS to the MS, which would forcely mean our MS should be 
aware of all the associations (or at least all the associations he would 
need to know, audio/video and the like) between floors and set of 
resources, and of the status of each one. Besides, would this mean that 
the MS should result as a participant in the FCS? or would we need 
adding a new role to the BFCP specifically for the MS? or could we just 
forward the BFCP message to the MS without it being actually known to 
the FCS?
For all these doubts I prefer the idea of having such an interaction 
only between the FCS and the AS, and of moreover providing directly to 
the AS the means of opportunely "directing" the MS, accordingly to all 
the floor status changes that happen (e.g. 
AS->MS:"destroy/disable/'ignore input from' this leg since the user has 
not been granted the floor"), without having the MS to actually know WHY 
such a directive arrived (a relevant floor status change, in this case).

What do you think about it?

Hope to hear you soon, cheers,

Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

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

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 13 Nov 2006 14:52:05 +0200

Lorenzo,

The FCS is a logical entity, in 3GPP they added this entity as part of the MRFP and wrote an extension to the H.248.19 conference package to support floor control.

In the case of the media server, the comment I made was that the Media server will not only accept video and audio but will also include the FCS functionality, so it may receive BFCP dialogs.

The protocol between the media server and application server should address the floor control policy. For example, the application server may tell the media server to always grant the floor to the requestor.

You can always have a separate FCS box but this still will require the application server to interact with it in order to get the floor request and tell the MS to handle the media accordingly. It will be easier to have the media server and FCS functionality in the same box.

Thanks
Roni Even

> -----Original Message-----
> From: Lorenzo Miniero [mailto:[email-masked]]
> Sent: Monday, November 13, 2006 2:33 PM
> To: [email-masked]
> Subject: [MEDIACTRL] BFCP and MediaCtrl
> 
> Hi,
> 
> **************************************************************************
> **********
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer
> viruses.
> **************************************************************************
> **********
> 
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 13 Nov 2006 15:24:48 +0100

Hi Roni,

thanks for your quick answer, comments inline.

> You can always have a separate FCS box but this still will require the application server to interact with it in order to get the floor request and tell the MS to handle the media accordingly. It w…

What do you mean exactly by FCS functionality? A FCS as integrated 
within the MS? It would effectively give better performance, and it is 
exactly how it is working at the moment in the BFCP demo we presented at 
the XCON WG: we used Asterisk which has embedded audio mixing 
functionality (signaling and codecs transcoding), and our FCS was 
implemented as an application module in Asterisk itself, thus providing 
an embedded MS+FCS (MS only in the functionality sense of the term, of 
course). But, since I agree with you that the FCS is a logical entity, 
this means that in a conferencing context it will also happen to have to 
manage floors and requests related to resources that the MS won't 
probably handle, e.g. text, whiteboards, etc. That's why, even if, as 
you said, this would require some kind of protocol to make the AS (or 
the MS) interact with the FCS, I tend to prefer the idea of having the 
FCS as a separate box, and in tighter contact with the AS than with the 
MS, just because of the fact that the floors could be associated with 
resources of any kind, and the AS would provide more abstraction upon 
the managed resources.

But this will all depend on what we'll want the MediaCtrl Media Server 
able to do.

Cheers,

Lorenzo

---

From: "Asher Shiratzky" <[email-masked]>
Date: Mon, 13 Nov 2006 16:37:53 +0200

Lorenzo,
The SIP  control framework is the best approach to solve the valid issues you raise, and this is the reason why we build it  in a such a way that it will be easier to integrate flow control as part of a control package, as well as bi-directionality and mid call events. We know that the AS should know on events going on the media plane, and this does not includes Floor control, but also  other information that is important for repotting and interactivity such as conference event package to notify on what is going on in the media plane, which is the reasonability of the AS

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 13 Nov 2006 17:36:42 +0200

Lorenzo,
The current media in the scope for media control are audio and video
Roni

> Sent: Monday, November 13, 2006 4:25 PM
> To: [email-masked]
> Subject: Re: [MEDIACTRL] BFCP and MediaCtrl
> 
> Hi Roni,
> 
> > The FCS is a logical entity, in 3GPP they added this entity as part of
> the MRFP and wrote an extension to the H.248.19 conference package to
> support floor control.
> >
> > In the case of the media server, the comment I made was that the Media
> server will not only accept video and audio but will also include the FCS
> functionality, so it may receive BFCP dialogs.
> >
> >
> > The protocol between the media server and application server should
> address the floor control policy. For example, the application server may
> tell the media server to always grant the floor to the requestor.
> >
> > You can always have a separate FCS box but this still will require the
> application server to interact with it in order to get the floor request
> and tell the MS to handle the media accordingly. It will be easier to have
> the media server and FCS functionality in the same box.
> >
> > Thanks
> > Roni Even
> >
> 
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 13 Nov 2006 17:21:18 +0100

Hi Roni,

> The current media in the scope for media control are audio and video

Yes, I supposed so: this means the problem with floors associated to 
resources different from audio and video could actually cause the 
problem I was thinking about. Of course this would not be a problem from 
the MediaCtrl point of view, since, as you rightly said and I agree, it 
would be much easier, and performing as well, to have the MS and FCS 
functionality in the same box. But, as Eric pointed out in the BoF, 
MediaCtrl work should coordinate on some relevant points with XCON, 
since the two WG are strongly related. And, since in an XCON conference 
audio and video could not be the only resources that would be used and 
possibly managed through floors (even if they will probably be the MOST 
used), it's the XCONer in me that partly complains with the integrated 
MS+FCS approach :)

But I don't want to become annoying on this point either, and there are 
a lot of other matters to take care about in the WG too...

Cheers,
Lorenzo

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 13 Nov 2006 17:26:29 +0100

Hi Asher,

> The SIP  control framework is the best approach to solve the valid issues you raise, and this is the reason why we build it  in a such a way that it will be easier to integrate flow control as part…

I'm very positive towards event-oriented notifications from the MS to 
the AS, but concerning the FCS this way the AS would only receive 
notifications about audio/video related floor events, right? Which is 
the only doubt/complaint I have at the moment, actually.

Cheers,
Lorenzo