Subject: Re: [MEDIACTRL] Where does BFCP go

From: xupeili 18916 <[email-masked]>
Date: Thu, 29 Mar 2007 21:50:34 +0800

It seems out of the scope of mediactrl since we do not decompose Media Server to MRFC and MRFP in our architecture. 

Peili

----- Original Message -----
From: Eric Burger <[email-masked]>
Date: Thursday, March 29, 2007 9:08 pm
Subject: [MEDIACTRL] Where does BFCP go

> Start the thread here.
> 
> Question for the Work Group: do we need to work on this?  Will we 
> be able to
> meet all of XCON's requirements with BFCP terminating at the AS?
> 
> 
> On 3/28/07 5:51 AM, "Lorenzo Miniero" <[email-masked]> 
> wrote:
> > Hi Eric,
> > 
> > just a small note upon my question during the meeting, since I think
> > neither the minutes nor the transcript address it well and 
> interested> readers could be confused; besides, Roni's answer isn't 
> reported either.
> > 
> > My concern was addressed in a post on this ML
> > (http://www1.ietf.org/mail-
> archive/web/mediactrl/current/msg00000.html),> and was about where 
> should BFCP be. My opinion is that it should be
> > between the participants and the AS, and thus be part of the "XCON
> > protocols" as seen on Roni's slides in Prague, be it colocating 
> AS-FCS,
> > be it having them as separate boxes interacting with each other. 
> This> way the AS could appropriately "orchestrate" and/or trigger 
> the right
> > component according to the set of resources associated with a floor,
> > i.e. the MS in case floors are associated with audio and/or 
> video, or
> > other components in case resources are related to IM, 
> whiteboarding or
> > whatever else.
> > 
> > Roni replied by rightly pointing out that there's an extension of
> > H.249.19 (as you can read on
> > http://www.ubiquitysoftware.com/archives/200608/msg00003.html, 
> where the
> > extension is attached FYI) to support floor control on the MRFP,
> > particularly useful when wanting, for example, to automatically 
> grant> floors to the requestors without specific policies. This 
> could mean
> > separating the Floor Control Server and the Floor Policy 
> Management, by
> > having the first colocated with the MS and the latter with the AS.
> > While I think this approach has its advantages, I still prefer the
> > AS-FCS approach, by having the Floor Control Server and Floor Policy
> > Management colocated. While the FCS would have no policy 
> management, it
> > still would need to know about all currently managed floors (e.g. to
> > check if a floor exists in a conference) and the basic policies upon
> > them (e.g. to check if a participant has reached the maximum 
> number of
> > allowed requests for a specific floor). Besides, having the FCS
> > colocated with the MS would mean additional channels to be 
> handled by
> > the MS, that would be taken at the expenses of SIP and RTP ones.
> > Nonetheless, the latest is probably a minor issue that could be 
> solved> with the appropriate architecture.
> > 
> > However, though my point of view seems to be reflected in the 
> Conference> Control Package for the SIP Control Framework, as Chris 
> pointed out in
> > one of the replies on the ML the logical role of the BFCP allows 
> both> approaches to be exploited and neither be prohibited, and I'm 
> absolutely> fine with this.
> > 
> > Cheers,
> > Lorenzo
> > 
> > 
> > Eric Burger ha scritto:
> >> Draft minutes are at:
> >> http://www3.ietf.org/proceedings/07mar/minutes/mediactrl.txt
> >> 
> >> Transcript is at:
> >> http://www3.ietf.org/meetings/ietf-logs/mediactrl/2007-03-22.html
> >> 
> >> Thanks to Steve and Spencer for taking notes and to Shida for 
> Jabbering.>> 
> >> Please send comments to me (or list) by 6 April.
> >> 
> >> Thanks.
> >> 
> >> 
> >> Notice:  This email message, together with any attachments, may 
> contain>> information  of  BEA Systems,  Inc.,  its subsidiaries  
> and  affiliated
> >> entities,  that may be confidential,  proprietary,  copyrighted  
> and/or>> legally privileged, and is intended solely for the use of 
> the individual or
> >> entity named in this message. If you are not the intended 
> recipient, and have
> >> received this message in error, please immediately return this 
> by email and
> >> then delete it.
> >> 
> >> _______________________________________________
> >> MEDIACTRL mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/mediactrl
> >> Supplemental Web Site:
> >> http://www.standardstrack.com/ietf/mediactrl
> >> 
> > 
> > 
> > --
> > 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]
> > 
> 
> 
> 
> Notice:  This email message, together with any attachments, may 
> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> affiliated entities,  that may be confidential,  proprietary,  
> copyrighted  and/or legally privileged, and is intended solely for 
> the use of the individual or entity named in this message. If you 
> are not the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> 

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 29 Mar 2007 16:13:03 +0200

Hi,
The reason for the BFCP discussion and H.248.19 direction was because the Media Server can be seen as the whole MRF, exposing the MRFC interface to the AS. This means that if someone wants to decompose the MS to MRFC and MRFP he should be able to support BFCP as suggested in H.248.19.
What it means that the floor chair may be in the AS while the floor control server may reside in the MS. 
We do not mandate this decomposition but BFCP allows for it.

Roni

> -----Original Message-----
> From: xupeili 18916 [mailto:[email-masked]]
> Sent: Thursday, March 29, 2007 3:51 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] Where does BFCP go
> 
> It seems out of the scope of mediactrl since we do not decompose Media
> Server to MRFC and MRFP in our architecture.
> 
> Peili
>