Subject: RE: [XCON] Conference Control

From: "Chris Boulton" <[email-masked]>
Date: Fri, 27 Jan 2006 15:12:35 -0000

Hi Brian,

Clarification in-line.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 27 January 2006 14:27
To: Chris Boulton; [email-masked]
Cc: [email-masked]; 'Adam Roach'
Subject: RE: [XCON] Conference Control

I'm not opposed to having two bindings to the same interface, but I
would not want to see two interfaces.  That means the models, data
structures, operations, errors, etc would have to be identical, with
only transport being different.  I'm not sure that would be particularly
interesting to you.

Also, could you clarify your statements on CSCP?  What you said was "it
may be likely, as it is not mandatory, that BFCP be implemented in the
solution and so developing support for something like CSCP would be seen
as a burden".  I can't figure out if you WILL implement BFCP, and thus
CSCP is easy, or you won't implement BFCP because it's not mandatory and
thus CSCP would be a burden.  I think if you implement BFCP then CSCP is
relatively less work from there. 

[Chris Boulton] The XCON Framework reads:

Floor control is not a mandatory mechanism for a conferencing system
implementation but provides advanced media input control features for
conference users.

So the point I was trying to convey was that BFCP, as it stands in the
Framework is not mandatory.  So for an element wanting to use just CSCP
would have to develop from scratch.  In this scenario, just having to
expose a WSDL initiated web interface is preferred.

Chris.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton
Sent: Friday, January 27, 2006 5:01 AM
To: [email-masked]
Cc: [email-masked]; Adam Roach
Subject: [XCON] Conference Control

Hi All,

Just wanted to generate some discussion relating to the recent
Conference Control submissions.  I would like to begin by thanking all
the relevant parties for the effort contributed before Christmas.  

While I realise that the thoughts conveyed in this mail are a little
controversial, I thought I would poke my head up into the firing line in
attempt to stimulate some discussion.  I have reviewed all of the
proposals and will be providing questions and feedback in individual
mails.  This mail is an attempt to discuss some architectural decisions
that I personally feel are equally as important.  As some of you may
already know, I am a supporter of the SOAP proposals (Henning, myself
and Mary) that are currently being worked on.  This led me to realise
that my preference was being swayed (purely selfish :-) by 'who exactly
will be a conference client manipulating Conference Objects?'  As an
application server vendor who's product very much utilises web services.
SOAP seems the obvious choice.  From a handset vendor I can also see
that proposals such as CCCP and CSCP are more appealing.  As an
application server offering conferencing services using web services it
may be likely, as it is not mandatory, that BFCP be implemented in the
solution and so developing support for something like CSCP would be seen
as a burden, especially as we already have a web services interface that
provides all the relevant infrastructure to link to our clients.

It is for these reasons that I was pondering the prospect of XCON
allowing both a handset friendly interface such as CSCP and a SOAP
interface for web services where the client might well be another
application and not a handset.  I realise that having two interfaces is
not ideal, but as long as we are careful in our rules on minimal
implementation and ability to advertise capabilities to a Conference
Client I personally feel that this is the best solution to make XCON
appealing to a wide variety of architectures.

I'm going to duck now and wait for incoming bullets but on a serious
note I strongly appeal to all who are interested on making Dallas a
productive meeting to comment on mails such as this over the coming
months.

Best Regards,

Chris Boulton.

Information contained in this e-mail and any attachments are intended
for the use of the addressee only, and may contain confidential
information of Ubiquity Software Corporation. All unauthorized use,
disclosure or distribution is strictly prohibited.  If you are not the
addressee, please notify the sender immediately and destroy all copies
of this email.  Unless otherwise expressly agreed in writing signed by
an officer of Ubiquity Software Corporation, nothing in this
communication shall be deemed to be legally binding. Thank-you 

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

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

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Fri, 27 Jan 2006 16:32:18 +0100

Hello Chris,
 
I think you are focusing too much in the web services. The protocol we
choose has to have a good performance in a bunch of uses cases, not only
web services (for instance: mobile phones, PDA, wireless, etc...) and I
believe CSCP is much compact and it will have a better performance in
wireless, and handset devices than SOAP. 
And another thing that is quite important, CSCP can be uses in web
services but, probably, SOAP will be a problem in some systems with low
bandwidth.
 
Oscar

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton
Sent: 27. tammikuuta 2006 12:01
To: [email-masked]
Cc: [email-masked]; Adam Roach
Subject: [XCON] Conference Control

Hi All,

Best Regards,

