Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 10:10:16 -0500

I don't understand this.  I'm not changing the definition of a focus.
I'm observing that the host of the focus is the host of the policy
server, at least for now.  At some point in the future, we could
change this, but now, we can easily make them the same.  

If we use XCAP for CPCP, this seems very straightforward,
and it's even a uri!

suppose the conferenceID is:
  sip:[email-masked]

Then the XCAP URI for this conference is
  http:confa.example.com/cpcp/hishams-weekly-status-meeting...

at least for now.  All I propose is that the root service uri for
CPCP be slightly more structured for CPCP than XCAP, which proposes
that the root service uri be provisioned.  If this offends you
that much, you could always say that if you have an XCAP service
root, use it, adding cpcp/hishams-weekly-status-meeting to it
to access the policy for this conference.

If it's not XCAP, we still use the focus host as the CPCP host,
and the conference uri userpart as the id, with whatever convention
the chosen protocol uses to encode it.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 03, 2003 9:44 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> 
> You are asking to change the definition of a focus. It is 
> created when the conference is instantiated (using your 
> definition of instantiation) and destroyed when the 
> conference instance is destroyed. Therefore, pre-establishing 
> a conference is not possible using CPCP unless a conference 
> is instantiated. That is not desirable.
> 
> We have a conference framework in place, lets use it.
> 
> /Hisham
> 
> > -----Original Message-----
> > From: ext Rosen, Brian [mailto:[email-masked]]
> > Sent: 03.December.2003 14:58
> > To: 'Paul Kyzivat'
> > Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> > [email-masked]; Mayer Georg (NMP-MSW/Helsinki);
> > [email-masked]; [email-masked]
> > Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> > 
> > 
> > Ah, I wondered when we would get to this.
> > 
> > This is one of the bigger problems in separating conference policy 
> > from sip signalling.  Everything would be simpler if the conference 
> > policy server was always the focus.
> > 
> > So, I want to ask, can we make it be so?
> > 
> > What are the advantages of making the conference policy server 
> > separate from the focus?  Two ideas occur to me:
> > 	1. Separation of implementation
> > 		But this is not possible with the current framework
> > 		because we don't specify the interface between 
> > 		CPCP and SIP; we assume that it is proprietary
> > 	2. Load Balancing
> > 		But I really, really doubt that works.  It 
> > would be easier
> > 		to have a separate CPS with every focus, and replicate
> > 		the combination
> > 
> > So, what if we assume they are the same entity, and use the same ID?
> > We don't need to have the conference policy be a URI, we merely have
> > to locate the address of the server.  So, it's the hostname of the
> > conference URI.  And a sip uri is a fine conference ID for the
> > purpose of specifying which policy once we know where the server is.
> > 
> > Is there some advantage of having the conference policy explicitly
> > be a URI that I'm missing?
> > 
> > Brian
> > 
> > > -----Original Message-----
> > > From: Paul Kiribati [mailto:[email-masked]]
> > > Sent: Tuesday, December 02, 2003 2:44 PM
> > > To: Rosen, Brian
> > > Cc: [email-masked]'; [email-masked];
> > > [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference
> > > 
> > > 
> > > 
> > > 
> > > Rosen, Brian wrote:
> > > >>
> > > >>If you look at XCAP list usage for example, you will see that 
> > > >>the list-URI used when sending SIP SUBSCRIBE requests to the 
> > > >>list is not the same as the URI used to manipulate the list 
> > > >>using XCAP. They certainly need to be linked, but not 
> > > >>necessarily the same.
> > > >>
> > > >>Depending on the protocol we chose, a SIP URI can or cannot 
> > > >>be used to identify a conference policy.
> > > > 
> > > > I think we CAN always have the same ID.
> > > > I think there is a lot of value in one ID
> > > > I don't think there is any problem in having one ID
> > > > 
> > > > So, I think there should be one.
> > > > 
> > > > If there is a good reason, we can burden the conference 
> > > policy server
> > > > with keeping the relationship, but unless there is a good 
> > > reason, history
> > > > suggests that one namespace is better than two with linkage.
> > > 
> > > [The chicken and the egg are different things. If I want to 
> > > talk to the 
> > > egg I need the address of the egg - having the address of 
> > the chicken 
> > > isn't sufficient. Its probably a bad idea to crack the egg in 
> > > order to 
> > > ask the chicken for the address of the egg.]
> > > 
> > > Getting away from metaphors, this seems to be coming down to the 
> > > distinction between URIs and URLs.
> > > 
> > > A sip address is a URL in that it is sufficient for me to 
> locate a 
> > > corresponding (sip) resource.
> > > 
> > > But it isn't sufficient for me to locate a CPCP resource. If 
> > > I knew how 
> > > to contact the appropriate CPCP server, perhaps a sip uri 
> > > could serve to 
> > > identify the policy. But that would require me to know the 
> > address of 
> > > the server a-priori.
> > > 
> > > If all I have is the sip conference id, then to derive the 
> > > URI for the 
> > > policy from it I must invoke sip operations on it.
> > > 
> > > 	Paul
> > > 
> > > 
> > > _______________________________________________
> > > XCON mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > > 
> > 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2003 18:41:09 -0500

I am in agreement with Alan and others that binding the names of the two 
  uris together algorithmically is a terrible idea, at least as part of 
a standard. (There is nothing to stop a particular implementation from 
doing this. It just won't be interoperable, and needn't be.)

What we have here are not two names for the same thing, but rather two 
names for different things that happen to be in 1:1 correspondence with 
one another. We have
- a sip uri identifying the focus of a conference
- an http uri identifying the policy for a conference

If all an application cares about is call control, then all it needs to 
implement is sip, and the only identifier it needs is the sip uri.

If all an application cares about is policy managment, then all it needs 
to implement is http and xcap, and the only identifier it needs is the 
http uri.

If an application cares about both of these, then it must implement both 
sets of protocols, and it needs both uris. Each protocol should provide 
a protocol to obtain the uri for the other object/protocol.

	Paul

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 4 Dec 2003 13:59:52 +0200

I agree with Paul, Alan and I think that also Orit. The XCON protocol 
should be a different protocol from SIP.
Other protocols that will want to create conferences should be able to use 
ti.

Reading again the XCON charter it explicitly says that the XCON protocol 
can be used by other protocols.
I think that  coupling INVITE with the conference creation does not agree 
with the charter.

<<<
Due to the centralized architecture of the WG, XCON's mechanisms will 
place requirements on the signaling protocol used between the focus and 
the participants. At a high level, the signaling protocol must be able 
to establish, tear down, modify, and perform call control operations on
multimedia streams, including voice, video, and instant messaging, in 
both a centralized and distributed mixing architecture. SIP will be the 
reference session signaling protocol used for examples; however, none of 
the XCON solutions themselves will be signaling protocols, nor will XCON 
extend existing signaling protocols. Other signaling protocols than SIP 
may be used between the focus and participants, including non-IETF 
protocols, but the requirements and possible extensions needed for other 
signaling protocols to utilize the full functionality of the XCON 
architecture is outside the scope of XCON.

Avshalom
_______________________
Avshalom Houri
Architect - Lotus Software, IBM SWG
Science Park, Building 18 floor D Rehovot, Israel 76470
Email: [email-masked]
Office: +972-8-9409761 Ext. 123 Fax: +972-8-9944697 Cell: +972-54-686021

Paul Kyzivat <[email-masked]> 
Sent by: [email-masked]
04/12/2003 01:41 AM

To
 [email-masked]
cc

Subject
Re: [XCON] Chicken and Egg - Can CPCP create a conference

                 Paul

---

From: Michael Hammer <[email-masked]>
Date: Thu, 04 Dec 2003 13:38:41 -0500

From the peanut gallery, inline below.

>I think that  coupling INVITE with the conference creation does not agree 

Help me understand this.  Not knowing the protocol syntax of XCON, is it 
not possible that CPCP could be orthogonal to SIP?  Could for instance the 
CPCP be a body that is carried inside a SIP message so that both could be 
established coincidentally as well as in separate messages?

>both a centralized and distributed mixing architecture.

>***SIP will be the
>extend existing signaling protocols.***

This seems to indicate that what I suggest above is not only possible, but 
desirable.  But, I am still trying to align the picture in my head with 
what is in other's heads.

Mike

>Other signaling protocols than SIP
>Email: <mailto:[email-masked]>[email-masked]