Subject: [XCON] Media Policy in Conferencing Framework

From: adam at dynamicsoft.com (Adam Roach)
Date: Thu Aug 14 16:00:50 2003

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

From: Adam Roach <[email-masked]>
To: "'IETF XCON Discussion List (E-mail)'" <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Thu, 14 Aug 2003 16:00:47 -0500
Sender: [email-masked]

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
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Dolan, Michael F (Mike)" <[email-masked]>
To: "'IETF XCON Discussion List (E-mail)'" <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Thu, 14 Aug 2003 14:32:53 -0500
Sender: [email-masked]

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
[email-masked]

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
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:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> > 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:[email-masked]]
> > 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:[email-masked]]
> > > 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
> > > [email-masked]
> > > http://www.softarmor.com/mailman/listinfo/xcon
> > >
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
> >

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Thu, 14 Aug 2003 10:10:01 -0500
From: Henry Sinnreich <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
To: "'Even, Roni'" <[email-masked]>,  "'Eric Burger'" <[email-masked]>
Organization: WorldCom, Inc.
Cc: "'IETF XCON Discussion List \(E-mail\)'" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> > 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:[email-masked]]
> > 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:[email-masked]]
> > > 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
> > > [email-masked]
> > > http://www.softarmor.com/mailman/listinfo/xcon
> > >
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> >
> >

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Thu, 14 Aug 2003 11:08:38 -0400
From: "Eric Burger" <[email-masked]>
To: "Even, Roni" <[email-masked]>,  "Henry Sinnreich (E-mail)" <[email-masked]>
Cc: "IETF XCON Discussion List \(E-mail\)" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> > 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:[email-masked]]
> > 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:[email-masked]]
> > > 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
> > > [email-masked]
> > > http://www.softarmor.com/mailman/listinfo/xcon
> > > 
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > _______________________________________________
> > XCON mailing list
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > 
> > 
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Even, Roni" <[email-masked]>
To: "'Eric Burger'" <[email-masked]>,  "Even, Roni" <[email-masked]>, "Henry Sinnreich (E-mail)" <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Thu, 14 Aug 2003 09:05:52 +0300
Cc: "IETF XCON Discussion List \(E-mail\)" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
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:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> > 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
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

content-class: urn:content-classes:message
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Wed, 13 Aug 2003 16:51:21 -0400
From: "Eric Burger" <[email-masked]>
To: "Even, Roni" <[email-masked]>,  "Henry Sinnreich (E-mail)" <[email-masked]>
Cc: "IETF XCON Discussion List \(E-mail\)" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
> 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:[email-masked]]
> 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:[email-masked]]
> > 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
> > [email-masked]
> > http://www.softarmor.com/mailman/listinfo/xcon
> > 
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: "Even, Roni" <[email-masked]>
To: Adam Roach <[email-masked]>, "'Rohan Mahy'" <[email-masked]>,  Steve Fisher <[email-masked]>
Cc: "'IETF XCON Discussion List (E-mail)'" <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Tue, 12 Aug 2003 20:38:53 +0300

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:[email-masked]]
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:[email-masked]]
> 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
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