Chris Boulton.

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Fri, 27 Jan 2006 16:37:23 +0100

Chris,
 
Notice that almost all the conference systems will implement the BFCP
even thought it is not compulsory. So, at the end few systems would have
to develop the protocol from scratch but If SOAP is going to be the
protocol all the conference systems have to develop the protocol from
scratch.
 
Oscar

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton
Sent: 27. tammikuuta 2006 17:13
To: [email-masked]; [email-masked]
Cc: [email-masked]; Adam Roach
Subject: RE: [XCON] Conference Control

Hi Brian,

Clarification in-line.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 27 January 2006 14:27
To: Chris Boulton; [email-masked]
Cc: [email-masked]; 'Adam Roach'
Subject: RE: [XCON] Conference Control

Chris.

Brian

Hi All,

Best Regards,

Chris Boulton.

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 27 Jan 2006 16:08:54 -0000

Okay, so, we could talk about two bindings for one data model/interaction model if we wanted to.  

An interesting question follows from that: would you want a SOAP based binding for floor control?

[Chris Boulton] I was actually musing the same question as I received yours.  I certainly think it would be useful.

Brian

  _____  

From: Chris Boulton [mailto:[email-masked]] 
Sent: Friday, January 27, 2006 11:00 AM
To: Oscar Novo (JO/LMF); [email-masked]; [email-masked]
Cc: [email-masked]; Adam Roach
Subject: RE: [XCON] Conference Control

I think it´s quite obvious. :) 

But anyway, still all the systems have to implement the SOAP protocol  from the scratch and this is not the case of CSCP even if the systems that support the BFCP are low. 

Don´t be mad at me. :)

