From alan.johnston at mci.com Mon Aug 4 13:24:48 2003 From: alan.johnston at mci.com (Alan Johnston) Date: Mon Aug 4 12:27:38 2003 Subject: [XCON] Fwd: Internal WG Review: Centralized Conferencing(xcon) Message-ID: <5.2.1.1.0.20030804122355.023f69c0@pop.mcit.com> FYI - progress on the formation of our working group... Thanks, Alan. >Date: Mon, 04 Aug 2003 11:15:48 -0400 >From: iesg-secretary@ietf.org >Subject: Internal WG Review: Centralized Conferencing(xcon) >Sender: nsyracus@cnri.reston.va.us >To: iesg@ietf.org, iab@ietf.org >Cc: alan.johnston@mci.com, adam@dynamicsoft.com >Original-recipient: rfc822;alan.johnston@mci.com > >A new IETF working group is being considered in the >Transport Area. The draft charter for this working group is >provided below for your review and comment. > >Review time is one week. > >The IETF Secretariat > > >Centralized Conferencing (xcon) >--------------------------------- > > Charter > Last Modified: 2003-08-04 > > Current Status: Proposed Working Group > > > CHAIRS: Alan Johnston (alan.johnston@mci.com) > Adam Roach (adam@dynamicsoft.com) > > Mailing list: > List-Archive: > > Transport Area > > Responsible Area Director: Allison Mankin > > Description of Working Group > > The focus of this working group is to develop a standardized suite of > protocols for tightly-coupled multimedia conferences, where strong security > and authorization requirements are integral to the solution. > Tightly-coupled conferences have a central point of control and > authorization so they can enforce specific media and membership > relationships, and provide an accurate roster of participants. The media > mixing or combining function of a tightly-coupled conference need not be > performed centrally, however. > > The scope of this effort is intentionally more narrow than previous > attempts to standardize conferencing (e.g. centralized control), and is > intended to enable interoperability in a commercial environment which > already has a number of non-standard implementations using some of the > protocols. > > Privacy, security, and authorization mechanisms are integral to the > solution generated by the working group. This includes allowing > participants to be completely invisible or to be visible but participate > anonymously with respect to some or all of the other participants. > Authorization rules allow for participants and non-participants to have > roles (ex: speaker, moderator, owner), and to be otherwise authorized to > perform membership and media manipulation for or on behalf of other > participants. In order to preserve these properties, the protocols used > will require implementation of channel security and authentication services. > > Initially this combination of protocols will be specified with respect to > session setup with SIP. The solutions developed in XCON will not preclude > operation with other signaling protocols; however it is anticipated that > the use of other protocols would require modifications which are out of > scope for this working group. > > None of the protocols defined by this group will be SIP, although the SIP > specific event notification framework will be used. The group will use the > high-level requirements and framework already described by documents > published by the SIPPING WG. > > The deliverables for the group will be: > - - A mechanism for membership and authorization control > - - A mechanism to manipulate and describe media "mixing" or "topology" for > multiple media types (audio, video, text) > - - A mechanism for notification of conference related events/changes (for > example a floor change) > - - A basic floor control protocol > > The initial set of protocols will be developed for use in unicast media > conferences. The working group will perform a second round of work to > enhance the set of protocols as necessary for use with multicast media > after their initial publication. > > The following items are specifically out-of-scope: > - - Voting > - - Fully distributed conferences > - - Loosely-coupled conferences (no central point of control) > - - Far-end device control > - - Protocol used between the conference controller and the mixer(s) > - - Capabilities negotiation of the mixer(s) > - - Master-slave cascaded conferences > > The working group will coordinate closely with the SIPPING and MMUSIC > working groups. In addition the working group will cooperate with other > groups as needed, including SIP, AVT, and the W3C SMIL working groups. > In addition, the working group will consider a number of existing drafts (a > non-exhaustive list is included below) as input to the working group. > > Proposed Milestones > > Oct 2003 Submit Requirements for Membership Manipulation for publication as > Informational > Oct 2003 Submit Requirements for Basic Floor Control for publication as > Informational > Nov 2003 Submit Conferencing Scenarios document for publication as > Informational > Nov 2003 Submit Use Cases for Media Topology Control for publication as > Informational > Dec 2003 Submit Requirements for Media Topology Control for publication as > Informational > Feb 2004 Submit Basic Floor Control Protocol for publication as PS > Mar 2004 Submit Notification Event package extension for conference related > events for publication as PS > May 2004 Submit Membership Manipulation Protocol for publication as PS > Jul 2004 Submit Protocol for Media Topology Control for publication as PS > > > From rohan at cisco.com Sun Aug 10 09:39:50 2003 From: rohan at cisco.com (Rohan Mahy) Date: Sun Aug 10 10:37:16 2003 Subject: [XCON] Media Policy in Conferencing Framework In-Reply-To: <000f01c34b1c$353b92d0$2c08d287@fisherlatitude> Message-ID: Hi, I'm not sure if I replied to this already. If not, sorry for the delay. Conferencing applications from one company can work with mixers from another if the mixer vendor also provides a conference policy server. Apps (from any vendor) | | <- (conf policy control protocol) | Conf Policy Server (from vendor X) | | <- (proprietary protocol) | Mixers (also from vendor X) thanks, -rohan On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > Rohan, > > In your response to Eric you state the following goal for xcon: > > "The goal is to allow customers to select a > conferencing application that can work with many vendor's mixers and > conference servers." > > I'm puzzled how this goal can be achieved when the protocol between the > application server and the mixers is explicitly out of scope for xcon? > According to the charter, the following is out of scope: "Protocol used > between the conference controller and the mixer(s)." > > Steve > > From rohan at cisco.com Sun Aug 10 09:54:21 2003 From: rohan at cisco.com (Rohan Mahy) Date: Sun Aug 10 10:51:45 2003 Subject: [XCON] RE: Wireless Systems do not flee XML In-Reply-To: <481D6FFB3BD60E4CB590F39C59098400F2F3B9@trebe004.europe.nokia.com> Message-ID: Hi Petri, Two comments inline. On Wednesday, July 16, 2003, at 11:45 AM, wrote: > Hi, > > I agree with Markus. > > Floor control protocol (at least the floor claim/grant/deny part of > it) should > not be used in time-critical applications like push to talk. > > Typical floor controlled application scenarios involve floor chair > (human being) > who grants or denies the floor claim. There is also claim queue > management > involved as there may several floor claims waiting for turn. > This is not very time-critical (and often there are couple of people > ahead of > you in the floor claim queue anyway). > Floor claim request may include additional information, e.g. priority > or > topic of your comment (chair can better control the floor queue if he > knows > in advance what is the topic of the comment). > XML (and SOAP) is logical solution for this, as defined in > draft-wu-sipping-floor-control. Your last statement really concerns me. Even if we had consensus that SOAP was the way to encode floor control requests (I am still unconvinced on the value of SOAP for this application), the Wu draft is not going to be amenable to either the SIPPING chairs, the IESG, or the IAB, since it is using SIP to send floor control traffic which is wildly unrelated to the core strengths of SIP. The draft isn't following the SIP communities own rules about SIP extensions. This *really* needs to be another protocol. > Push to talk like applications definitely should not use floor chairs > or floor claim requests > as it would be too slow. Having seen an implementation of PTT using floor control, I have to disagree with you; especially if we select a simple protocol. thanks, -rohan > Instead, they should use fixed media and floor policies > (something like "no floor control protocol for media X, first speaker > is passed through"). > In the rare case that this did not work out (e.g. two persons starts > speaking at the same time) > then there may be negative notification, as markus pointed out. So > this kind of application might > utilize XML/SOAP only for floor creation. Anyway, this specific > example is a service > and IETF does not specify services. > >> I think it would make sense to include the support for this kind of >> scenario also under >> the "floor control" work item in XCON. > > We tried to support this in floor control draft (e.g. create_floor > defines the floor policy > which says whether floor claims are used) but it seems that this work > must be better aligned > with media policy work. > > > -- > Petri > >> -----Original Message----- >> From: ext [mailto:Markus.Isomaki@nokia.com] >> Sent: 16 July, 2003 18:24 >> To: dwillis@dynamicsoft.com; Mayer Georg (NMP/Helsinki); >> xcon@softarmor.com >> Subject: RE: [XCON] RE: Wireless Systems do not flee XML >> >> >> Hi, >> >> I agree that for certain floor control operations latency is >> clearly the most important issue in wireless networks. Push >> to talk type of applications require some very efficient >> mechanism to compete for the "floor", in which case some >> other enconding than XML would seem reasonable. >> >> Actually, for some applications it would be enough just to do >> the contention with the media (i.e. the RTP packets carrying >> the talkburst), and then just to learn if you did NOT get the >> floor through some simple protocol message (in which case the >> person talking would get some negative indication). In other >> words this means that you always don't need to first >> explicitly reserve the floor for you before starting to send >> the media. I believe this is how it works in most of the >> proprietary push to talk apps. >> >> I think it would make sense to include the support for this >> kind of scenario also under the "floor control" work item in >> XCON. First we would ofcourse need some more specifric >> requirements text. >> >> Markus >> >>> -----Original Message----- >>> From: ext Dean Willis [mailto:dwillis@dynamicsoft.com] >>> Sent: 16 July, 2003 11:12 >>> To: Mayer Georg (NMP/Helsinki); xcon@softarmor.com >>> Subject: [XCON] RE: Wireless Systems do not flee XML >>> >>> >>> Georg said: >>> >>>> Dean made a statement during the XCON BOF that the wireless >>>> guys (to which I count myself) do not want XML as it would >>>> use to much bandwidth. That is in fact not true - there were >>>> requirements expressed that XML is the preferred solution for >>>> coding e.g. CPCP, as this would allow us XML also for XCON >>>> purposes and we would not need to implement the next encoder >>>> in our devices. This was actually a requirement that clearly >>>> came out from the last 3G CN1 meeting. >>> >>> >>> I was specifically worried about XML for floor management in >>> a conference. >>> >>> Within the "other" mobile community (3GPP2 -- CDMA) everybody >>> that I've >>> talked is of the belief that the floor control messages for >>> PoC (push talk >>> over cellular) will need to be down in the 20-30 byte range >> (including >>> headers after ROHC) to work optimally with CDMA2000. This >>> allows them to >>> transmit in a single short data burst. >>> >>> XML for configuration and other non-real-time data seems to be ok. >>> >>> -- >>> Dean >>> >>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@softarmor.com >>> http://www.softarmor.com/mailman/listinfo/xcon >>> >> >> _______________________________________________ >> XCON mailing list >> XCON@softarmor.com >> http://www.softarmor.com/mailman/listinfo/xcon >> > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon From hgs at cs.columbia.edu Sun Aug 10 12:59:04 2003 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Sun Aug 10 10:59:20 2003 Subject: [XCON] RE: Wireless Systems do not flee XML In-Reply-To: References: Message-ID: <3F366BC8.3010908@cs.columbia.edu> > unrelated to the core strengths of SIP. The draft isn't following the > SIP communities own rules about SIP extensions. This *really* needs to > be another protocol. > This just isn't true. The proposal uses SIP for event notification, not for command & control. This combination is not unusual in SIP-space, e.g., in the configuration efforts or in the SIMPLE/XCAP work. See the abstract: This document defines an approach of using Session Initiation Protocol (SIP) event notification mechanism and Simple Object Access Protocol (SOAP) to perform floor control. I share your concern about the value of SOAP in this context, but the draft is not proposing to carry SOAP over SIP or anything close to that. Henning From fluffy at cisco.com Sat Aug 9 11:30:03 2003 From: fluffy at cisco.com (Cullen Jennings) Date: Sun Aug 10 13:02:37 2003 Subject: [XCON] Floor Control: Charter. In-Reply-To: Message-ID: I don't see voting as being integral for floor control. I think we can define a useful floor control system without doing voting. No one is going to try and break voting, it's just a hard problem - I'm happy to have it out of scope for the initial round of stuff. Cullen On 7/22/03 8:17, "Orit Levin" wrote: > I am afraid I share some of the concerns expressed by Avshalom. > > The reason for including the basic Floor Control Protocol as a part of XCON > is to be able to use it as the tool for building various applications when > "lecture with questions/answers" and "voting" being some of them. > > Therefore I suggest including the motivation as a part of the Charter: > > "The basic Floor Control Protocol will provide the tools for building > conferencing applications such as lecture with questions/answers and voting. > Standardization of the Floor Control applications is out of scope of XCON" > > and removing the stand-alone "out-of-scope Voting" statement because it is > one of the many examples only. > > Orit. > > >> -----Original Message----- >> From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] >> Sent: Thursday, July 17, 2003 5:12 AM >> To: Jonathan Rosenberg >> Cc: Rosen, Brian; xcon@softarmor.com >> Subject: Re: [XCON] Charter >> >> Voting is only an example of some type of floor control given to all >> participants for a certain period of time. If people feel that it can be >> easily added on I would agree with Brian, Jonathan & Henning. We really >> need to get this going. >> >> Avshalom >> >> >> >> >> Jonathan Rosenberg >> 17/07/2003 11:50 AM >> >> To >> "Rosen, Brian" >> cc >> Avshalom Houri/Haifa/IBM@IBMIL, xcon@softarmor.com >> Subject >> Re: [XCON] Charter >> >> >> >> >> >> >> I agree with Brian. >> >> There is already a lot of work on the proposed charter. Let us get >> that done first. >> >> -Jonathan R. >> >> Rosen, Brian wrote: >> >>> While I don't necessarily oppose the inclusion of voting, I find the >>> arguments here to not be convincing. >>> >>> I think voting is a simple request/response mechanism - you send out >>> a request for vote and you get a vote in response. There could be >>> significant security implications on voting (for example, you may need >>> non-repudiation). However, I think the vote object itself can >>> carry all the security itself, it won't affect the media or conference >>> policy stuff at all. >>> >>> Now, I do assume that the vote recorder is architecturally part of >>> the conference policy server. I don't want to see a protocol between >>> the cps and the vote recorder. >>> >>> For these reasons, I think voting can be considered as an add-on >>> at any time. >>> >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] >>>> Sent: Thursday, July 17, 2003 4:04 AM >>>> To: xcon@softarmor.com >>>> Subject: Re: [XCON] Charter >>>> >>>> >>>> I agree that voting should be added. It is not complex as the >>>> other issues >>>> and seems to be a thing that should >>>> designed from the beginning. >>>> In other words I am not sure that it is a layer that can be >>>> added later >>>> easily. Another point for voting is that it will >>>> certainly have some requirements on the presence protocols >>>> that will be >>>> used for the controlling the conference. >>>> >>>> Avshalom >>>> >>>> >>>> >>>> >>>> "Kozdon, Peter" >>>> Sent by: xcon-bounces@softarmor.com >>>> 17/07/2003 12:50 AM >>>> >>>> To >>>> xcon@softarmor.com >>>> cc >>>> >>>> Subject >>>> [XCON] Charter >>>> >>>> >>>> >>>> >>>> >>>> >>>> Can someone please help me understand why Voting is excluded >>>> from the >>>> scope >>>> of XCON. >>>> >>>> I can understand why the actual vote counting, aggregation, >>>> etc.. should >>>> be >>>> left to the implementation, however, the capability to make a >>>> vote should >>>> be >>>> provided. This capability should be included in Conference >>>> Control in the >>>> same manner as "raise hand" to get attention, slow down >>>> instruction to the >>>> presenter, and similar actions. >>>> >>>> >>>> Thanks >>>> >>>> Peter Kozdon >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@softarmor.com >>>> http://www.softarmor.com/mailman/listinfo/xcon >>>> >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@softarmor.com >>>> http://www.softarmor.com/mailman/listinfo/xcon >>>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@softarmor.com >>> http://www.softarmor.com/mailman/listinfo/xcon >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ 07054-2711 >> dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> >> _______________________________________________ >> XCON mailing list >> XCON@softarmor.com >> http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > From adam at dynamicsoft.com Mon Aug 11 13:54:47 2003 From: adam at dynamicsoft.com (Adam Roach) Date: Mon Aug 11 12:56:42 2003 Subject: [XCON] Media Policy in Conferencing Framework Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862B3@dyn-tx-exch-001.dynamicsoft.com> Note also that the type of protocols that would be required to perform such control is not completely unexplored. For example, it is probable that the following would be a viable solution: Apps (from vendor X) | | <- (CPCP) | Conf Policy Server (from vendor Y) | | <- (H.248) | Mixers (from vendor Z) The issue is that XCON is not going to define or even identify a canonical protocol that goes between the conference policy server and the mixer. We aren't going to analyze any particular protocols for gaps. If you're really interested in making certain that, for example, H.248 will serve the purpose you have in mind, you can certainly take the issue to the MEGACO working group to see if you can get enough interest. In particular, I want to make sure that people aren't equating "out of scope for this working group" with "can't be standardized anywhere" or "must be proprietary." It just means, "we're not doing it *here*." /a > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, August 10, 2003 10:40 > To: Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > Hi, > > I'm not sure if I replied to this already. If not, sorry for > the delay. > > Conferencing applications from one company can work with mixers from > another if the mixer vendor also provides a conference policy server. > > Apps (from any vendor) > | > | <- (conf policy control protocol) > | > Conf Policy Server (from vendor X) > | > | <- (proprietary protocol) > | > Mixers (also from vendor X) > > > thanks, > -rohan > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > Rohan, > > > > In your response to Eric you state the following goal for xcon: > > > > "The goal is to allow customers to select a > > conferencing application that can work with many vendor's mixers and > > conference servers." > > > > I'm puzzled how this goal can be achieved when the protocol > between the > > application server and the mixers is explicitly out of > scope for xcon? > > According to the charter, the following is out of scope: > "Protocol used > > between the conference controller and the mixer(s)." > > > > Steve > > > > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > From roni.even at polycom.co.il Tue Aug 12 21:38:53 2003 From: roni.even at polycom.co.il (Even, Roni) Date: Tue Aug 12 12:39:06 2003 Subject: [XCON] Media Policy in Conferencing Framework Message-ID: To enhance Adam's point the ITU is working on H.248.19 "Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" that will enable the focus or a conference policy server to control the mixers. Roni Even Polycom -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Monday, August 11, 2003 8:55 PM To: 'Rohan Mahy'; Steve Fisher Cc: 'IETF XCON Discussion List (E-mail)' Subject: RE: [XCON] Media Policy in Conferencing Framework Note also that the type of protocols that would be required to perform such control is not completely unexplored. For example, it is probable that the following would be a viable solution: Apps (from vendor X) | | <- (CPCP) | Conf Policy Server (from vendor Y) | | <- (H.248) | Mixers (from vendor Z) The issue is that XCON is not going to define or even identify a canonical protocol that goes between the conference policy server and the mixer. We aren't going to analyze any particular protocols for gaps. If you're really interested in making certain that, for example, H.248 will serve the purpose you have in mind, you can certainly take the issue to the MEGACO working group to see if you can get enough interest. In particular, I want to make sure that people aren't equating "out of scope for this working group" with "can't be standardized anywhere" or "must be proprietary." It just means, "we're not doing it *here*." /a > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, August 10, 2003 10:40 > To: Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > Hi, > > I'm not sure if I replied to this already. If not, sorry for > the delay. > > Conferencing applications from one company can work with mixers from > another if the mixer vendor also provides a conference policy server. > > Apps (from any vendor) > | > | <- (conf policy control protocol) > | > Conf Policy Server (from vendor X) > | > | <- (proprietary protocol) > | > Mixers (also from vendor X) > > > thanks, > -rohan > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > Rohan, > > > > In your response to Eric you state the following goal for xcon: > > > > "The goal is to allow customers to select a > > conferencing application that can work with many vendor's mixers and > > conference servers." > > > > I'm puzzled how this goal can be achieved when the protocol > between the > > application server and the mixers is explicitly out of > scope for xcon? > > According to the charter, the following is out of scope: > "Protocol used > > between the conference controller and the mixer(s)." > > > > Steve > > > > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon From eburger at snowshore.com Wed Aug 13 17:51:21 2003 From: eburger at snowshore.com (Eric Burger) Date: Wed Aug 13 15:51:29 2003 Subject: [XCON] Media Policy in Conferencing Framework Message-ID: <4A3384433CE2AB46A63468CB207E209D4F665F@zoe.office.snowshore.com> If at all possible, I would try to stay far, far away from H.248. Depending on your perspective, it will seriously limit what an endpoint can request or it will significantly increase the amount of application interworking code required, neither of which is what people want to pay for. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tue, August 12, 2003 1:39 PM > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > Multipoint Control Unit, Audio, Video and Data Conferencing > Packages" that > will enable the focus or a conference policy server to > control the mixers. > > Roni Even > Polycom > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Monday, August 11, 2003 8:55 PM > To: 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > Note also that the type of protocols that would be required > to perform such control is not completely unexplored. For > example, it is probable that the following would be a viable > solution: > > Apps (from vendor X) > | > | <- (CPCP) > | > Conf Policy Server (from vendor Y) > | > | <- (H.248) > | > Mixers (from vendor Z) > > The issue is that XCON is not going to define or even identify > a canonical protocol that goes between the conference policy > server and the mixer. We aren't going to analyze any particular > protocols for gaps. > > If you're really interested in making certain that, for example, > H.248 will serve the purpose you have in mind, you can certainly > take the issue to the MEGACO working group to see if you can get > enough interest. > > In particular, I want to make sure that people aren't equating > "out of scope for this working group" with "can't be standardized > anywhere" or "must be proprietary." It just means, "we're not > doing it *here*." > > /a > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Sunday, August 10, 2003 10:40 > > To: Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > Hi, > > > > I'm not sure if I replied to this already. If not, sorry for > > the delay. > > > > Conferencing applications from one company can work with > mixers from > > another if the mixer vendor also provides a conference > policy server. > > > > Apps (from any vendor) > > | > > | <- (conf policy control protocol) > > | > > Conf Policy Server (from vendor X) > > | > > | <- (proprietary protocol) > > | > > Mixers (also from vendor X) > > > > > > thanks, > > -rohan > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > Rohan, > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > "The goal is to allow customers to select a > > > conferencing application that can work with many vendor's > mixers and > > > conference servers." > > > > > > I'm puzzled how this goal can be achieved when the protocol > > between the > > > application server and the mixers is explicitly out of > > scope for xcon? > > > According to the charter, the following is out of scope: > > "Protocol used > > > between the conference controller and the mixer(s)." > > > > > > Steve > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > > From roni.even at polycom.co.il Thu Aug 14 10:05:52 2003 From: roni.even at polycom.co.il (Even, Roni) Date: Thu Aug 14 01:05:59 2003 Subject: [XCON] Media Policy in Conferencing Framework Message-ID: Eric, The H.248 is not used by the EP but in order to control a mixer from a focus or in a decomposed model according to H.323 to control an MP by an MC. The EP will use the CPCP and MPCP to the conference/media policy server Roni -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Wednesday, August 13, 2003 11:51 PM To: Even, Roni; Henry Sinnreich (E-mail) Cc: IETF XCON Discussion List (E-mail) Subject: RE: [XCON] Media Policy in Conferencing Framework If at all possible, I would try to stay far, far away from H.248. Depending on your perspective, it will seriously limit what an endpoint can request or it will significantly increase the amount of application interworking code required, neither of which is what people want to pay for. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tue, August 12, 2003 1:39 PM > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > Multipoint Control Unit, Audio, Video and Data Conferencing > Packages" that > will enable the focus or a conference policy server to > control the mixers. > > Roni Even > Polycom > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Monday, August 11, 2003 8:55 PM > To: 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > Note also that the type of protocols that would be required > to perform such control is not completely unexplored. For > example, it is probable that the following would be a viable > solution: > > Apps (from vendor X) > | > | <- (CPCP) > | > Conf Policy Server (from vendor Y) > | > | <- (H.248) > | > Mixers (from vendor Z) > > The issue is that XCON is not going to define or even identify > a canonical protocol that goes between the conference policy > server and the mixer. We aren't going to analyze any particular > protocols for gaps. > > If you're really interested in making certain that, for example, > H.248 will serve the purpose you have in mind, you can certainly > take the issue to the MEGACO working group to see if you can get > enough interest. > > In particular, I want to make sure that people aren't equating > "out of scope for this working group" with "can't be standardized > anywhere" or "must be proprietary." It just means, "we're not > doing it *here*." > > /a > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Sunday, August 10, 2003 10:40 > > To: Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > Hi, > > > > I'm not sure if I replied to this already. If not, sorry for > > the delay. > > > > Conferencing applications from one company can work with > mixers from > > another if the mixer vendor also provides a conference > policy server. > > > > Apps (from any vendor) > > | > > | <- (conf policy control protocol) > > | > > Conf Policy Server (from vendor X) > > | > > | <- (proprietary protocol) > > | > > Mixers (also from vendor X) > > > > > > thanks, > > -rohan > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > Rohan, > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > "The goal is to allow customers to select a > > > conferencing application that can work with many vendor's > mixers and > > > conference servers." > > > > > > I'm puzzled how this goal can be achieved when the protocol > > between the > > > application server and the mixers is explicitly out of > > scope for xcon? > > > According to the charter, the following is out of scope: > > "Protocol used > > > between the conference controller and the mixer(s)." > > > > > > Steve > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > > From eburger at snowshore.com Thu Aug 14 12:08:38 2003 From: eburger at snowshore.com (Eric Burger) Date: Thu Aug 14 10:08:42 2003 Subject: [XCON] Media Policy in Conferencing Framework Message-ID: <4A3384433CE2AB46A63468CB207E209D59E5BE@zoe.office.snowshore.com> Agreed. However, quoting myself: > it will significantly increase the amount of application > interworking code Why impose burdens on the conferencing application at this point in time? If we don't impose burdens on the application, then we're saying the CPCP/MPCP will look or at least act like H.248. This is not a desired restriction on the protocol. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thu, August 14, 2003 2:06 AM > To: Eric Burger; Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > Eric, > The H.248 is not used by the EP but in order to control a > mixer from a focus > or in a decomposed model according to H.323 to control an MP > by an MC. The > EP will use the CPCP and MPCP to the conference/media policy server > Roni > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Wednesday, August 13, 2003 11:51 PM > To: Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > If at all possible, I would try to stay far, far away from > H.248. Depending > on your perspective, it will seriously limit what an endpoint > can request or > it will significantly increase the amount of application > interworking code > required, neither of which is what people want to pay for. > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tue, August 12, 2003 1:39 PM > > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > > Multipoint Control Unit, Audio, Video and Data Conferencing > > Packages" that > > will enable the focus or a conference policy server to > > control the mixers. > > > > Roni Even > > Polycom > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Monday, August 11, 2003 8:55 PM > > To: 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > Note also that the type of protocols that would be required > > to perform such control is not completely unexplored. For > > example, it is probable that the following would be a viable > > solution: > > > > Apps (from vendor X) > > | > > | <- (CPCP) > > | > > Conf Policy Server (from vendor Y) > > | > > | <- (H.248) > > | > > Mixers (from vendor Z) > > > > The issue is that XCON is not going to define or even identify > > a canonical protocol that goes between the conference policy > > server and the mixer. We aren't going to analyze any particular > > protocols for gaps. > > > > If you're really interested in making certain that, for example, > > H.248 will serve the purpose you have in mind, you can certainly > > take the issue to the MEGACO working group to see if you can get > > enough interest. > > > > In particular, I want to make sure that people aren't equating > > "out of scope for this working group" with "can't be standardized > > anywhere" or "must be proprietary." It just means, "we're not > > doing it *here*." > > > > /a > > > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, August 10, 2003 10:40 > > > To: Steve Fisher > > > Cc: 'IETF XCON Discussion List (E-mail)' > > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > > > > Hi, > > > > > > I'm not sure if I replied to this already. If not, sorry for > > > the delay. > > > > > > Conferencing applications from one company can work with > > mixers from > > > another if the mixer vendor also provides a conference > > policy server. > > > > > > Apps (from any vendor) > > > | > > > | <- (conf policy control protocol) > > > | > > > Conf Policy Server (from vendor X) > > > | > > > | <- (proprietary protocol) > > > | > > > Mixers (also from vendor X) > > > > > > > > > thanks, > > > -rohan > > > > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > > > Rohan, > > > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > > > "The goal is to allow customers to select a > > > > conferencing application that can work with many vendor's > > mixers and > > > > conference servers." > > > > > > > > I'm puzzled how this goal can be achieved when the protocol > > > between the > > > > application server and the mixers is explicitly out of > > > scope for xcon? > > > > According to the charter, the following is out of scope: > > > "Protocol used > > > > between the conference controller and the mixer(s)." > > > > > > > > Steve > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@softarmor.com > > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > > From Henry.Sinnreich at mci.com Thu Aug 14 11:10:01 2003 From: Henry.Sinnreich at mci.com (Henry Sinnreich) Date: Thu Aug 14 10:27:15 2003 Subject: [XCON] Media Policy in Conferencing Framework In-Reply-To: Message-ID: <0HJM0051B7GSE7@pmismtp06.wcomnet.com> Even, there is simply no justification for even mentioning H.248 in this dedicated group that works to promote SIP and tries hard keep the old monsters away. Just a matter of hygiene... Henry > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, August 14, 2003 1:06 AM > To: 'Eric Burger'; Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > Eric, > The H.248 is not used by the EP but in order to control a mixer from a > focus > or in a decomposed model according to H.323 to control an MP by an MC. The > EP will use the CPCP and MPCP to the conference/media policy server > Roni > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Wednesday, August 13, 2003 11:51 PM > To: Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > If at all possible, I would try to stay far, far away from H.248. > Depending > on your perspective, it will seriously limit what an endpoint can request > or > it will significantly increase the amount of application interworking code > required, neither of which is what people want to pay for. > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tue, August 12, 2003 1:39 PM > > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > > Multipoint Control Unit, Audio, Video and Data Conferencing > > Packages" that > > will enable the focus or a conference policy server to > > control the mixers. > > > > Roni Even > > Polycom > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Monday, August 11, 2003 8:55 PM > > To: 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > Note also that the type of protocols that would be required > > to perform such control is not completely unexplored. For > > example, it is probable that the following would be a viable > > solution: > > > > Apps (from vendor X) > > | > > | <- (CPCP) > > | > > Conf Policy Server (from vendor Y) > > | > > | <- (H.248) > > | > > Mixers (from vendor Z) > > > > The issue is that XCON is not going to define or even identify > > a canonical protocol that goes between the conference policy > > server and the mixer. We aren't going to analyze any particular > > protocols for gaps. > > > > If you're really interested in making certain that, for example, > > H.248 will serve the purpose you have in mind, you can certainly > > take the issue to the MEGACO working group to see if you can get > > enough interest. > > > > In particular, I want to make sure that people aren't equating > > "out of scope for this working group" with "can't be standardized > > anywhere" or "must be proprietary." It just means, "we're not > > doing it *here*." > > > > /a > > > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, August 10, 2003 10:40 > > > To: Steve Fisher > > > Cc: 'IETF XCON Discussion List (E-mail)' > > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > > > > Hi, > > > > > > I'm not sure if I replied to this already. If not, sorry for > > > the delay. > > > > > > Conferencing applications from one company can work with > > mixers from > > > another if the mixer vendor also provides a conference > > policy server. > > > > > > Apps (from any vendor) > > > | > > > | <- (conf policy control protocol) > > > | > > > Conf Policy Server (from vendor X) > > > | > > > | <- (proprietary protocol) > > > | > > > Mixers (also from vendor X) > > > > > > > > > thanks, > > > -rohan > > > > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > > > Rohan, > > > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > > > "The goal is to allow customers to select a > > > > conferencing application that can work with many vendor's > > mixers and > > > > conference servers." > > > > > > > > I'm puzzled how this goal can be achieved when the protocol > > > between the > > > > application server and the mixers is explicitly out of > > > scope for xcon? > > > > According to the charter, the following is out of scope: > > > "Protocol used > > > > between the conference controller and the mixer(s)." > > > > > > > > Steve > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@softarmor.com > > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > > From mfdolan at lucent.com Thu Aug 14 15:32:53 2003 From: mfdolan at lucent.com (Dolan, Michael F (Mike)) Date: Thu Aug 14 14:33:12 2003 Subject: [XCON] Media Policy in Conferencing Framework Message-ID: Hi, Isn't it a bit early in the work of XCON to declare biases toward / away from any particular protocols? Wouldn't it be a bit better to understand all of the requirements first? Mike Dolan mfdolan@lucent.com -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] Sent: Thursday, August 14, 2003 10:10 AM To: 'Even, Roni'; 'Eric Burger' Cc: 'IETF XCON Discussion List (E-mail)' Subject: RE: [XCON] Media Policy in Conferencing Framework Even, there is simply no justification for even mentioning H.248 in this dedicated group that works to promote SIP and tries hard keep the old monsters away. Just a matter of hygiene... Henry > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, August 14, 2003 1:06 AM > To: 'Eric Burger'; Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > Eric, > The H.248 is not used by the EP but in order to control a mixer from a > focus > or in a decomposed model according to H.323 to control an MP by an MC. The > EP will use the CPCP and MPCP to the conference/media policy server > Roni > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Wednesday, August 13, 2003 11:51 PM > To: Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > If at all possible, I would try to stay far, far away from H.248. > Depending > on your perspective, it will seriously limit what an endpoint can request > or > it will significantly increase the amount of application interworking code > required, neither of which is what people want to pay for. > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tue, August 12, 2003 1:39 PM > > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > > Multipoint Control Unit, Audio, Video and Data Conferencing > > Packages" that > > will enable the focus or a conference policy server to > > control the mixers. > > > > Roni Even > > Polycom > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Monday, August 11, 2003 8:55 PM > > To: 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > Note also that the type of protocols that would be required > > to perform such control is not completely unexplored. For > > example, it is probable that the following would be a viable > > solution: > > > > Apps (from vendor X) > > | > > | <- (CPCP) > > | > > Conf Policy Server (from vendor Y) > > | > > | <- (H.248) > > | > > Mixers (from vendor Z) > > > > The issue is that XCON is not going to define or even identify > > a canonical protocol that goes between the conference policy > > server and the mixer. We aren't going to analyze any particular > > protocols for gaps. > > > > If you're really interested in making certain that, for example, > > H.248 will serve the purpose you have in mind, you can certainly > > take the issue to the MEGACO working group to see if you can get > > enough interest. > > > > In particular, I want to make sure that people aren't equating > > "out of scope for this working group" with "can't be standardized > > anywhere" or "must be proprietary." It just means, "we're not > > doing it *here*." > > > > /a > > > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, August 10, 2003 10:40 > > > To: Steve Fisher > > > Cc: 'IETF XCON Discussion List (E-mail)' > > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > > > > Hi, > > > > > > I'm not sure if I replied to this already. If not, sorry for > > > the delay. > > > > > > Conferencing applications from one company can work with > > mixers from > > > another if the mixer vendor also provides a conference > > policy server. > > > > > > Apps (from any vendor) > > > | > > > | <- (conf policy control protocol) > > > | > > > Conf Policy Server (from vendor X) > > > | > > > | <- (proprietary protocol) > > > | > > > Mixers (also from vendor X) > > > > > > > > > thanks, > > > -rohan > > > > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > > > Rohan, > > > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > > > "The goal is to allow customers to select a > > > > conferencing application that can work with many vendor's > > mixers and > > > > conference servers." > > > > > > > > I'm puzzled how this goal can be achieved when the protocol > > > between the > > > > application server and the mixers is explicitly out of > > > scope for xcon? > > > > According to the charter, the following is out of scope: > > > "Protocol used > > > > between the conference controller and the mixer(s)." > > > > > > > > Steve > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@softarmor.com > > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon From adam at dynamicsoft.com Thu Aug 14 17:00:47 2003 From: adam at dynamicsoft.com (Adam Roach) Date: Thu Aug 14 16:00:50 2003 Subject: [XCON] Media Policy in Conferencing Framework Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862EB@dyn-tx-exch-001.dynamicsoft.com> The very point that started this thread is *precisely* that we are not going to even consider the protocols in this space. The signaling going between a focus and a mixer (if they are, in fact, decomposed) is completely out of scope for XCON. The religious opinions expressed on this thread have confirmed that the decision to leave mixer control off of the charter was a wise one. I apologize for actually naming a concrete protocol in my earlier note, as it appears to have simply muddied the issue. The point I was attempting to make is that there are already solutions for this problem, and I simply named one as an existence proof. To be clear: I was not intending to promote any protocol over another, and further apologize that I didn't make such a fact clear in my original post on this topic. XCON is not an appropriate forum for campaigning for your favorite (or against your least favorite) protocol that can be used for mixer control. Let's devote our energies to more productive tasks. /a X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJHBH2; Thu, 14 Aug 2003 17:02:24 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EKxWuU018694; Thu, 14 Aug 2003 16:59:32 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7EL0pDs026613; Thu, 14 Aug 2003 16:00:54 -0500 Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7EL0mDq026610 for ; Thu, 14 Aug 2003 16:00:48 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EL0mRe014166 for ; Thu, 14 Aug 2003 17:00:48 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Aug 2003 16:00:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862EB@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'IETF XCON Discussion List (E-mail)'" Subject: RE: [XCON] Media Policy in Conferencing Framework Date: Thu, 14 Aug 2003 16:00:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=iso-8859-1; format=flowed X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit The very point that started this thread is *precisely* that we are not going to even consider the protocols in this space. The signaling going between a focus and a mixer (if they are, in fact, decomposed) is completely out of scope for XCON. The religious opinions expressed on this thread have confirmed that the decision to leave mixer control off of the charter was a wise one. I apologize for actually naming a concrete protocol in my earlier note, as it appears to have simply muddied the issue. The point I was attempting to make is that there are already solutions for this problem, and I simply named one as an existence proof. To be clear: I was not intending to promote any protocol over another, and further apologize that I didn't make such a fact clear in my original post on this topic. XCON is not an appropriate forum for campaigning for your favorite (or against your least favorite) protocol that can be used for mixer control. Let's devote our energies to more productive tasks. /a _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJHA94; Thu, 14 Aug 2003 15:34:38 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EJVjuU018356; Thu, 14 Aug 2003 15:31:46 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7EJXCDs026282; Thu, 14 Aug 2003 14:33:13 -0500 Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7EJXADq026279 for ; Thu, 14 Aug 2003 14:33:10 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7EJX6U05052 for ; Thu, 14 Aug 2003 14:33:07 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 14 Aug 2003 14:33:06 -0500 Message-ID: From: "Dolan, Michael F (Mike)" To: "'IETF XCON Discussion List (E-mail)'" Subject: RE: [XCON] Media Policy in Conferencing Framework Date: Thu, 14 Aug 2003 14:32:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset=windows-1252; format=flowed X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit Hi, Isn't it a bit early in the work of XCON to declare biases toward / away from any particular protocols? Wouldn't it be a bit better to understand all of the requirements first? Mike Dolan mfdolan@lucent.com -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@mci.com] Sent: Thursday, August 14, 2003 10:10 AM To: 'Even, Roni'; 'Eric Burger' Cc: 'IETF XCON Discussion List (E-mail)' Subject: RE: [XCON] Media Policy in Conferencing Framework Even, there is simply no justification for even mentioning H.248 in this dedicated group that works to promote SIP and tries hard keep the old monsters away. Just a matter of hygiene... Henry > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, August 14, 2003 1:06 AM > To: 'Eric Burger'; Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > Eric, > The H.248 is not used by the EP but in order to control a mixer from a > focus > or in a decomposed model according to H.323 to control an MP by an MC. The > EP will use the CPCP and MPCP to the conference/media policy server > Roni > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Wednesday, August 13, 2003 11:51 PM > To: Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > If at all possible, I would try to stay far, far away from H.248. > Depending > on your perspective, it will seriously limit what an endpoint can request > or > it will significantly increase the amount of application interworking code > required, neither of which is what people want to pay for. > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tue, August 12, 2003 1:39 PM > > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > > Multipoint Control Unit, Audio, Video and Data Conferencing > > Packages" that > > will enable the focus or a conference policy server to > > control the mixers. > > > > Roni Even > > Polycom > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Monday, August 11, 2003 8:55 PM > > To: 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > Note also that the type of protocols that would be required > > to perform such control is not completely unexplored. For > > example, it is probable that the following would be a viable > > solution: > > > > Apps (from vendor X) > > | > > | <- (CPCP) > > | > > Conf Policy Server (from vendor Y) > > | > > | <- (H.248) > > | > > Mixers (from vendor Z) > > > > The issue is that XCON is not going to define or even identify > > a canonical protocol that goes between the conference policy > > server and the mixer. We aren't going to analyze any particular > > protocols for gaps. > > > > If you're really interested in making certain that, for example, > > H.248 will serve the purpose you have in mind, you can certainly > > take the issue to the MEGACO working group to see if you can get > > enough interest. > > > > In particular, I want to make sure that people aren't equating > > "out of scope for this working group" with "can't be standardized > > anywhere" or "must be proprietary." It just means, "we're not > > doing it *here*." > > > > /a > > > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, August 10, 2003 10:40 > > > To: Steve Fisher > > > Cc: 'IETF XCON Discussion List (E-mail)' > > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > > > > Hi, > > > > > > I'm not sure if I replied to this already. If not, sorry for > > > the delay. > > > > > > Conferencing applications from one company can work with > > mixers from > > > another if the mixer vendor also provides a conference > > policy server. > > > > > > Apps (from any vendor) > > > | > > > | <- (conf policy control protocol) > > > | > > > Conf Policy Server (from vendor X) > > > | > > > | <- (proprietary protocol) > > > | > > > Mixers (also from vendor X) > > > > > > > > > thanks, > > > -rohan > > > > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > > > Rohan, > > > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > > > "The goal is to allow customers to select a > > > > conferencing application that can work with many vendor's > > mixers and > > > > conference servers." > > > > > > > > I'm puzzled how this goal can be achieved when the protocol > > > between the > > > > application server and the mixers is explicitly out of > > > scope for xcon? > > > > According to the charter, the following is out of scope: > > > "Protocol used > > > > between the conference controller and the mixer(s)." > > > > > > > > Steve > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@softarmor.com > > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJHAGC; Thu, 14 Aug 2003 11:28:04 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EFPP7g018763; Thu, 14 Aug 2003 11:25:25 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7EFREDs025198; Thu, 14 Aug 2003 10:27:14 -0500 Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7EFDlDs025140 for ; Thu, 14 Aug 2003 10:13:47 -0500 Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJM00HH27GUP8@firewall.wcom.com> for xcon@softarmor.com; Thu, 14 Aug 2003 15:10:06 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJM005017GNHR@pmismtp06.wcomnet.com>; Thu, 14 Aug 2003 15:10:06 +0000 (GMT) Received: from hsinnreich2 ([166.50.136.152]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJM005167GPE7@pmismtp06.wcomnet.com>; Thu, 14 Aug 2003 15:10:05 +0000 (GMT) Date: Thu, 14 Aug 2003 10:10:01 -0500 From: Henry Sinnreich Subject: RE: [XCON] Media Policy in Conferencing Framework In-reply-to: To: "'Even, Roni'" , "'Eric Burger'" Message-id: <0HJM0051B7GSE7@pmismtp06.wcomnet.com> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5329 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 8bit Thread-index: AcNiKiCBU8RtozUkS6Sbj8UpwSs+WgASFC7Q X-Mailman-Approved-At: Thu, 14 Aug 2003 10:27:14 -0500 Cc: "'IETF XCON Discussion List \(E-mail\)'" X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Even, there is simply no justification for even mentioning H.248 in this dedicated group that works to promote SIP and tries hard keep the old monsters away. Just a matter of hygiene... Henry > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thursday, August 14, 2003 1:06 AM > To: 'Eric Burger'; Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > Eric, > The H.248 is not used by the EP but in order to control a mixer from a > focus > or in a decomposed model according to H.323 to control an MP by an MC. The > EP will use the CPCP and MPCP to the conference/media policy server > Roni > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Wednesday, August 13, 2003 11:51 PM > To: Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > If at all possible, I would try to stay far, far away from H.248. > Depending > on your perspective, it will seriously limit what an endpoint can request > or > it will significantly increase the amount of application interworking code > required, neither of which is what people want to pay for. > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tue, August 12, 2003 1:39 PM > > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > > Multipoint Control Unit, Audio, Video and Data Conferencing > > Packages" that > > will enable the focus or a conference policy server to > > control the mixers. > > > > Roni Even > > Polycom > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Monday, August 11, 2003 8:55 PM > > To: 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > Note also that the type of protocols that would be required > > to perform such control is not completely unexplored. For > > example, it is probable that the following would be a viable > > solution: > > > > Apps (from vendor X) > > | > > | <- (CPCP) > > | > > Conf Policy Server (from vendor Y) > > | > > | <- (H.248) > > | > > Mixers (from vendor Z) > > > > The issue is that XCON is not going to define or even identify > > a canonical protocol that goes between the conference policy > > server and the mixer. We aren't going to analyze any particular > > protocols for gaps. > > > > If you're really interested in making certain that, for example, > > H.248 will serve the purpose you have in mind, you can certainly > > take the issue to the MEGACO working group to see if you can get > > enough interest. > > > > In particular, I want to make sure that people aren't equating > > "out of scope for this working group" with "can't be standardized > > anywhere" or "must be proprietary." It just means, "we're not > > doing it *here*." > > > > /a > > > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, August 10, 2003 10:40 > > > To: Steve Fisher > > > Cc: 'IETF XCON Discussion List (E-mail)' > > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > > > > Hi, > > > > > > I'm not sure if I replied to this already. If not, sorry for > > > the delay. > > > > > > Conferencing applications from one company can work with > > mixers from > > > another if the mixer vendor also provides a conference > > policy server. > > > > > > Apps (from any vendor) > > > | > > > | <- (conf policy control protocol) > > > | > > > Conf Policy Server (from vendor X) > > > | > > > | <- (proprietary protocol) > > > | > > > Mixers (also from vendor X) > > > > > > > > > thanks, > > > -rohan > > > > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > > > Rohan, > > > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > > > "The goal is to allow customers to select a > > > > conferencing application that can work with many vendor's > > mixers and > > > > conference servers." > > > > > > > > I'm puzzled how this goal can be achieved when the protocol > > > between the > > > > application server and the mixers is explicitly out of > > > scope for xcon? > > > > According to the charter, the following is out of scope: > > > "Protocol used > > > > between the conference controller and the mixer(s)." > > > > > > > > Steve > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@softarmor.com > > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJHA1R; Thu, 14 Aug 2003 11:11:33 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7EF8fuU017080; Thu, 14 Aug 2003 11:08:41 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7EF8gDs025112; Thu, 14 Aug 2003 10:08:44 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h7EF8dDq025109 for ; Thu, 14 Aug 2003 10:08:39 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 31159; Thu, 14 Aug 2003 11:05:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: RE: [XCON] Media Policy in Conferencing Framework Date: Thu, 14 Aug 2003 11:08:38 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D59E5BE@zoe.office.snowshore.com> Thread-Topic: [XCON] Media Policy in Conferencing Framework Thread-Index: AcNiKiVl46I4m/leTk2gST2BOZvB6wAS4UoQ From: "Eric Burger" To: "Even, Roni" , "Henry Sinnreich (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h7EF8dDq025109 Cc: "IETF XCON Discussion List \(E-mail\)" X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Agreed. However, quoting myself: > it will significantly increase the amount of application > interworking code Why impose burdens on the conferencing application at this point in time? If we don't impose burdens on the application, then we're saying the CPCP/MPCP will look or at least act like H.248. This is not a desired restriction on the protocol. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Thu, August 14, 2003 2:06 AM > To: Eric Burger; Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > Eric, > The H.248 is not used by the EP but in order to control a > mixer from a focus > or in a decomposed model according to H.323 to control an MP > by an MC. The > EP will use the CPCP and MPCP to the conference/media policy server > Roni > > > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Wednesday, August 13, 2003 11:51 PM > To: Even, Roni; Henry Sinnreich (E-mail) > Cc: IETF XCON Discussion List (E-mail) > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > If at all possible, I would try to stay far, far away from > H.248. Depending > on your perspective, it will seriously limit what an endpoint > can request or > it will significantly increase the amount of application > interworking code > required, neither of which is what people want to pay for. > > > -----Original Message----- > > From: Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: Tue, August 12, 2003 1:39 PM > > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > > Multipoint Control Unit, Audio, Video and Data Conferencing > > Packages" that > > will enable the focus or a conference policy server to > > control the mixers. > > > > Roni Even > > Polycom > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@dynamicsoft.com] > > Sent: Monday, August 11, 2003 8:55 PM > > To: 'Rohan Mahy'; Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > > > Note also that the type of protocols that would be required > > to perform such control is not completely unexplored. For > > example, it is probable that the following would be a viable > > solution: > > > > Apps (from vendor X) > > | > > | <- (CPCP) > > | > > Conf Policy Server (from vendor Y) > > | > > | <- (H.248) > > | > > Mixers (from vendor Z) > > > > The issue is that XCON is not going to define or even identify > > a canonical protocol that goes between the conference policy > > server and the mixer. We aren't going to analyze any particular > > protocols for gaps. > > > > If you're really interested in making certain that, for example, > > H.248 will serve the purpose you have in mind, you can certainly > > take the issue to the MEGACO working group to see if you can get > > enough interest. > > > > In particular, I want to make sure that people aren't equating > > "out of scope for this working group" with "can't be standardized > > anywhere" or "must be proprietary." It just means, "we're not > > doing it *here*." > > > > /a > > > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rohan@cisco.com] > > > Sent: Sunday, August 10, 2003 10:40 > > > To: Steve Fisher > > > Cc: 'IETF XCON Discussion List (E-mail)' > > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > > > > Hi, > > > > > > I'm not sure if I replied to this already. If not, sorry for > > > the delay. > > > > > > Conferencing applications from one company can work with > > mixers from > > > another if the mixer vendor also provides a conference > > policy server. > > > > > > Apps (from any vendor) > > > | > > > | <- (conf policy control protocol) > > > | > > > Conf Policy Server (from vendor X) > > > | > > > | <- (proprietary protocol) > > > | > > > Mixers (also from vendor X) > > > > > > > > > thanks, > > > -rohan > > > > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > > > Rohan, > > > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > > > "The goal is to allow customers to select a > > > > conferencing application that can work with many vendor's > > mixers and > > > > conference servers." > > > > > > > > I'm puzzled how this goal can be achieved when the protocol > > > between the > > > > application server and the mixers is explicitly out of > > > scope for xcon? > > > > According to the charter, the following is out of scope: > > > "Protocol used > > > > between the conference controller and the mixer(s)." > > > > > > > > Steve > > > > > > > > > > > > > > _______________________________________________ > > > XCON mailing list > > > XCON@softarmor.com > > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > > > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJG99C; Thu, 14 Aug 2003 02:06:58 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7E645uU015399; Thu, 14 Aug 2003 02:04:05 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7E660Ds022183; Thu, 14 Aug 2003 01:06:01 -0500 Received: from accord-ntsrv3.polycom.co.il (212.199.61.2.forward.012.net.il [212.199.61.2]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7E65qDq022180 for ; Thu, 14 Aug 2003 01:05:57 -0500 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 14 Aug 2003 09:05:53 +0300 Message-ID: From: "Even, Roni" To: "'Eric Burger'" , "Even, Roni" , "Henry Sinnreich (E-mail)" Subject: RE: [XCON] Media Policy in Conferencing Framework Date: Thu, 14 Aug 2003 09:05:52 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Cc: "IETF XCON Discussion List \(E-mail\)" X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-type: text/plain; charset=windows-1252; format=flowed MIME-Version: 1.0 Content-transfer-encoding: 8bit Eric, The H.248 is not used by the EP but in order to control a mixer from a focus or in a decomposed model according to H.323 to control an MP by an MC. The EP will use the CPCP and MPCP to the conference/media policy server Roni -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Wednesday, August 13, 2003 11:51 PM To: Even, Roni; Henry Sinnreich (E-mail) Cc: IETF XCON Discussion List (E-mail) Subject: RE: [XCON] Media Policy in Conferencing Framework If at all possible, I would try to stay far, far away from H.248. Depending on your perspective, it will seriously limit what an endpoint can request or it will significantly increase the amount of application interworking code required, neither of which is what people want to pay for. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tue, August 12, 2003 1:39 PM > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > Multipoint Control Unit, Audio, Video and Data Conferencing > Packages" that > will enable the focus or a conference policy server to > control the mixers. > > Roni Even > Polycom > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Monday, August 11, 2003 8:55 PM > To: 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > Note also that the type of protocols that would be required > to perform such control is not completely unexplored. For > example, it is probable that the following would be a viable > solution: > > Apps (from vendor X) > | > | <- (CPCP) > | > Conf Policy Server (from vendor Y) > | > | <- (H.248) > | > Mixers (from vendor Z) > > The issue is that XCON is not going to define or even identify > a canonical protocol that goes between the conference policy > server and the mixer. We aren't going to analyze any particular > protocols for gaps. > > If you're really interested in making certain that, for example, > H.248 will serve the purpose you have in mind, you can certainly > take the issue to the MEGACO working group to see if you can get > enough interest. > > In particular, I want to make sure that people aren't equating > "out of scope for this working group" with "can't be standardized > anywhere" or "must be proprietary." It just means, "we're not > doing it *here*." > > /a > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Sunday, August 10, 2003 10:40 > > To: Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > Hi, > > > > I'm not sure if I replied to this already. If not, sorry for > > the delay. > > > > Conferencing applications from one company can work with > mixers from > > another if the mixer vendor also provides a conference > policy server. > > > > Apps (from any vendor) > > | > > | <- (conf policy control protocol) > > | > > Conf Policy Server (from vendor X) > > | > > | <- (proprietary protocol) > > | > > Mixers (also from vendor X) > > > > > > thanks, > > -rohan > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > Rohan, > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > "The goal is to allow customers to select a > > > conferencing application that can work with many vendor's > mixers and > > > conference servers." > > > > > > I'm puzzled how this goal can be achieved when the protocol > > between the > > > application server and the mixers is explicitly out of > > scope for xcon? > > > According to the charter, the following is out of scope: > > "Protocol used > > > between the conference controller and the mixer(s)." > > > > > > Steve > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJG87Z; Wed, 13 Aug 2003 16:54:08 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7DKpGuU013774; Wed, 13 Aug 2003 16:51:17 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7DKpTDs019489; Wed, 13 Aug 2003 15:51:31 -0500 Received: from webshield.office.snowshore.com (goalie.snowshore.com [216.57.133.4]) by bdsl.greycouncil.com (8.12.8/8.12.8) with SMTP id h7DKpLDq019486 for ; Wed, 13 Aug 2003 15:51:22 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 25217; Wed, 13 Aug 2003 16:48:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: RE: [XCON] Media Policy in Conferencing Framework Date: Wed, 13 Aug 2003 16:51:21 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F665F@zoe.office.snowshore.com> Thread-Topic: [XCON] Media Policy in Conferencing Framework Thread-Index: AcNg+XUfMgO/1d2DT56LrDs3ttzUSQA4QVvQ From: "Eric Burger" To: "Even, Roni" , "Henry Sinnreich (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bdsl.greycouncil.com id h7DKpLDq019486 Cc: "IETF XCON Discussion List \(E-mail\)" X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com If at all possible, I would try to stay far, far away from H.248. Depending on your perspective, it will seriously limit what an endpoint can request or it will significantly increase the amount of application interworking code required, neither of which is what people want to pay for. > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Tue, August 12, 2003 1:39 PM > To: Adam Roach; 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > > To enhance Adam's point the ITU is working on H.248.19 "Decomposed > Multipoint Control Unit, Audio, Video and Data Conferencing > Packages" that > will enable the focus or a conference policy server to > control the mixers. > > Roni Even > Polycom > > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Monday, August 11, 2003 8:55 PM > To: 'Rohan Mahy'; Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: RE: [XCON] Media Policy in Conferencing Framework > > > Note also that the type of protocols that would be required > to perform such control is not completely unexplored. For > example, it is probable that the following would be a viable > solution: > > Apps (from vendor X) > | > | <- (CPCP) > | > Conf Policy Server (from vendor Y) > | > | <- (H.248) > | > Mixers (from vendor Z) > > The issue is that XCON is not going to define or even identify > a canonical protocol that goes between the conference policy > server and the mixer. We aren't going to analyze any particular > protocols for gaps. > > If you're really interested in making certain that, for example, > H.248 will serve the purpose you have in mind, you can certainly > take the issue to the MEGACO working group to see if you can get > enough interest. > > In particular, I want to make sure that people aren't equating > "out of scope for this working group" with "can't be standardized > anywhere" or "must be proprietary." It just means, "we're not > doing it *here*." > > /a > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Sunday, August 10, 2003 10:40 > > To: Steve Fisher > > Cc: 'IETF XCON Discussion List (E-mail)' > > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > > > > Hi, > > > > I'm not sure if I replied to this already. If not, sorry for > > the delay. > > > > Conferencing applications from one company can work with > mixers from > > another if the mixer vendor also provides a conference > policy server. > > > > Apps (from any vendor) > > | > > | <- (conf policy control protocol) > > | > > Conf Policy Server (from vendor X) > > | > > | <- (proprietary protocol) > > | > > Mixers (also from vendor X) > > > > > > thanks, > > -rohan > > > > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > > > Rohan, > > > > > > In your response to Eric you state the following goal for xcon: > > > > > > "The goal is to allow customers to select a > > > conferencing application that can work with many vendor's > mixers and > > > conference servers." > > > > > > I'm puzzled how this goal can be achieved when the protocol > > between the > > > application server and the mixers is explicitly out of > > scope for xcon? > > > According to the charter, the following is out of scope: > > "Protocol used > > > between the conference controller and the mixer(s)." > > > > > > Steve > > > > > > > > > > _______________________________________________ > > XCON mailing list > > XCON@softarmor.com > > http://www.softarmor.com/mailman/listinfo/xcon > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJGZ09; Tue, 12 Aug 2003 13:39:18 -0400 Received: from accord-ntsrv3.polycom.co.il (212.199.61.2.forward.012.net.il [212.199.61.2]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7CHab7g008429 for ; Tue, 12 Aug 2003 13:36:40 -0400 (EDT) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Tue, 12 Aug 2003 20:39:01 +0300 Message-ID: From: "Even, Roni" To: Adam Roach , "'Rohan Mahy'" , Steve Fisher Cc: "'IETF XCON Discussion List (E-mail)'" Subject: RE: [XCON] Media Policy in Conferencing Framework Date: Tue, 12 Aug 2003 20:38:53 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Content-type: text/plain; charset=windows-1252; format=flowed MIME-Version: 1.0 Content-transfer-encoding: 8bit To enhance Adam's point the ITU is working on H.248.19 "Decomposed Multipoint Control Unit, Audio, Video and Data Conferencing Packages" that will enable the focus or a conference policy server to control the mixers. Roni Even Polycom -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com] Sent: Monday, August 11, 2003 8:55 PM To: 'Rohan Mahy'; Steve Fisher Cc: 'IETF XCON Discussion List (E-mail)' Subject: RE: [XCON] Media Policy in Conferencing Framework Note also that the type of protocols that would be required to perform such control is not completely unexplored. For example, it is probable that the following would be a viable solution: Apps (from vendor X) | | <- (CPCP) | Conf Policy Server (from vendor Y) | | <- (H.248) | Mixers (from vendor Z) The issue is that XCON is not going to define or even identify a canonical protocol that goes between the conference policy server and the mixer. We aren't going to analyze any particular protocols for gaps. If you're really interested in making certain that, for example, H.248 will serve the purpose you have in mind, you can certainly take the issue to the MEGACO working group to see if you can get enough interest. In particular, I want to make sure that people aren't equating "out of scope for this working group" with "can't be standardized anywhere" or "must be proprietary." It just means, "we're not doing it *here*." /a > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, August 10, 2003 10:40 > To: Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > Hi, > > I'm not sure if I replied to this already. If not, sorry for > the delay. > > Conferencing applications from one company can work with mixers from > another if the mixer vendor also provides a conference policy server. > > Apps (from any vendor) > | > | <- (conf policy control protocol) > | > Conf Policy Server (from vendor X) > | > | <- (proprietary protocol) > | > Mixers (also from vendor X) > > > thanks, > -rohan > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > Rohan, > > > > In your response to Eric you state the following goal for xcon: > > > > "The goal is to allow customers to select a > > conferencing application that can work with many vendor's mixers and > > conference servers." > > > > I'm puzzled how this goal can be achieved when the protocol > between the > > application server and the mixers is explicitly out of > scope for xcon? > > According to the charter, the following is out of scope: > "Protocol used > > between the conference controller and the mixer(s)." > > > > Steve > > > > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJGWXQ; Mon, 11 Aug 2003 13:59:11 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7BHuJuU002595; Mon, 11 Aug 2003 13:56:19 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7BHugDs003266; Mon, 11 Aug 2003 12:56:44 -0500 Received: from mail4.dynamicsoft.com (dyn-tx-bapp-001.dfw.dynamicsoft.com [63.110.3.100]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7BHudDq003263 for ; Mon, 11 Aug 2003 12:56:39 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7BHsmRe006247; Mon, 11 Aug 2003 13:54:48 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 12:54:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E862B3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Rohan Mahy'" , Steve Fisher Subject: RE: [XCON] Media Policy in Conferencing Framework Date: Mon, 11 Aug 2003 12:54:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: "'IETF XCON Discussion List \(E-mail\)'" X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit Note also that the type of protocols that would be required to perform such control is not completely unexplored. For example, it is probable that the following would be a viable solution: Apps (from vendor X) | | <- (CPCP) | Conf Policy Server (from vendor Y) | | <- (H.248) | Mixers (from vendor Z) The issue is that XCON is not going to define or even identify a canonical protocol that goes between the conference policy server and the mixer. We aren't going to analyze any particular protocols for gaps. If you're really interested in making certain that, for example, H.248 will serve the purpose you have in mind, you can certainly take the issue to the MEGACO working group to see if you can get enough interest. In particular, I want to make sure that people aren't equating "out of scope for this working group" with "can't be standardized anywhere" or "must be proprietary." It just means, "we're not doing it *here*." /a > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Sunday, August 10, 2003 10:40 > To: Steve Fisher > Cc: 'IETF XCON Discussion List (E-mail)' > Subject: Re: [XCON] Media Policy in Conferencing Framework > > > Hi, > > I'm not sure if I replied to this already. If not, sorry for > the delay. > > Conferencing applications from one company can work with mixers from > another if the mixer vendor also provides a conference policy server. > > Apps (from any vendor) > | > | <- (conf policy control protocol) > | > Conf Policy Server (from vendor X) > | > | <- (proprietary protocol) > | > Mixers (also from vendor X) > > > thanks, > -rohan > > > On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > > > Rohan, > > > > In your response to Eric you state the following goal for xcon: > > > > "The goal is to allow customers to select a > > conferencing application that can work with many vendor's mixers and > > conference servers." > > > > I'm puzzled how this goal can be achieved when the protocol > between the > > application server and the mixers is explicitly out of > scope for xcon? > > According to the charter, the following is out of scope: > "Protocol used > > between the conference controller and the mixer(s)." > > > > Steve > > > > > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJG4H1; Sun, 10 Aug 2003 14:05:04 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7AI2DJq022444; Sun, 10 Aug 2003 14:02:14 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AI2cDs030485; Sun, 10 Aug 2003 13:02:38 -0500 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AI2ZDq030482 for ; Sun, 10 Aug 2003 13:02:35 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7AI2XuG022614; Sun, 10 Aug 2003 11:02:33 -0700 (PDT) Received: from [192.168.2.40] (sjc-vpn4-746.cisco.com [10.21.82.234]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AGY47197; Sun, 10 Aug 2003 11:02:31 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 09 Aug 2003 10:30:03 -0700 Subject: Re: [XCON] Floor Control: Charter. From: Cullen Jennings To: Orit Levin , xcon@softarmor.com Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 8bit X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com I don't see voting as being integral for floor control. I think we can define a useful floor control system without doing voting. No one is going to try and break voting, it's just a hard problem - I'm happy to have it out of scope for the initial round of stuff. Cullen On 7/22/03 8:17, "Orit Levin" wrote: > I am afraid I share some of the concerns expressed by Avshalom. > > The reason for including the basic Floor Control Protocol as a part of XCON > is to be able to use it as the tool for building various applications when > "lecture with questions/answers" and "voting" being some of them. > > Therefore I suggest including the motivation as a part of the Charter: > > "The basic Floor Control Protocol will provide the tools for building > conferencing applications such as lecture with questions/answers and voting. > Standardization of the Floor Control applications is out of scope of XCON" > > and removing the stand-alone "out-of-scope Voting" statement because it is > one of the many examples only. > > Orit. > > >> -----Original Message----- >> From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] >> Sent: Thursday, July 17, 2003 5:12 AM >> To: Jonathan Rosenberg >> Cc: Rosen, Brian; xcon@softarmor.com >> Subject: Re: [XCON] Charter >> >> Voting is only an example of some type of floor control given to all >> participants for a certain period of time. If people feel that it can be >> easily added on I would agree with Brian, Jonathan & Henning. We really >> need to get this going. >> >> Avshalom >> >> >> >> >> Jonathan Rosenberg >> 17/07/2003 11:50 AM >> >> To >> "Rosen, Brian" >> cc >> Avshalom Houri/Haifa/IBM@IBMIL, xcon@softarmor.com >> Subject >> Re: [XCON] Charter >> >> >> >> >> >> >> I agree with Brian. >> >> There is already a lot of work on the proposed charter. Let us get >> that done first. >> >> -Jonathan R. >> >> Rosen, Brian wrote: >> >>> While I don't necessarily oppose the inclusion of voting, I find the >>> arguments here to not be convincing. >>> >>> I think voting is a simple request/response mechanism - you send out >>> a request for vote and you get a vote in response. There could be >>> significant security implications on voting (for example, you may need >>> non-repudiation). However, I think the vote object itself can >>> carry all the security itself, it won't affect the media or conference >>> policy stuff at all. >>> >>> Now, I do assume that the vote recorder is architecturally part of >>> the conference policy server. I don't want to see a protocol between >>> the cps and the vote recorder. >>> >>> For these reasons, I think voting can be considered as an add-on >>> at any time. >>> >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] >>>> Sent: Thursday, July 17, 2003 4:04 AM >>>> To: xcon@softarmor.com >>>> Subject: Re: [XCON] Charter >>>> >>>> >>>> I agree that voting should be added. It is not complex as the >>>> other issues >>>> and seems to be a thing that should >>>> designed from the beginning. >>>> In other words I am not sure that it is a layer that can be >>>> added later >>>> easily. Another point for voting is that it will >>>> certainly have some requirements on the presence protocols >>>> that will be >>>> used for the controlling the conference. >>>> >>>> Avshalom >>>> >>>> >>>> >>>> >>>> "Kozdon, Peter" >>>> Sent by: xcon-bounces@softarmor.com >>>> 17/07/2003 12:50 AM >>>> >>>> To >>>> xcon@softarmor.com >>>> cc >>>> >>>> Subject >>>> [XCON] Charter >>>> >>>> >>>> >>>> >>>> >>>> >>>> Can someone please help me understand why Voting is excluded >>>> from the >>>> scope >>>> of XCON. >>>> >>>> I can understand why the actual vote counting, aggregation, >>>> etc.. should >>>> be >>>> left to the implementation, however, the capability to make a >>>> vote should >>>> be >>>> provided. This capability should be included in Conference >>>> Control in the >>>> same manner as "raise hand" to get attention, slow down >>>> instruction to the >>>> presenter, and similar actions. >>>> >>>> >>>> Thanks >>>> >>>> Peter Kozdon >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@softarmor.com >>>> http://www.softarmor.com/mailman/listinfo/xcon >>>> >>>> _______________________________________________ >>>> XCON mailing list >>>> XCON@softarmor.com >>>> http://www.softarmor.com/mailman/listinfo/xcon >>>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@softarmor.com >>> http://www.softarmor.com/mailman/listinfo/xcon >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Technology Officer Parsippany, NJ 07054-2711 >> dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> >> _______________________________________________ >> XCON mailing list >> XCON@softarmor.com >> http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJG4CS; Sun, 10 Aug 2003 12:00:04 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7AFvEJq022207; Sun, 10 Aug 2003 11:57:15 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AFxLDs030155; Sun, 10 Aug 2003 10:59:21 -0500 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.59.238]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AFxHDr030152 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 10 Aug 2003 10:59:18 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h7AFx4Fh010126 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 10 Aug 2003 11:59:04 -0400 (EDT) Message-ID: <3F366BC8.3010908@cs.columbia.edu> Date: Sun, 10 Aug 2003 11:59:04 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [XCON] RE: Wireless Systems do not flee XML References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Cc: xcon@softarmor.com, dwillis@dynamicsoft.com, Markus.Isomaki@nokia.com X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com > unrelated to the core strengths of SIP. The draft isn't following the > SIP communities own rules about SIP extensions. This *really* needs to > be another protocol. > This just isn't true. The proposal uses SIP for event notification, not for command & control. This combination is not unusual in SIP-space, e.g., in the configuration efforts or in the SIMPLE/XCAP work. See the abstract: This document defines an approach of using Session Initiation Protocol (SIP) event notification mechanism and Simple Object Access Protocol (SOAP) to perform floor control. I share your concern about the value of SOAP in this context, but the draft is not proposing to carry SOAP over SIP or anything close to that. Henning _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail2.dynamicsoft.com (192.168.4.31 [192.168.4.31]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJG4CH; Sun, 10 Aug 2003 11:52:38 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail2.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7AFo18t024430; Sun, 10 Aug 2003 11:50:01 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AFpjDs030127; Sun, 10 Aug 2003 10:51:46 -0500 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AFpiDq030124 for ; Sun, 10 Aug 2003 10:51:44 -0500 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2003 08:51:44 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7AFpfuG021446; Sun, 10 Aug 2003 08:51:41 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE97128; Sun, 10 Aug 2003 08:45:04 -0700 (PDT) Date: Sun, 10 Aug 2003 08:54:21 -0700 Subject: Re: [XCON] RE: Wireless Systems do not flee XML Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 To: petri.koskelainen@nokia.com From: Rohan Mahy In-Reply-To: <481D6FFB3BD60E4CB590F39C59098400F2F3B9@trebe004.europe.nokia.com> Message-Id: Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.552) Cc: dwillis@dynamicsoft.com, xcon@softarmor.com, Markus.Isomaki@nokia.com X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Hi Petri, Two comments inline. On Wednesday, July 16, 2003, at 11:45 AM, wrote: > Hi, > > I agree with Markus. > > Floor control protocol (at least the floor claim/grant/deny part of > it) should > not be used in time-critical applications like push to talk. > > Typical floor controlled application scenarios involve floor chair > (human being) > who grants or denies the floor claim. There is also claim queue > management > involved as there may several floor claims waiting for turn. > This is not very time-critical (and often there are couple of people > ahead of > you in the floor claim queue anyway). > Floor claim request may include additional information, e.g. priority > or > topic of your comment (chair can better control the floor queue if he > knows > in advance what is the topic of the comment). > XML (and SOAP) is logical solution for this, as defined in > draft-wu-sipping-floor-control. Your last statement really concerns me. Even if we had consensus that SOAP was the way to encode floor control requests (I am still unconvinced on the value of SOAP for this application), the Wu draft is not going to be amenable to either the SIPPING chairs, the IESG, or the IAB, since it is using SIP to send floor control traffic which is wildly unrelated to the core strengths of SIP. The draft isn't following the SIP communities own rules about SIP extensions. This *really* needs to be another protocol. > Push to talk like applications definitely should not use floor chairs > or floor claim requests > as it would be too slow. Having seen an implementation of PTT using floor control, I have to disagree with you; especially if we select a simple protocol. thanks, -rohan > Instead, they should use fixed media and floor policies > (something like "no floor control protocol for media X, first speaker > is passed through"). > In the rare case that this did not work out (e.g. two persons starts > speaking at the same time) > then there may be negative notification, as markus pointed out. So > this kind of application might > utilize XML/SOAP only for floor creation. Anyway, this specific > example is a service > and IETF does not specify services. > >> I think it would make sense to include the support for this kind of >> scenario also under >> the "floor control" work item in XCON. > > We tried to support this in floor control draft (e.g. create_floor > defines the floor policy > which says whether floor claims are used) but it seems that this work > must be better aligned > with media policy work. > > > -- > Petri > >> -----Original Message----- >> From: ext [mailto:Markus.Isomaki@nokia.com] >> Sent: 16 July, 2003 18:24 >> To: dwillis@dynamicsoft.com; Mayer Georg (NMP/Helsinki); >> xcon@softarmor.com >> Subject: RE: [XCON] RE: Wireless Systems do not flee XML >> >> >> Hi, >> >> I agree that for certain floor control operations latency is >> clearly the most important issue in wireless networks. Push >> to talk type of applications require some very efficient >> mechanism to compete for the "floor", in which case some >> other enconding than XML would seem reasonable. >> >> Actually, for some applications it would be enough just to do >> the contention with the media (i.e. the RTP packets carrying >> the talkburst), and then just to learn if you did NOT get the >> floor through some simple protocol message (in which case the >> person talking would get some negative indication). In other >> words this means that you always don't need to first >> explicitly reserve the floor for you before starting to send >> the media. I believe this is how it works in most of the >> proprietary push to talk apps. >> >> I think it would make sense to include the support for this >> kind of scenario also under the "floor control" work item in >> XCON. First we would ofcourse need some more specifric >> requirements text. >> >> Markus >> >>> -----Original Message----- >>> From: ext Dean Willis [mailto:dwillis@dynamicsoft.com] >>> Sent: 16 July, 2003 11:12 >>> To: Mayer Georg (NMP/Helsinki); xcon@softarmor.com >>> Subject: [XCON] RE: Wireless Systems do not flee XML >>> >>> >>> Georg said: >>> >>>> Dean made a statement during the XCON BOF that the wireless >>>> guys (to which I count myself) do not want XML as it would >>>> use to much bandwidth. That is in fact not true - there were >>>> requirements expressed that XML is the preferred solution for >>>> coding e.g. CPCP, as this would allow us XML also for XCON >>>> purposes and we would not need to implement the next encoder >>>> in our devices. This was actually a requirement that clearly >>>> came out from the last 3G CN1 meeting. >>> >>> >>> I was specifically worried about XML for floor management in >>> a conference. >>> >>> Within the "other" mobile community (3GPP2 -- CDMA) everybody >>> that I've >>> talked is of the belief that the floor control messages for >>> PoC (push talk >>> over cellular) will need to be down in the 20-30 byte range >> (including >>> headers after ROHC) to work optimally with CDMA2000. This >>> allows them to >>> transmit in a single short data burst. >>> >>> XML for configuration and other non-real-time data seems to be ok. >>> >>> -- >>> Dean >>> >>> >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@softarmor.com >>> http://www.softarmor.com/mailman/listinfo/xcon >>> >> >> _______________________________________________ >> XCON mailing list >> XCON@softarmor.com >> http://www.softarmor.com/mailman/listinfo/xcon >> > > _______________________________________________ > XCON mailing list > XCON@softarmor.com > http://www.softarmor.com/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q4CJG4B6; Sun, 10 Aug 2003 11:38:10 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h7AFZLJq022168; Sun, 10 Aug 2003 11:35:21 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AFbFDs030082; Sun, 10 Aug 2003 10:37:18 -0500 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h7AFbDDq030079 for ; Sun, 10 Aug 2003 10:37:13 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7AFb9pp024955; Sun, 10 Aug 2003 08:37:09 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE96751; Sun, 10 Aug 2003 08:30:32 -0700 (PDT) Date: Sun, 10 Aug 2003 08:39:50 -0700 Subject: Re: [XCON] Media Policy in Conferencing Framework Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 To: "Steve Fisher" From: Rohan Mahy In-Reply-To: <000f01c34b1c$353b92d0$2c08d287@fisherlatitude> Message-Id: Content-Transfer-Encoding: 8bit X-Mailer: Apple Mail (2.552) Cc: "'IETF XCON Discussion List \(E-mail\)'" X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Hi, I'm not sure if I replied to this already. If not, sorry for the delay. Conferencing applications from one company can work with mixers from another if the mixer vendor also provides a conference policy server. Apps (from any vendor) | | <- (conf policy control protocol) | Conf Policy Server (from vendor X) | | <- (proprietary protocol) | Mixers (also from vendor X) thanks, -rohan On Tuesday, July 15, 2003, at 02:58 PM, Steve Fisher wrote: > Rohan, > > In your response to Eric you state the following goal for xcon: > > "The goal is to allow customers to select a > conferencing application that can work with many vendor's mixers and > conference servers." > > I'm puzzled how this goal can be achieved when the protocol between the > application server and the mixers is explicitly out of scope for xcon? > According to the charter, the following is out of scope: "Protocol used > between the conference controller and the mixer(s)." > > Steve > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Received: from mail1.dynamicsoft.com (192.168.4.30 [192.168.4.30]) by DYN-EXCH-01.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QG5RLD0V; Mon, 4 Aug 2003 13:29:08 -0400 Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mail1.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id h74HQHtu002328; Mon, 4 Aug 2003 13:26:18 -0400 (EDT) Received: from bdsl.greycouncil.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h74HRbDs011143; Mon, 4 Aug 2003 12:27:40 -0500 Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h74HRYDq011140 for ; Mon, 4 Aug 2003 12:27:34 -0500 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HJ3006CPV1KTU@firewall.wcom.com> for xcon@softarmor.com; Mon, 04 Aug 2003 17:24:57 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HJ300001V1KW7@pmismtp01.wcomnet.com> for xcon@softarmor.com; Mon, 04 Aug 2003 17:24:56 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.128.191]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HJ300095V1I1K@pmismtp01.wcomnet.com> for xcon@softarmor.com; Mon, 04 Aug 2003 17:24:56 +0000 (GMT) Date: Mon, 04 Aug 2003 12:24:48 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: xcon@softarmor.com Message-id: <5.2.1.1.0.20030804122355.023f69c0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [XCON] Fwd: Internal WG Review: Centralized Conferencing(xcon) X-BeenThere: xcon@softarmor.com X-Mailman-Version: 2.1.2 Precedence: list List-Id: IETF XCON BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@softarmor.com Errors-To: xcon-bounces@softarmor.com Content-transfer-encoding: 8bit FYI - progress on the formation of our working group... Thanks, Alan. >Date: Mon, 04 Aug 2003 11:15:48 -0400 >From: iesg-secretary@ietf.org >Subject: Internal WG Review: Centralized Conferencing(xcon) >Sender: nsyracus@cnri.reston.va.us >To: iesg@ietf.org, iab@ietf.org >Cc: alan.johnston@mci.com, adam@dynamicsoft.com >Original-recipient: rfc822;alan.johnston@mci.com > >A new IETF working group is being considered in the >Transport Area. The draft charter for this working group is >provided below for your review and comment. > >Review time is one week. > >The IETF Secretariat > > >Centralized Conferencing (xcon) >--------------------------------- > > Charter > Last Modified: 2003-08-04 > > Current Status: Proposed Working Group > > > CHAIRS: Alan Johnston (alan.johnston@mci.com) > Adam Roach (adam@dynamicsoft.com) > > Mailing list: > List-Archive: > > Transport Area > > Responsible Area Director: Allison Mankin > > Description of Working Group > > The focus of this working group is to develop a standardized suite of > protocols for tightly-coupled multimedia conferences, where strong security > and authorization requirements are integral to the solution. > Tightly-coupled conferences have a central point of control and > authorization so they can enforce specific media and membership > relationships, and provide an accurate roster of participants. The media > mixing or combining function of a tightly-coupled conference need not be > performed centrally, however. > > The scope of this effort is intentionally more narrow than previous > attempts to standardize conferencing (e.g. centralized control), and is > intended to enable interoperability in a commercial environment which > already has a number of non-standard implementations using some of the > protocols. > > Privacy, security, and authorization mechanisms are integral to the > solution generated by the working group. This includes allowing > participants to be completely invisible or to be visible but participate > anonymously with respect to some or all of the other participants. > Authorization rules allow for participants and non-participants to have > roles (ex: speaker, moderator, owner), and to be otherwise authorized to > perform membership and media manipulation for or on behalf of other > participants. In order to preserve these properties, the protocols used > will require implementation of channel security and authentication services. > > Initially this combination of protocols will be specified with respect to > session setup with SIP. The solutions developed in XCON will not preclude > operation with other signaling protocols; however it is anticipated that > the use of other protocols would require modifications which are out of > scope for this working group. > > None of the protocols defined by this group will be SIP, although the SIP > specific event notification framework will be used. The group will use the > high-level requirements and framework already described by documents > published by the SIPPING WG. > > The deliverables for the group will be: > - - A mechanism for membership and authorization control > - - A mechanism to manipulate and describe media "mixing" or "topology" for > multiple media types (audio, video, text) > - - A mechanism for notification of conference related events/changes (for > example a floor change) > - - A basic floor control protocol > > The initial set of protocols will be developed for use in unicast media > conferences. The working group will perform a second round of work to > enhance the set of protocols as necessary for use with multicast media > after their initial publication. > > The following items are specifically out-of-scope: > - - Voting > - - Fully distributed conferences > - - Loosely-coupled conferences (no central point of control) > - - Far-end device control > - - Protocol used between the conference controller and the mixer(s) > - - Capabilities negotiation of the mixer(s) > - - Master-slave cascaded conferences > > The working group will coordinate closely with the SIPPING and MMUSIC > working groups. In addition the working group will cooperate with other > groups as needed, including SIP, AVT, and the W3C SMIL working groups. > In addition, the working group will consider a number of existing drafts (a > non-exhaustive list is included below) as input to the working group. > > Proposed Milestones > > Oct 2003 Submit Requirements for Membership Manipulation for publication as > Informational > Oct 2003 Submit Requirements for Basic Floor Control for publication as > Informational > Nov 2003 Submit Conferencing Scenarios document for publication as > Informational > Nov 2003 Submit Use Cases for Media Topology Control for publication as > Informational > Dec 2003 Submit Requirements for Media Topology Control for publication as > Informational > Feb 2004 Submit Basic Floor Control Protocol for publication as PS > Mar 2004 Submit Notification Event package extension for conference related > events for publication as PS > May 2004 Submit Membership Manipulation Protocol for publication as PS > Jul 2004 Submit Protocol for Media Topology Control for publication as PS > > > _______________________________________________ XCON mailing list XCON@softarmor.com http://www.softarmor.com/mailman/listinfo/xcon