From: Adam Roach <[email-masked]>
To: "'Rohan Mahy'" <[email-masked]>, Steve Fisher <[email-masked]>
Subject: RE: [XCON] Media Policy in Conferencing Framework
Date: Mon, 11 Aug 2003 12:54:47 -0500
Cc: "'IETF XCON Discussion List \(E-mail\)'" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
> 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
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 
_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Sat, 09 Aug 2003 10:30:03 -0700
Subject: Re: [XCON] Floor Control: Charter.
From: Cullen Jennings <[email-masked]>
To: Orit Levin <[email-masked]>,  [email-masked]
Sender: [email-masked]

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" <[email-masked]> 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:[email-masked]]
>> Sent: Thursday, July 17, 2003 5:12 AM
>> To: Jonathan Rosenberg
>> Cc: Rosen, Brian; [email-masked]
>> 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 <[email-masked]>
>> 17/07/2003 11:50 AM
>> 
>> To
>> "Rosen, Brian" <[email-masked]>
>> cc
>> Avshalom Houri/Haifa/IBM@IBMIL, [email-masked]
>> 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:[email-masked]]
>>>> Sent: Thursday, July 17, 2003 4:04 AM
>>>> To: [email-masked]
>>>> 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" <[email-masked]>
>>>> Sent by: [email-masked]
>>>> 17/07/2003 12:50 AM
>>>> 
>>>> To
>>>> [email-masked]
>>>> 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
>>>> [email-masked]
>>>> http://www.softarmor.com/mailman/listinfo/xcon
>>>> 
>>>> _______________________________________________
>>>> XCON mailing list
>>>> [email-masked]
>>>> http://www.softarmor.com/mailman/listinfo/xcon
>>>> 
>>> 
>>> _______________________________________________
>>> XCON mailing list
>>> [email-masked]
>>> http://www.softarmor.com/mailman/listinfo/xcon
>>> 
>> 
>> --
>> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>> Chief Technology Officer                    Parsippany, NJ 07054-2711
>> dynamicsoft
>> [email-masked]                     FAX:   (973) 952-5050
>> http://www.jdrosen.net                      PHONE: (973) 952-5000
>> http://www.dynamicsoft.com
>> 
>> 
>> _______________________________________________
>> XCON mailing list
>> [email-masked]
>> http://www.softarmor.com/mailman/listinfo/xcon
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Sun, 10 Aug 2003 11:59:04 -0400
From: Henning Schulzrinne <[email-masked]>
To: Rohan Mahy <[email-masked]>
Subject: Re: [XCON] RE: Wireless Systems do not flee XML
Cc: [email-masked],  [email-masked],  [email-masked]
Sender: [email-masked]

> 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
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Sun, 10 Aug 2003 08:54:21 -0700
Subject: Re: [XCON] RE: Wireless Systems do not flee XML
To: [email-masked]
From: Rohan Mahy <[email-masked]>
Cc: [email-masked],  [email-masked],  [email-masked]
Sender: [email-masked]

Hi Petri,

Two comments inline.

On Wednesday, July 16, 2003, at 11:45 AM, <[email-masked]> 
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:[email-masked]]
>> Sent: 16 July, 2003 18:24
>> To: [email-masked]; Mayer Georg (NMP/Helsinki);
>> [email-masked]
>> 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:[email-masked]]
>>> Sent: 16 July, 2003 11:12
>>> To: Mayer Georg (NMP/Helsinki); [email-masked]
>>> 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
>>> [email-masked]
>>> http://www.softarmor.com/mailman/listinfo/xcon
>>>
>>
>> _______________________________________________
>> XCON mailing list
>> [email-masked]
>> http://www.softarmor.com/mailman/listinfo/xcon
>>
>
> _______________________________________________
> XCON mailing list
> [email-masked]
> http://www.softarmor.com/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Sun, 10 Aug 2003 08:39:50 -0700
Subject: Re: [XCON] Media Policy in Conferencing Framework
To: "Steve Fisher" <[email-masked]>
From: Rohan Mahy <[email-masked]>
Cc: "'IETF XCON Discussion List \(E-mail\)'" <[email-masked]>
Sender: [email-masked]

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
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon

Date: Mon, 04 Aug 2003 12:24:48 -0500
From: Alan Johnston <[email-masked]>
To: [email-masked]
Subject: [XCON] Fwd: Internal WG Review: Centralized Conferencing(xcon)
Sender: [email-masked]

FYI - progress on the formation of our working group...

Thanks,
Alan.

>Date: Mon, 04 Aug 2003 11:15:48 -0400
>From: [email-masked]
>Subject: Internal WG Review: Centralized Conferencing(xcon)
>Sender: [email-masked]
>To: [email-masked], [email-masked]
>Cc: [email-masked], [email-masked]
>Original-recipient: rfc822;[email-masked]
>
>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 ([email-masked])
>                  Adam Roach ([email-masked])
>
>  Mailing list: <http://www.softarmor.com/mailman/listinfo/xcon>
>  List-Archive: <http://www.softarmor.com/pipermail/xcon>
>
>  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
[email-masked]
http://www.softarmor.com/mailman/listinfo/xcon