[Chris Boulton] hehehe - how could I.  This isn't a 'vs' debate - I'm just saying that if you have got a web services SOAP interface, it would be useful for XCON to provide hooks so that clients (e.g. J2EE applications not UA's or handsets) can control conferences using mechanisms that they find common e.g. SOAP, WSDL, UDDI.  I agree that this Conference System would almost certainly have a BFCP interface (and therefore a CSCP interface), but my client application would probably not. 

  _____  

From: Chris Boulton [mailto:[email-masked]] 
Sent: 27. tammikuuta 2006 17:43
To: Oscar Novo (JO/LMF); [email-masked]; [email-masked]
Cc: [email-masked]; Adam Roach
Subject: RE: [XCON] Conference Control

Chris,

Notice that almost all the conference systems will implement the BFCP even thought it is not compulsory.

[Chris Boulton] What proof is this comments based on?

 So, at the end few systems would have to develop the protocol from scratch but If SOAP is going to be the protocol all the conference systems have to develop the protocol from scratch.

Oscar

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton

Hi Brian,

Clarification in-line.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 27 January 2006 14:27
To: Chris Boulton; [email-masked]
Cc: [email-masked]; 'Adam Roach'
Subject: RE: [XCON] Conference Control

I'm not opposed to having two bindings to the same interface, but I would not want to see two interfaces.  That means the models, data structures, operations, errors, etc would have to be identical, with only transport being different.  I'm not sure that would be particularly interesting to you.

Also, could you clarify your statements on CSCP?  What you said was "it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden".  I can't figure out if you WILL implement BFCP, and thus CSCP is easy, or you won't implement BFCP because it's not mandatory and thus CSCP would be a burden.  I think if you implement BFCP then CSCP is relatively less work from there. 

Floor control is not a mandatory mechanism for a conferencing system implementation but provides advanced media input control features for conference users.

So the point I was trying to convey was that BFCP, as it stands in the Framework is not mandatory.  So for an element wanting to use just CSCP would have to develop from scratch.  In this scenario, just having to expose a WSDL initiated web interface is preferred.

Chris.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: Friday, January 27, 2006 5:01 AM
To: [email-masked]
Cc: [email-masked]; Adam Roach
Subject: [XCON] Conference Control

Hi All,

Just wanted to generate some discussion relating to the recent Conference Control submissions.  I would like to begin by thanking all the relevant parties for the effort contributed before Christmas.  

While I realise that the thoughts conveyed in this mail are a little controversial, I thought I would poke my head up into the firing line in attempt to stimulate some discussion.  I have reviewed all of the proposals and will be providing questions and feedback in individual mails.  This mail is an attempt to discuss some architectural decisions that I personally feel are equally as important.  As some of you may already know, I am a supporter of the SOAP proposals (Henning, myself and Mary) that are currently being worked on.  This led me to realise that my preference was being swayed (purely selfish :-) by 'who exactly will be a conference client manipulating Conference Objects?'  As an application server vendor who's product very much utilises web services. SOAP seems the obvious choice.  From a handset vendor I can also see that proposals such as CCCP and CSCP are more appealing.  As an application server offering conferencing services using web services it may be likely, as it is not mandatory, that BFCP be implemented in the solution and so developing support for something like CSCP would be seen as a burden, especially as we already have a web services interface that provides all the relevant infrastructure to link to our clients.

It is for these reasons that I was pondering the prospect of XCON allowing both a handset friendly interface such as CSCP and a SOAP interface for web services where the client might well be another application and not a handset.  I realise that having two interfaces is not ideal, but as long as we are careful in our rules on minimal implementation and ability to advertise capabilities to a Conference Client I personally feel that this is the best solution to make XCON appealing to a wide variety of architectures.

I'm going to duck now and wait for incoming bullets but on a serious note I strongly appeal to all who are interested on making Dallas a productive meeting to comment on mails such as this over the coming months.

Best Regards,

Chris Boulton.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 30 Jan 2006 11:17:19 -0000

So it looks to me like we MIGHT be getting somewhere.  I'd be interested to know what the chair's make of this current discussion and if they think it will be achievable.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 27 January 2006 23:29
To: 'Sean Olson'; Chris Boulton; 'Henning Schulzrinne'; 'Oscar Novo (JO/LMF)'
Cc: [email-masked]
Subject: RE: [XCON] Conference Control

Just to be clear, I don't have a problem with multiple bindings as long as
the underlying data structures and operations are the same.

I think having a protocol that had both a SOAP binding, and something fast
and small, especially for the typical operations, is a good thing.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean
Olson
Sent: Friday, January 27, 2006 6:26 PM
To: Chris Boulton; Henning Schulzrinne; Oscar Novo (JO/LMF)
Cc: [email-masked]
Subject: RE: [XCON] Conference Control

I think Chris' proposal is very reasonable. Why is this an either-or
discussion? Why not allow multiple bindings? I think it would be a mistake
to create a least common denominator approach to satisfy the constraints of
CPU/bandwidth limited devices.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Boulton
Sent: Friday, January 27, 2006 9:28 AM
To: Henning Schulzrinne; Oscar Novo (JO/LMF)
Cc: [email-masked]
Subject: RE: [XCON] Conference Control

Compared to implementing the logic of conference control, the encapsulation
is a tiny fraction of the work, particularly given that you can get SOAP
stacks pre-packaged for almost any conceivable platform and language, mobile
or otherwise. (A SOAP client is nothing more than a bit of XML on top of
HTTP, so you don't even need a stack, just an XML parser and an HTTP client
library, both of which any SIP-speaking device will need in any event.)

[Chris Boulton] Agreed.

Thus, I don't think this is much of a differentiator.

[Chris Boulton] Either way - I am fed up of it being 'the only'
differentiator.

Oscar Novo (JO/LMF) wrote:
> But anyway, still all the systems have to implement the SOAP protocol  
> from the scratch and this is not the case of CSCP even if the systems 
> that support the BFCP are low.

Information contained in this e-mail and any attachments are intended for
the use of the addressee only, and may contain confidential information of
Ubiquity Software Corporation.  All unauthorized use, disclosure or
distribution is strictly prohibited.  If you are not the addressee, please
notify the sender immediately and destroy all copies of this email.  Unless
otherwise expressly agreed in writing signed by an officer of Ubiquity
Software Corporation, nothing in this communication shall be deemed to be
legally binding.  Thank you.

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 30 Jan 2006 18:38:36 +0200

Hi,

This brings up an interesting question, is floor control needed for
conferencing, probably yes in some cases. So this may mean two separate
control channels. Maybe it will make sense, once we decide on the
protocol/s to define if we can tunnel BFCP through this protocol.

Roni Even

Sent: Friday, January 27, 2006 5:43 PM

Chris,

Notice that almost all the conference systems will implement the BFCP
even thought it is not compulsory.

 So, at the end few systems would have to develop the protocol from
scratch but If SOAP is going to be the protocol all the conference
systems have to develop the protocol from scratch.

Oscar

Hi Brian,

Clarification in-line.

Chris.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 27 January 2006 14:27
To: Chris Boulton; [email-masked]
Cc: [email-masked]; 'Adam Roach'
Subject: RE: [XCON] Conference Control

Chris.

Brian

Hi All,

Best Regards,

Chris Boulton.