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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Dec 2003 13:26:20 -0500

I'd like to re-open the requirement to create a conference with CPCP.
Somehow, I missed that one.

Generally, I think it's a bad idea to have two ways to do something, and we
have another way to create a conference (conference factory uri).  I'd
like to eliminate one of them if possible.

Beyond that, it seems to me that there is a chicken and egg problem with
CPCP.  That is, how do you "start" sending CPCP "commands", and to whom
do you address them?  This is an issue that intertwines with the signalling
protocol (sip).  In my mind, the conference uri gave you an address (the
host of the focus) and an identifier (the userpart of the uri).  Now,
in at least the first version of all of this, do we need to have some kind
of discovery mechanism for the conference policy server?  I think not,
or at least I think you get it from the focus.  I'd propose that it is
precisely the host of the focus, but I'd be okay with a query to the focus
that returned the address of the conference policy server. 

So, if I were choosing, I would not permit CPCP to create conferences.
I would rely on the conference factory URI (as well as out of band means).
I would make the conference policy server the same host as the conference
uri, or at least make the focus return the address of conference policy
server.
If you need a conference uri to get the conference policy server address,
then you can't use CPCP without a conference URI, and thus using CPCP to
create/discover a conference URI wouldn't work.

Brian

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

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 1 Dec 2003 12:02:29 -0800

Brian!
I am actually surprised by this thread.

In reality, a single conference instance can be potentially defined /
requested by million ways. Moreover, the same conference instance can
host participants joining by very different means and media. Moreover,
the same conference can have more than a single unique identifier...

SIP conferencing and XCON conferencing must be able to coexist in the
system and share same conference instances but apart from that - each is
a "complete system" on its own. (SIP point-to-point CC is a different
issue - it is one of the tools available for XCON.)

As a result, the discussion of the addressing scheme should first apply
to the SIPPING conferencing work. (In XCON we still need to agree on the
higher level architectural decomposition of the pieces that we managed
to introduce.)

In particular, draft-ietf-sipping-cc-conferencing-02.txt has different
assumptions or, I should say, is less restrictive that you propose
below. BTW, it does define that "calling a Factory" results in
establishing a conference with its focus (either through the same dialog
or by redirection to a focus - both are valid cases). If we disagree on
this, let's start this discussion in SIPPING ASAP.

Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Monday, December 01, 2003 10:26 AM
To: [email-masked]'
Subject: [XCON] Chicken and Egg - Can CPCP create a conference

Generally, I think it's a bad idea to have two ways to do something, and
we
have another way to create a conference (conference factory uri).  I'd
like to eliminate one of them if possible.

Beyond that, it seems to me that there is a chicken and egg problem with
CPCP.  That is, how do you "start" sending CPCP "commands", and to whom
do you address them?  This is an issue that intertwines with the
signalling
protocol (sip).  In my mind, the conference uri gave you an address (the
host of the focus) and an identifier (the userpart of the uri).  Now,
in at least the first version of all of this, do we need to have some
kind
of discovery mechanism for the conference policy server?  I think not,
or at least I think you get it from the focus.  I'd propose that it is
precisely the host of the focus, but I'd be okay with a query to the
focus
that returned the address of the conference policy server. 

So, if I were choosing, I would not permit CPCP to create conferences.
I would rely on the conference factory URI (as well as out of band
means).
I would make the conference policy server the same host as the
conference
uri, or at least make the focus return the address of conference policy
server.
If you need a conference uri to get the conference policy server
address,
then you can't use CPCP without a conference URI, and thus using CPCP to
create/discover a conference URI wouldn't work.

Brian

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 1 Dec 2003 13:11:10 -0800

I agree with the general principles below :-)
In my view they don't contradict the points that I stressed in my
previous mail.
That is NOT for the sake of other (than SIP) protocols - it is for the
sake of simple conferencing using SIP and clean extensible conferencing
design using XCON.

Cheers,
Orit.

BTW Using URI as a conference ID - is OK. Prescribing its structure - I
don't think so. 

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Monday, December 01, 2003 12:37 PM
To: Orit Levin; [email-masked]
Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference

Orit

Keeping XCON separate from SIP is useful so long as it doesn't 
get in the way of common sense.  To me, that would mean, for example, 
having a different name space for a conference ID, requiring one 
for CPCP and another for SIP.  If a conference ID in CPCP is not a 
uri, for which a SIP uri is an excellent, but not limiting example, 
I have a very large problem.

I don't care if some day, someone invents a way to use CPCP without 
SIP, and I don't have any interest in making that difficult in any way.
However, it's not a driving function, and I don't think there is 
any reason to have more than one standardized way to create a
conference.  
An INVITE to a conference URI does it.  A specific implementation may 
have some other, non standardized way.  I want ONE standardized way, 
unless someone has a compelling reason why we need to have two.  
It's a broken record; when you have multiple ways to do the same thing, 
you facilitate incompatible implementations.  If there are a million 
ways, you will have a lot of incompatible systems.  I have no interest 
in fostering that kind of design.

Brian

> From: Orit Levin [mailto:[email-masked]]
> Sent: Monday, December 01, 2003 3:02 PM
> To: Rosen, Brian; [email-masked]
> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> 
> Brian!

---

From: Alan Johnston <[email-masked]>
Date: Mon, 01 Dec 2003 15:11:54 -0600

At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote:
>any reason to have more than one standardized way to create a conference.

Brian,

Please re-read the SIP Conferencing Framework document - practically every 
conference-related operation has both a SIP and a non-SIP mechanism to do so.

Thanks,
Alan
sip:[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2003 16:21:15 -0500

Brian - inline.

	Paul

Rosen, Brian wrote:
> An INVITE to a conference URI does it. 

I have one problem with this, and perhaps it is small enough to be ignored:

If I want to create a scheduled conference for some time in the future, 
perhaps from an application with a web interface, then using an INVITE 
to do so seems peculiar. I don't want to establish a dialog with the 
focus now. I don't even what a focus now. All I want is an address that 
uniquely addresses the conference policy server and the conference to be 
defined. I especially don't want to open any media streams, or force the 
server to assign media resources just in case I might need them.

But it may indeed be possible to use sip in a specific way to achieve 
all that is needed. For instance, perhaps an invite could be sent with a 
medialess offer, together with some headers that indicate desire for 
suitable features. If this was sufficiently specific for the server to 
get the hint, the response could be a 3xx with a contact for the policy 
server (http url). This may however be a viewed as a hack.

If I am forced to send a real invite, and establish and invite dialog, 
in order to learn the policy server address, then what happens if I then 
change the conference policy to start at a particular time in the 
future? Does my call immediately get terminated?

	Paul

 > A specific implementation may

---

From: [email-masked]
Date: Tue, 2 Dec 2003 00:25:59 +0200

Hi,

> This is a reason I don't want a conference factory uri to instantiate
> a conference.  I want to send an INVITE to the factory URI, 
> get a conference
> ID, manipulate it's policy, and then INVITE/REFER participants.

I may have problems understanding this, so I have to ask. I understand the current work on SIP conferencing in a way, that I can send a conf-factory URI to a server, which then, during establishment of the session/invite dialog, creates the conference and with it the conference URI. It returns the conference URI latest in the 200 (OK) response to me (in the Contact header) and then I am in the conference. So I would not need to dial into the conference again.

Do you think this is ok?

If not, then I would have a problem to use an INVITE request to ... "connect" to the conference-factory URI in order to create the conference URI. An INVITE is supposed to establish a media session, but in that case it would be used only for conference URI creation. Then maybe (!) the OPTIONS or some other request would be better suited.

But from my point of view it is easy, conveninant und nice that I just call the conf-facotry and <<bing>> I'm in the conference.

Best regards
Georg

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Rosen, Brian
> Sent: 02 December, 2003 00:10
> To: 'Paul Kyzivat'
> Cc: 'Orit Levin'; [email-masked]
> I think you need to be able to manipulate policy before a conference
> is instantiated.  So, policy is available as soon as you have a valid
> conference ID (ie conference uri).
> 
> This is a reason I don't want a conference factory uri to instantiate
> a conference.  I want to send an INVITE to the factory URI, 
> get a conference
> ID, manipulate it's policy, and then INVITE/REFER participants.
> 
> Brian
> 
> > From: Paul Kyzivat [mailto:[email-masked]]
> > Sent: Monday, December 01, 2003 4:21 PM
> > To: Rosen, Brian
> > Cc: 'Orit Levin'; [email-masked]
> > Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference
> > 
> > 
> > Brian - inline.
> > 
> > 	Paul
> > 
> > Rosen, Brian wrote:
> > > Orit
> > >

---

From: [email-masked]
Date: Tue, 2 Dec 2003 11:43:00 +0200

Again, you are tying ah-hoc conferences with scheduled ones. Conferences are not always ad-hoc. There is no conference policy for an ad-hoc conference that is created with a conference factory URI. The focus does not create a conference policy. A conference server reading a conference policy creates the focus at the time the conference is scheduled to start.

Conference Policy server address needs to be provisioned, just like the conference factory URI.

Regards,
Hisham

> Sent: 01.December.2003 20:26
> To: [email-masked]'

---

From: [email-masked]
Date: Tue, 2 Dec 2003 11:58:24 +0200

> Sent: 02.December.2003 00:07
> To: 'Alan Johnston'; 'Orit Levin'; [email-masked]
> Guilty of not reading documents carefully enough.
> Most of the "duplicate" mechanisms were, on my reading, merely
> reflecting the observation that the focus is one end of the
> dialog each participant has, and in SIP, either end can
> initiate most operations, thus there is really no possibility
> of incompatible implementations.  Re-reading, I think we may
> want to beef up the wording to make sure of it.  
> 
> The only case where I think CPCP actually "creates" a conference
> is where there is a dial out with no-one dialing in before the
> dial out occurs.  It should not be possible, I think, to "create"
> a conference before someone dials in or the focus dials out.

This might be a local policy of the conference server, or it can be configured using CPCP itself.

> 
> Similarly, a conference is destroyed when the last dialog is
> terminated with a BYE, which may very well be by the focus,
> but it is not terminated explicitly by CPCP.

CPCP does not termiate, it provides a policy. Part of that policy could be a stop-time for the confernece whre the conference focus is not removed until the time is up. A conference policy that does not define a stop-time could mean that a conference is terminated as soon as the last participant departs.

> 
> Looking at the other mechanisms:
>   Adding participants
> 	Similar to creating conferences, you can dial out or dial in.
> 	I think we might want to observe in the text that focus
> 	implementations MUST accept INVITES and REFERS, as well as
> 	CPCP requests to send INVITES.  A UA could implement either or
> 	both mechanisms.  I would observe that if a UA wishes to promote
> 	a two way to a conference, then it would have to use a 
> REFER, and
> 	no other mechanism.  I'd prefer that the SIP way be the 
> only way,
> 	but the carriers seem to want to control who does the 
> dialing, so
> 	there is no way the community would support REFER only.
>   Removing Participants
> 	Again, mostly a "both ends of the dialog" issue.  BYE from focus
> 	really is an acceptable way to boot someone.  3rd party REFER
> 	really is a duplicate, but prohibiting it seems unlikely.  In
> 	most systems it wouldn't work from, say, a moderator, because
> 	of security issues (a random user can't REFER/BYE you I hope).
> 	Probably need to expand that wording to say "third person
> 	(another participant) departures..."  I don't want to imply
> 	that the focus would use REFER.  It would use BYE.

CPCP is used to indicate the desire to remove someone. The focus, after receiving a notification on the updated policy, as a result sends a BYE to that participant.

This is only the case when the conference is currently active. But with a scheduled conference that has not started yet. A BYE seems hardly an appropriate mechanism to remove someone from, say, a dial-out list. A CPCP command modifying the dial-out list is more appropriate.

> 
> 	I note that the text in this section about the focus 
> manipulating
> 	other dialogs is misplaced, because it would do the same thing
> 	if the participant was removed by SIP or any other means.
>   Obtaining Membership
> 	I don't see why we need two mechanisms.  If we keep 
> both, then we
> 	should explicitly require a focus to implement both.  I really
> 	don't care which one we keep.

Again, CPCP is used to create a conference policy, not a conference. The focus add/removes members using the one and only one mechanism, SIP. But remember, you can manpulate conference policy even when the conference is not running, ie: there is no focus yet.

/Hisham

> 
>   Adding and Removing Media
> 	"Both ends of the dialog" issues.  Again, a focus probably can't
> 	help but implement both, but it might be good to say that
> 	explicitly somewhere.
> 
> Brian
> 
> 
> > From: Alan Johnston [mailto:[email-masked]]
> > Sent: Monday, December 01, 2003 4:12 PM
> > To: Rosen, Brian; 'Orit Levin'; [email-masked]

---

From: [email-masked]
Date: Tue, 2 Dec 2003 12:03:04 +0200

> Sent: 02.December.2003 00:10
> To: 'Paul Kyzivat'

If you want a conference with a policy, the conference factory URI is not the write choice since it is only used for ah-hoc conferences that don't have user specified policy.

In the scenario you describe, you would upload a conference policy using CPCP and get back a conference URI. You can manipulate that policy and you may or may not need the conference URI to do that (our XCAP based solution proposaql uses the XCAP URI).

Users can then send INVITE requests to join the confernece when the start-time has passed.

/Hisham

---

From: [email-masked]
Date: Tue, 2 Dec 2003 12:05:38 +0200

> [email-masked]
> Sent: 02.December.2003 00:26
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> I may have problems understanding this, so I have to ask. I 
> understand the current work on SIP conferencing in a way, 
> that I can send a conf-factory URI to a server, which then, 
> during establishment of the session/invite dialog, creates 
> the conference and with it the conference URI. It returns the 
> conference URI latest in the 200 (OK) response to me (in the 
> Contact header) and then I am in the conference. So I would 
> not need to dial into the conference again.
> 
> Do you think this is ok?

This is how the cc-conferencing describes it in sipping, and I agree with it.

/Hisham

> 
> If not, then I would have a problem to use an INVITE request 
> to ... "connect" to the conference-factory URI in order to 
> create the conference URI. An INVITE is supposed to establish 
> a media session, but in that case it would be used only for 
> conference URI creation. Then maybe (!) the OPTIONS or some 
> other request would be better suited.
> 
> But from my point of view it is easy, conveninant und nice 
> that I just call the conf-facotry and <<bing>> I'm in the conference.
> 
> Best regards
> Georg
>

---

From: [email-masked]
Date: Tue, 2 Dec 2003 12:07:28 +0200

Yes. After the conference server creates the focus on the scheduled time that was set using CPCP, the focus can use SIP INVTE or whatever protocol it desires to invite participants into the conference, or accpet participants to join a conference.

/Hisham

> Rohan Mahy
> Sent: 02.December.2003 00:58
> To: Rosen, Brian
> Cc: 'Alan Johnston'; 'Orit Levin'; [email-masked]
> On Monday, December 1, 2003, at 02:06 PM, Rosen, Brian wrote:
> 
> I can think of several reasons to create a conference before 
> there are 
> any participants/legs/users:
> 
> - A scheduled conference which has policies set by the creator before 
> the creator joins
> - A long running conference/group chat
> - A dial out conference
> 
> So clearly having a mechanism to create conferences using CPCP makes 
> sense.
> 
> Now if someone wants to create (possibly standardized) mechanisms in 
> other protocols to create an XCON  conference, I see no 
> reason why this 
> is a problem.  The SIP conferencing framework describes a role (a 
> conference factory) that has a URI you can INVITE that will create an 
> XCON conference.  You could define a similar function for HTTP, XMPP, 
> iCal via SMTP, or H.323.
> 
> thanks,
> -rohan
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Dec 2003 08:15:54 -0500

Well it's clear that my view is different from you-all.
Not an unfamiliar situation :(
Let me keep trying a while, but I'll cave if I'm out here
by myself for too long.

Several points to make.  In my view:
1. "Instantiating" a conference is a concept that is getting confusing.
It's all in what you mean.  I think it's when the mixer resources
are actually allocated (as opposed to reserved).  That starts when
the first participant creates a dialog with the focus, and ends
when the last dialog terminates.  Getting a conference ID doesn't
instantiate a conference, creating a dialog with it does.

You can have a policy on whether the conference ID expires when 
the last dialog terminates.  If it does, once the conference
instantiation terminates, it cannot be re-instantiated.  
If it doesn't, then it can be re-instantiated.  An example of the 
latter is a weekly sales meeting or a "meet-me" number.  
An example of the latter could be a 4-way call created by a CONF 
button.

2. You can manipulate policy before you instantiate a conference.
As soon as a conference ID is created, policy is available to be
manipulated on it.  

3. There is almost no difference between a pre-established 
conference and an ad-hoc conference.  Try and think of something 
that matters:
	Time between creation of conference ID and instantiation?
		Nope; you can pre-establish a conference and use it 
		immediately, and there can be an arbitrary delay between 
		requesting an ad-hoc conference and the first dialog 
		with it.  And even if there was, who cares?
	DialIn/DialOut 
		Nope - both can do both, or a mixture of either
	"Long running conference/chat"  Nope; length of time of a
		conference/chat is not relevant, you could start one 
		ad-hoc and leave it run for years.
Therefore, I think you can't use CPCP for pre-established 
conferences and SIP for ad-hoc conferences.  Pick one.  There is no 
justification for two mechanisms to do the same thing.  I have a 
problem with policy creating a conference, and I think SIP 
signalling is a more appropriate way to create a conference, but 
I care more about having one and only one way to do it.

4. My view of the conference factory was that you didn't get a 
conference instantiation from it, you only got a conference ID.  
Either end would immediately terminate the conference factory dialog, 
either by an actual BYE or a REFER.  If you wanted to immediately 
instantiate the conference after getting the conferenceID, fine, 
but you don't have to; you can just get the conference ID and
instantiate later.  Later could be milliseconds or, if policy 
allowed, years.

5. I agree that non-SIP signalling mechanisms could be standardized 
to create conferences (H.323, iCal) if there is a SIP way to do it.  
There wouldn't be any interoperability issues with that like there 
would if both CPCP and SIP can do it. Even a single device that had, 
say, both SIP and iCAL mechanisms would have no interoperability 
issues with devices that were, say, SIP-only.  On the other hand, 
if you standardize on CPCP to do it, then you would not expect to 
see any other standardized mechanism.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2003 5:07 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Yes. After the conference server creates the focus on the 
> scheduled time that was set using CPCP, the focus can use SIP 
> INVTE or whatever protocol it desires to invite participants 
> into the conference, or accpet participants to join a conference.
> 
> /Hisham
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Dec 2003 09:51:51 -0500

So, two fundamental differences:
1. You think CPCP has some separate namespace independent of a URI 
(of which a SIP uri is a good, but not exclusive example).  
I am opposed to that.  A conferenceID is a uri.  I can imagine a 
specific instance of a conference service that could have multiple 
IDs for the same conference, for example, an H.323 URI and a SIP URI 
that resolves to the same conference.  That's fine, and it's not subject 
to standardization.  However, I think that the ID you use with the 
focus is always the ID you use with CPCP for the same conference.

2. You think ad-hoc conferences don't have policy.  I am fundamentally 
opposed to that.  Ad-hoc conferences should have all of the 
functionality of a pre-established conference and I can't imagine any 
reason why we can't provide that.

We also have a nit, at least I think it's a nit, about Instantiation.
I'm not sure there is any real difference between a re-usable 
conference ID and an instantiated conference that has no participants.  
Since I define instantiated as allocated mixer resources, if I'm not 
using resources I don't have the conference instantiated.  
If you define instantiation differently, then you could.  
It would be good, I think, to have a common agreement on what 
instantiation means, because we use it in the documents, but I'm 
not sure we disagree on what can happen.  We both agree you can 
manipulate policy, and we both agree participants can come and go.  
I guess I would ask you if you have some notion of a re-usable 
conference ID that is somehow different from an instantiated 
conference with no participants.

Brian

> Sent: Tuesday, December 02, 2003 9:26 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > From: ext Rosen, Brian [mailto:[email-masked]]
> > Sent: 02.December.2003 15:16
> > To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]; 
> > 'Paul Kyzivat'
> > Cc: [email-masked]; Mayer Georg (NMP-MSW/Helsinki);
> > [email-masked]; [email-masked]
> Some chat type conferences can exist without any 
> participants. Participants come and go as they please. Why is 
> there a requirement that at least one participant is needed 
> for the conference to ever exist?
> 
> > 
> Agreed on the part, but I don't think you need the conferece 
> ID (that is the SIP URI for the conference) in order to 
> manipulate the policy. CPCP can provide its own conference 
> policy ID that is somehow mapped to a conference ID. This 
> depends on the protocol chosen for CPCP.
> 
> > 
> You are asking to redefine the whole concept of ah-hoc 
> conferencing using SIP. The INVITE creates a conference, and 
> creates a dialog.
> 
> > 	DialIn/DialOut 
> How can you limit the dail-in list in an ad-hoc conference. 
> Let me remind you that an ad-hoc conference does not have a policy.
> 
> For dial-out list, it is true that you can send REFER 
> requests for the focus, but again, you cannot predefine that 
> list. Also, you have to send a REFER to the focus for each 
> potential participant, creating x number of dialogs, one for 
> each REFER request.
> 
> 
> again, with ad-hoc conferences, there is no policy to dictate 
> this. I think I will stop commenting now until someone agrues 
> that I am wrong and an ah-hoc conference also needs a policy 
> (where my reply would be: why is it called ah-hoc then?).
> 
> Regards,
> Hisham
>

---

From: Heil Franca Marcelo <[email-masked]>
Date: Tue, 2 Dec 2003 16:03:23 +0100

Hisham,

please see my comments below.

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Dienstag, 2. Dezember 2003 15:26
> An: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> Betreff: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> 
> 
> 
I think that it is too strong to state that there is no policy for ad-hoc conferences. Surely there is no pre-configured policy for it, but when it is created a set of parameters regarding membership and media policy are (automatically) assigned to it. They may result from the ad-hoc conference setup procedure and from the default configuration of the conference server. In the course of the conference these parameters may be eventually accessed via a CPCP. 

Regards,
Marcelo

> > > > >>>> establishing a conference with its focus (either 
> through the
> > > > >>>> same dialog

---

From: [email-masked]
Date: Tue, 2 Dec 2003 17:26:35 +0200

> Sent: 02.December.2003 16:52
> [email-masked]

I don't understand why the ID for the conference needs to be the same as the ID for the conference policy. 

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.

> reason why we can't provide that.

If we replicate everything that a scheduled conference can have to ad-hoc conferences, then we don't need scheduled conferences at all. Perhaps we need to define the scope of an ad-hoc conference. To me an ad-hoc is just that; a conference created instantaneously for discussing an urgent matter or whatever. You REFER other participants and it terminated as soon as the last participant leaves. There are no start and stop times, there are no dial-out and dial-in lists configured, there is no general conference info, and there are no media policies.

> using resources I don't have the conference instantiated.  

I agree about the definition of "instantiated". But if there are no current participants in a conference, and a server releases resources and keeps the conference ID, it needs to guarantee what resources will be available as soon as a participant enters. This might be not releasing the resources. Perhaps all this is an implementation issue. 

> conference with no participants.

A conference ID can exist even if a conference is not instantiated. But what I was trying to say is that a conference can be instantiated without any participants, unless as I said, the resources can be guaranteed to be reallocated.

Regards,
Hisham

---

From: [email-masked]
Date: Tue, 2 Dec 2003 17:33:13 +0200

> From: ext Heil Franca Marcelo [mailto:[email-masked]]
> Sent: 02.December.2003 17:03
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> Subject: AW: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> > 
> I think that it is too strong to state that there is no 
> policy for ad-hoc conferences. Surely there is no 
> pre-configured policy for it, but when it is created a set of 
> parameters regarding membership and media policy are 
> (automatically) assigned to it. They may result from the 
> ad-hoc conference setup procedure and from the default 
> configuration of the conference server. In the course of the 
> conference these parameters may be eventually accessed via a CPCP. 

If you want this, then we go back to Brian's original point of why do we want 2 ways of achieving the same thing?

Instead of creating the conference policy then instantiating the conference, you want to instantiate the conference then create its policy.

We need one solution for quick conferences created on the fly, and ones that are more controlled and scheduled with policies, etc.

/Hisham

---

From: Alan Johnston <[email-masked]>
Date: Tue, 02 Dec 2003 09:51:50 -0600

>the ID for the conference policy.

I agree with Brian here.  The conference identifier is the URI.  It is the 
means by which a participant joins the conference and depends on the 
signaling protocol (SIP, H.323, PSTN, etc.).  It can't just be some random 
string.  This is a fundamental idea in the framework.

>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.

I don't understand what you are saying.  The policy URI and the conference 
URI can not be the same since they are different protocols, right?

>identify a conference policy.

Knowing only the conference URI, it must be possible to determine the 
conference policy URI.

>If we replicate everything that a scheduled conference can have to ad-hoc 
>conferences, then we don't need scheduled conferences at all. Perhaps we 
>need to define the scope of an ad-hoc conference. To me an ad-hoc is just 
>that; a conference created instantaneously for discussing an urgent matter 
>or whatever. You REFER other participants and it terminated as soon as the 
>last participant leaves. There are no start and stop times, there are no 
>dial-out and dial-in lists configured, there is no general conference 
>info, and there are no media policies.

I agree 100% with Brian.  An ad-hoc conference does have policy, but it is 
a default (non-unique) policy.  The creator of the conference factory URI 
sets that policy.  It is possible for this policy to be manipulated once 
the conference has begun, but again this is up to the application.

There is no such thing as an "ad-hoc conference" or a "scheduled 
conference" - however,there are "ad-hoc methods" of joining or being added 
to a conference, and scheduled means.

When joining a pre-established, the conference URI is typically sent 
out-of-band, often in advance, to participants using say email or IM.  When 
a participant is added using ad-hoc means, they often will not know (see) 
the conference URI - they will just be added in via a REFER or 
transfer.  Trying to come up with a strict definition for one vs. the other 
is very difficult and probably not all that productive.

I would encourage everyone to carefully read the SIPPING Conference 
Framework document - it details many of these issues.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

>I agree about the definition of "instantiated". But if there are no 
>current participants in a conference, and a server releases resources and 
>keeps the conference ID, it needs to guarantee what resources will be 
>available as soon as a participant enters. This might be not releasing the 
>resources. Perhaps all this is an implementation issue.
>
>A conference ID can exist even if a conference is not instantiated. But 
>what I was trying to say is that a conference can be instantiated without 
>any participants, unless as I said, the resources can be guaranteed to be 
>reallocated.
>
>Regards,
>Hisham
> >
> > Brian
> >
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 2 Dec 2003 11:27:41 -0500

Agree with one nit.

Every conference starts with a default policy.  You then use CPCP to
modify it.  The conference service defines the default policy.  It may
also enforce limits on what kinds of changes could be made to policy
with CPCP, but that is beyond the scope of our work.  The default policy
for an ad-hoc conference may or may not be different from the default
policy for a pre-scheduled conference; that's an implementation issue.

If you create a conference ID, connect to the conference policy server
and request it's current conference policy, you should get a coherent
answer.

> Sent: Tuesday, December 02, 2003 10:52 AM
> To: [email-masked]; [email-masked];
> Cc: [email-masked]; [email-masked]; [email-masked]
> >I don't understand why the ID for the conference needs to be 
> the same as 
> >the ID for the conference policy.
> 
> >Depending on the protocol we chose, a SIP URI can or cannot 
> be used to 
> >identify a conference policy.
>

---

From: Heil Franca Marcelo <[email-masked]>
Date: Tue, 2 Dec 2003 17:58:24 +0100

> Von: Rosen, Brian [mailto:[email-masked]] 
> Gesendet: Dienstag, 2. Dezember 2003 17:28
> An: 'Alan Johnston'; [email-masked]; 
I see one point here: pre-scheduled conferences may start with a policy which is different from the default one, as the policy could have been changed at conference creation (scheduling) time. (This is of course application dependent.)

> and request it's current conference policy, you should get a coherent
I think that the conference server is the entity that creates the conference ID (on request), not "me"...

Marcelo

---

From: Heil Franca Marcelo <[email-masked]>
Date: Wed, 3 Dec 2003 09:02:43 +0100

> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Dienstag, 2. Dezember 2003 20:22
> An: Rosen, Brian
> Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> 
> 
> 
> Rosen, Brian wrote:
> > Well, now you might see why I think the Conference Factory URI
> > does not instantiate a conference; it just returns a conference ID.
> > That way, you could, if you wanted to, change the default policy
> > before you "started" it.
> 
> It is my understanding that the Conference Factory URI is used by 
> sending an INVITE to it. So how is it supposed to return a 
> conference ID 
> without also "starting" the conference? Typically the result of the 
> INVITE will be a dialog with the focus, with the address of the focus 
> being returned as the Contact. Or are you assuming that Conference 
> Factory URI will *always* return a 3xx rather than 
> establishing the dialog?
> 
> I would hate to write an application for creating/configuring a 
> conference that sends and INVITE but depends on it not 
> succeeding - so 
> that if it is surprised by having the INVITE succeed it barfs.
> 
> I think sending an invite to a Conference Factory URI should only be 
> used when the UAC wants to participate in a new conference 
> that starts 
> *now*.
> 
> If you want to establish a name and policy for a conference to take 
> place later, then I think you must use other means.
> 
> 	Paul
> 

Exactly, and the other mean could be to use CPCP.

Marcelo

---

From: [email-masked]
Date: Wed, 3 Dec 2003 10:49:19 +0200

> From: ext Alan Johnston [mailto:[email-masked]]
> Sent: 02.December.2003 17:52
> Cc: Mayer Georg (NMP-MSW/Helsinki); [email-masked]; [email-masked]

> URI can not be the same since they are different protocols, right?

That is what I said. First you agree with Brian that a conference and conference policy need to be identified with the same ID, then you agree with me here that policy URI and conference URI can be different because of the differing protocols.

> Knowing only the conference URI, it must be possible to determine the 

So, you agree that they can be different?

Who needs to make such determination?

Quite often with pre-extablished conferences, the user learns the policy URI before the conference URI.

> sets that policy.  

No arguments here.

> It is possible for this policy to be 
> manipulated once 

Are you saying that the user needs to be able to manipulate the policy?

Regards,
Hisham

---

From: [email-masked]
Date: Wed, 3 Dec 2003 10:58:46 +0200

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 02.December.2003 18:15
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked];
> Mayer Georg (NMP-MSW/Helsinki); [email-masked]; [email-masked]
> [email-masked] wrote:
> > 
> > Some chat type conferences can exist without any participants.
>  > Participants come and go as they please. Why is there a requirement
>  > that at least one participant is needed for the conference 
> to ever exist?
> 
> I agree. Defining the conference by the allocation of mixer resources 
> seems wrong to me. That is very implementation specific - I 
> might choose 
> to allocate mixer resources differently than Brian does. In 
> case of chat 
> conferences where mixing is trivial, there may not be any explicitly 
> allocated mixing resources at all.
> 
> IMO a conference is defined by a valid address. So as long as the sip 
> address constituting the conference ID, which names a unique 
> focus, is 
> valid, it *is* a conference. The only real question is what 
> state that 
> conference is in. If the conference isn't scheduled to start 
> yet, then I 
> would hope that a request directed to it would yield some meaningful 
> error - perhaps 480 Temporarily Unavailable, giving the time until it 
> will be available. If a request is directed to it after 
> policy says it 
> should have expired, then a 404 Not Found error would be appropriate.
> 
> > You are asking to redefine the whole concept of ah-hoc conferencing
>  > using SIP. The INVITE creates a conference, and creates a dialog.
> ...
>  > again, with ad-hoc conferences, there is no policy to dictate this.
>  > I think I will stop commenting now until someone agrues that I am
>  > wrong and an ah-hoc conference also needs a policy (where my reply
>  > would be: why is it called ah-hoc then?).
> 
> I have to disagree with you and agree with Brian here.
> I don't think it makes sense to say a conference has no policy.
> It may be that you can neither query nor manipulate the policy, but 
> conceptually it still has a policy. Fancier conferencing 
> products would 
> hopefully provide the ability to query and manipulate policy 
> on ad hoc 
> conferences.
> 
> I think the only real difference is that if you create an ad hoc 
> conference by sending an invitation to a conference factory, 
> you get a 
> conference with some *default* policy determined by the 
> factory in its 
> infinite wisdom.

I completely agree here. I was arguing that for an ad-hoc conference, there is no need to manipulate that policy. If a user wants to have that much control, then they should use CPCP to create a conference, not using ah-hoc means.

/Hisham

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 3 Dec 2003 09:04:02 -0000

<<comment in-line>>

>Sent: 03 December 2003 08:59
>To: [email-masked]
this.
>I completely agree here. I was arguing that for an ad-hoc conference,
there
>is no need to manipulate that policy. If a user wants to have that much
>control, then they should use CPCP to create a conference, not using
ah-hoc
>means.

[Chris Boulton] Once a conference instance has started - should it
matter HOW the conference was started.  We have a conference instance,
we have CPCP, why restrict a user just because it was started in an
ad-hoc fashion.

Chris.

>_______________________________________________________________________
_
>This email has been scanned for all viruses by the MessageLabs Email
>Security System. For more information on a proactive email security
>service working around the clock, around the globe, visit
>http://www.messagelabs.com
>_______________________________________________________________________
_

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

---

From: [email-masked]
Date: Wed, 3 Dec 2003 11:05:27 +0200

> Sent: 02.December.2003 21:22
> To: Rosen, Brian
> Cc: 'Heil Franca Marcelo'; 'Alan Johnston'; Khartabil Hisham
> (NMP-MSW/Helsinki); [email-masked]; Mayer Georg (NMP-MSW/Helsinki);

Yes, this has been my point all along.

/Hisham

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 07:57:31 -0500

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

> 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]
> >>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.
> >>
> >>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
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 08:15:35 -0500

I'm arguing that there is no advantage for two mechanisms to start
conferences.
I prefer a SIP way, but I'll reluctantly except a CPCP way.

First, let's observe that the "creator" of the conference has to be
conference aware.  A non-conference aware participant can be given
a URI he don't understands is a conference URI, INVITE to it, and he's in.
Similarly, he can get a REFER to some URI and get in that way.  

So, one could define the mechanism to always be that you send an INVITE
to a conference Factory URI, which always returns a 3xx response with
a Contact containing the conference URI.  Given the conference URI you
could INVITE immediately (ad=hoc) or wait until some time later.  You
can use the conference URI to modify the policy of the conference before
or after the conference starts.  Everything works fine.

Similarly, you could always use CPCP to get a conference URI, INVITE
immediately or later, modify the policy now or later, etc.  Everything works
fine.

What is the difference in the result of these two mechanisms?
	Nothing

What is the advantage of one mechanism over another?
	A UA which only did ad-hoc has a trivial implementation if you use
	the conference factory URI as long as the default policy was
acceptable

	I don't see any other difference.  

	This small difference argues for the conference factory uri choice

Now, suppose, as has been proposed, the conference factory URI doesn't
work the way I think, rather it immediately instantiates the conference.
What is the difference?
	a) you save the second INVITE (2 messages per conference)
	b) you need another mechanism for a pre-established conference

I expect most implementations of conference aware UAs will support both 
ad-hoc and pre-established. One mechanism is preferred.  I don't think
you will see a UA implementation that does pre-established only.  That
argues for the conference factory uri choice.

The worst situation is that there are two equivalent mechanisms and there
are implementations that only do one.  That would create incompatible
implementations.

Brian

> Sent: Tuesday, December 02, 2003 2:22 PM
> To: Rosen, Brian
> [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 08:26:23 -0500

> I see it as you connect to conference policy server, create a 
> conference policy and a conference ID (or get a conference ID 
> assigned to you). There is no need for a default policy to 
> exist for non ad-hoc conferences.
> 
Sure there is.  There is no requirement, nor should there be, 
to specify every element of conference policy.  Yet, the 
implementation will enforce some value anyway.  It's highly likely 
that there will be configuration by local administration.   
That is default policy.

There is no requirement that you specify policy in one transaction.
I expect many, many implementations will not do so for various UI
reasons.  Before you complete the policy, there is default policy
for those parts you have not (yet) specified values.

---

From: [email-masked]
Date: Wed, 3 Dec 2003 16:44:09 +0200

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

> Sent: 03.December.2003 14:58
> To: 'Paul Kyzivat'
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]; Mayer Georg (NMP-MSW/Helsinki);

---

From: [email-masked]
Date: Wed, 3 Dec 2003 16:53:52 +0200

This is an unnecessary 2 step process. Get a conference ID, which creates a default policy for you, then modify the policy. Instead, I just want to upload a policy and in return get the conference ID. I can then manipulate the policy as see it.

If there are local administration limitations, then either the policy is rejected or manipulated by the administrator (the machine).

Again, my point was that I see it as you connect to conference policy server, create a conference policy and a conference ID (or get a conference ID  assigned to you)

/Hisham

> Sent: 03.December.2003 15:26
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];

---

From: Alan Johnston <[email-masked]>
Date: Wed, 03 Dec 2003 09:10:14 -0600

>or after the conference starts.  Everything works fine.

No, I'm afraid not.  Many proxies automatically recurse on 3xx 
responses.  As a result, even if we somehow say that a conference factory 
MUST redirect, the result would often be the establishment of a 
session.  Now what, the application has to send a BYE to disconnect since 
the conference is not until next week?  Will my conference server see a 
steady stream of 1 second, single participant conferences?  Yuk!

Also, I expect that many of the protocols developed here in XCON will be 
used to applications and automata.  These applications will not have a SIP 
UA.  Will we force them to have a SIP UA so they can send an INVITE which 
will always be followed by a BYE just to get a Conference URI?  Besides the 
CPCP security mechanisms, now this application will need SIP 
security/authentication/firewall/NAT traversal issues - again, yuk!

XCON protocols must stand on their own - having a way to create and get a 
Conference URI seems like a critical element.

>argues for the conference factory uri choice.

As I have argued above, many endpoints besides UAs will use our protocols 
to create conferences - requiring them to implement SIP and send an INVITE 
that doesn't establish a session is just a bad idea.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: Alan Johnston <[email-masked]>
Date: Wed, 03 Dec 2003 09:19:23 -0600

>                 to have a separate CPS with every focus, and replicate

These are all design issues for the service provider - building in 
assumptions like these in the protocol design is a bad idea.

>purpose of specifying which policy once we know where the server is.

So my media server must also be my conference policy server??  Once you 
learn the IP address of the mixer, you just start sending CPCP commands to 
that IP address?  Are you serious?

>be a URI that I'm missing?

Yes - flexibility, extensibility, generality, DNS, etc - the same reasons 
we use URIs in SIP and not just IP addresses.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: [email-masked]
Date: Wed, 3 Dec 2003 17:31:26 +0200

Focus host and focus are different things. I earlier assumed you meant focus and not focus host. I apologise.

I agree that the host of the policy server and the focus is one of the same (the conference server). NO arguments here.

More comments inline...

> Sent: 03.December.2003 17:10
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]
> Cc: [email-masked]; [email-masked]; Mayer Georg
> (NMP-MSW/Helsinki); [email-masked]; [email-masked]
> 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.

Yes, this is what I thought of also when I earlier agreed for ad-hoc conferences to have a default policy. The UA can then extract the userinfo part of the URI returned as the focus address and use that to manipulate the policy. The host of the policy server and the focus needs to create such policy and therefore needs to either assign conference URIs or learn then to enable it to create the policy.

so:

INVITE-->
200<-- with contact: sip:[email-masked]

CPCP (assuming xcap) can be:

GET http://example.com/conference/hisham/conf123

should work.

/Hisham

---

From: Alan Johnston <[email-masked]>
Date: Wed, 03 Dec 2003 10:01:12 -0600

At 05:31 PM 12/3/2003 +0200, [email-masked] wrote:
>I agree that the host of the policy server and the focus is one of the 
>same (the conference server). NO arguments here.
>
>More comments inline...
>
>Yes, this is what I thought of also when I earlier agreed for ad-hoc 
>conferences to have a default policy. The UA can then extract the userinfo 
>part of the URI returned as the focus address and use that to manipulate 
>the policy.

We must stop talking about "ad-hoc conferences" and "scheduled conferences" 
- there is no such thing.  There are only ad-hoc mechanisms and scheduled 
mechanisms to create/join a conference.

I don't think there has ever been consensus on a requirement that the 
policy URI be guessable from the Conference URI.

>  The host of the policy server and the focus needs to create such policy 
> and therefore needs to either assign conference URIs or learn then to 
> enable it to create the policy.
>
>so:
>
>INVITE-->

So, if The Example Company already has their public web server home page at 
example.com where everyone goes to download the latest examples, this web 
server now needs to become the conference policy server?

There are significant disadvantages in limiting ourselves to such 
conventions - especially when there are other ways of discovering the 
policy URI.  One way that has been discussed is advertising the policy URI 
in conference package notifications.  Is this not sufficient?  This 
approach is flexible and extensible (different protocols for policy 
manipulation can be defined with a new URI scheme) and has none of the name 
space limitations of this proposal.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 3 Dec 2003 16:21:07 -0000

>Sent: 03 December 2003 16:01
[email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]

[Chris Boulton] I totally agree.  Whether 'ad-hoc' or 'scheduled' means
are used to create a conference should have no effect - a conference
should be created and a default policy applied.  Then, if it is an
'ad-hoc' conference, a participant is free to join and if it is a
scheduled, the creator may manipulate the conference policy.  

>space limitations of this proposal.

[Chris Boulton] This approach does seem to 'shoe-horn' the HTTP usage
and IMHO is quite an ugly solution.  As Alan points out, policy URI
contained in conference packages is a far more elegant solution.

_
_

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 13:46:02 -0500

> >mechanisms to create/join a conference.
Which, I think, is completely useless.
And, to be specific:
	There is no difference in how you join a conference
		You always send an INVITE, or get a REFER,
			or receive an INVITE.  You can't join with
			CPCP.
	There is no reason to have a difference to create one
 
> scheduled, the creator may manipulate the conference policy. 
Why is it different with ad-hoc that a participant is free to join?
Why is it different with scheduled that the creator may manipulate 
the conference policy?

I think there is no difference at all.  No matter how you create it,
participants are free to join any time the policy says they pay.
No matter how you create it, the creator may manipulate the conference
policy (and participants may manipulate it also, subject to permissions).

> >server now needs to become the conference policy server?
No, unless the example.com is also the focus host.  If it is, then the
web server is there too. That is just not a limitation worth worrying
about.

> >policy URI.  One way that has been discussed is advertising 
> the policy
> URI
> >manipulation can be defined with a new URI scheme) and has 
> none of the
> name
My problem is that we seem to be heading to a solution where there
is no subset of capabilities.  To do anything, you need to implement:
	cc conference
AND
	cpcp
AND
	mpcp
AND
	the conference package

There are no simple implementations other than conference unaware.
Is that really what we want to do?  Intertwine all the pieces so that
there is no clean functional separation that allows implementation
flexibility without creating incompatibility?  In this specific
case, why do you have to implement the conference package in order
to discover the conference policy uri?

A message or two ago, Alan talked about automata manipulating conference
policy, and you were aghast that I proposed using SIP means to
create a conference ID.  You now want the automata to use SIP means
to find a conference policy URI given a conference URI; they even have
to join the conference to do so, unless the automata created the
conference in the first place, where it may get the conference policy
uri returned to it).

Can't we give up a slight amount of flexibility to get the possibility
of more widespread use of this facility by limiting implementation
complexity?  Maybe we need some use case stuff to see how subsets might
be useful.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 14:17:02 -0500

I delayed sending an answer to this to get another reply out.
I dealt with a couple of issues here already.

I don't want to beat a dead horse on the conference factory URI.
If proxies are automatically forwarding calls when they shouldn't
be (3261 says that the CLIENT should retry), we can't use that.
We could, of course, define a new 3xx response for this purpose.
I don't want to establish a dialog, for sure.

If it doesn't work, it doesn't work, and I think we are better
off just making CPCP the only way to create a conference.
My only hesitation is the "subset" argument I just made.
A relatively dumb phone with a "Conference" button could
do what they do now with only SIP means if the conference factory
uri was implemented.  It could not manipulate policy, but it's
still a useful subset of functionality.  Having to implement
CPCP just to create the conference is doing what I don't want to do.

If we do allow both, then we need to require that a conference
service must implement both if it implements any SIP functionality.
I can just see some conference server implementer deciding that since 
he isn't going to implement any policy mechanisms he will only 
implement the SIP conference factory mechanism, and then hit a phone 
that decided it was always going to use CPCP to create every 
conference.

Brian

> Sent: Wednesday, December 03, 2003 10:10 AM
> To: Rosen, Brian; 'Paul Kyzivat'
> Cc: 'Heil Franca Marcelo'; [email-masked]; 
> [email-masked];

---

From: Alan Johnston <[email-masked]>
Date: Wed, 03 Dec 2003 13:22:59 -0600

(trimmed cc list since we're all on the XCON list)

>         There is no reason to have a difference to create one

The reason is exactly the point you make below - to have a subset of 
capabilities.  Many UAs can just support cc-conferencing, and have the 
ability to create a conference, invite participants, eject participants, etc.

If they want to be able to know who is on the conference, they need to 
support the conference package.

If they want to be able to manipulate the policy, they need to support 
CPCP.  Note that CPCP *does not* contain information about the state of the 
conference - that's what the conference package is for.  A participant can 
not use CPCP to add participants, eject participants, etc if it doesn't 
know the state of the conference (ie who is in the conference).  This 
separation of state and policy is a critical one - if you disagree then 
we'd better discuss it now.

>web server is there too. That is just not a limitation worth worrying

Look at Hisham's example - they are the same.  One can get around it by 
having an application server that does 3pcc, or some sort of HTTP proxy, 
but why require all this complexity?  Why must my media server be my policy 
server as well?

As another example, I have the domain sipstation.com which I use for my own 
SIP network with a proxy at my house.  However, my web page is hosted by a 
provider.  If I setup a conference service, would I be forced to host my 
own web server just so I can assign Conference URIs with the domain 
sipstation.com?  Or do I have to get my web hosting company to run my 
policy server?

This is a serious, serious URI naming limitation.

>conference in the first place, where it may get the conference policy

No.  If CPCP allows a conference to be created, there must be a URI for it 
(similar to the Conference Factory URI) which must be provisioned.  The 
automata would use this URI to create the conference, receive the 
Conference URI.  Now, the automata's interest in the conference is over - 
it has created it and set it up.  It can send out notifications, etc. do 
whatever it wants.

However, if the automata wants to use CPCP during the conference do do 
real-time things, then it needs to know the current state of the conference 
- the policy does not have this information in it.  As a result, it should 
subscribe to the conference package.

>complexity?  Maybe we need some use case stuff to see how subsets might

I understand your concern about having two ways to do certain 
things.  However, there will be two users of CPCP - actual conference 
participants, and applications that never ever will be 
participants.  Forcing only one way will seriously affect one of these two 
users - I'm not prepared to do this.

Thanks,
Alan Johnston
MCI
sip:[email-masked]

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 3 Dec 2003 11:36:16 -0800

***I vote for this conclusion*** 

with a slight rewording:
An XCON-compliant conference server MUST implement conference creation
using XCON.
(We, XCON, can not prescribe general conferencing behavior for every
possible server.)

Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Wednesday, December 03, 2003 11:17 AM
To: 'Alan Johnston'; 'Paul Kyzivat'
Cc: 'Heil Franca Marcelo'; [email-masked]; [email-masked];
[email-masked]; Orit Levin; [email-masked]
Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference

-- skip

If we do allow both, then we need to require that a conference service
must implement both if it implements any SIP functionality.
I can just see some conference server implementer deciding that since he
isn't going to implement any policy mechanisms he will only implement
the SIP conference factory mechanism, and then hit a phone that decided
it was always going to use CPCP to create every conference.

Brian

> >conference aware.  A non-conference aware participant can be given a 
> >URI he don't understands is a conference URI, INVITE to
> it, and he's in.

> responses.  As a result, even if we somehow say that a conference 
> factory MUST redirect, the result would often be the establishment of 
> a session.  Now what, the application has to send a BYE to disconnect 
> since the conference is not until next week?  Will my conference 
> server see a steady stream of 1 second, single participant 
> conferences?  Yuk!
> 
> Also, I expect that many of the protocols developed here in XCON will 
> be used to applications and automata.  These applications will not 
> have a SIP UA.  Will we force them to have a SIP UA so they can send 
> an INVITE which will always be followed by a BYE just to get a 
> Conference URI?  Besides the CPCP security mechanisms, now this 
> application will need SIP security/authentication/firewall/NAT 
> traversal issues - again, yuk!
> 
> XCON protocols must stand on their own - having a way to create and 
> get a Conference URI seems like a critical element.
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 14:46:01 -0500

Orit

This is just what I want to avoid.  With this definition, you could
create a conference service that did not support a conference factory
URI, and yet was otherwise SIP-compliant.  That means a phone could 
implement the conference factory uri, and wouldn't be compatible
with your service.  I explicitly said

Brian

> Sent: Wednesday, December 03, 2003 2:36 PM
> To: Rosen, Brian; Alan Johnston; Paul Kyzivat
> Cc: Heil Franca Marcelo; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 3 Dec 2003 15:21:39 -0500

> but why require all this complexity?  Why must my media 
We're assuming XCAP, right?  So a "web server" is not just a web
server, it's an XCAP server.  If it is the CPCP server; you can't
separate the http part from the xcap part from the cpcp part; they
are the same thing.

If your media server is your conference server (focus), then it's
not much of a stretch at all to force it to be your conference
policy server, at least now.  Now, that doesn't mean that you can't,
for example, use the media server as a mixer, and have the focus
be part of some proxy server, controlling the mixer with, say,
Megaco.  It seems pretty impractical to separate the conference
policy server from the focus, because they are so intertwined.

> sipstation.com?  Or do I have to get my web hosting company to run my 
I see the point.  It would be pretty simple to have your conference
server be conference.sipstation.com, regardless of which machine it
ran on, right?  That would solve the problem, would it not?  It doesn't
change the address of your end stations, or your proxy server.  It 
does limit (very slightly) the form of the uri for a conference
you can use.  It's a tradeoff.

> This is a serious, serious URI naming limitation.
Doesn't seem very serious.

> it has created it and set it up.  It can send out 
You just made a leap - the only thing an automata does with cpcp is create
a conference.  That is not true; it can do many other things before
the conference starts.  

> subscribe to the conference package.
The word "policy" is a real joke; claiming that removing a participant
by manipulating the policy so that he is not welcome, and having
the focus send him a BYE as a consequence lets you say "policy",
but there is a wink in your eye fella.  It's control and policy.
Separating state from control is always pretty iffy.  Hard to
name a successful protocol that separates state from control of 
state.  You can have one without the other, but it's pretty unusual.

If we separated those parts of "policy" that really were not state
dependent - those that made sense before the conference was instantiated
then maybe separating state from policy would make some sense.

---

From: [email-masked]
Date: Wed, 3 Dec 2003 17:17:16 +0200

I have to admit I am beginning to warm up to Brain's ideas about choosing one way to create a conference, but not fully. I can agree that one protocol is used to create a conference, SIP.

I don't like the idea of using INVITE/3xx/INVITE/200 to create a conference. There needs to be a mechanism to create a conference immediately (ad hoc), one round trip. This is very important. I think INVITE should create that type of conference. I agree now that a policy can be created for this ad-hoc conference that in manipulatable using CPCP.

We can define a new SIP method to schedule a conference. Something like SCHEDULE. Also, this mechanism does not allow the user to suggest a conference ID, so we can create a conf-ID URI parameter that can be place in the request URI:

SCHEDULE sip:[email-masked];conf-ID=[email-masked]
To:
From:
...

This also creates that manipulatable default policy using CPCP.

Regards,
Hisham

> Sent: 03.December.2003 15:16
> To: 'Paul Kyzivat'

---

From: "Orit Levin" <[email-masked]>
Date: Wed, 3 Dec 2003 13:44:29 -0800

I agree with the other half as well. I am not sure you can enforce it
through XCON, though. (I am not opposing to it - if we can.)
I am a big fan of cc-conferencing (obviously!) - I think it MUST be
followed by any SIP conferencing implementation including the indication
of the isfocus parameter with the conference URI in the Contact header.

Orit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Wednesday, December 03, 2003 11:46 AM
To: Orit Levin; Alan Johnston; Paul Kyzivat
Cc: Heil Franca Marcelo; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference

Orit

This is just what I want to avoid.  With this definition, you could
create a conference service that did not support a conference factory
URI, and yet was otherwise SIP-compliant.  That means a phone could
implement the conference factory uri, and wouldn't be compatible with
your service.  I explicitly said

Brian

---

From: Nermeen Ismail <[email-masked]>
Date: Wed, 03 Dec 2003 19:56:16 -0800

I have just seen this thread so I might be repeating what is laredy been said.

I agree that from the protocols point of view a conference is a conference. 
It does not matter if it is ad hoc or scheduled. It has a unique URI, its 
policy can be manipulated and authorized users can join/leave them either 
by dial-in or dial-out.

My understanding for why there are two ways to create a conference is to 
support :
1- Creating a conference and joining it without having to implement 
anything other than SIP (cc-conferencing). In this case sending an
INVITE to the URI factory is sufficient. Off course if the endpoint needs 
to do something more like modifying the conference policy then
it needs to also implement CPCP/MPCP in which case it might have just used 
that to create the conference. However the point is still that an 
application can create, join a conference and get the roster without 
needing anything other than a SIP stack.

2- Creating a conference and never joining it. This is like the case of a 
scheduling automata that at the time of conference scheduling it creates a
conference and a focus. In this case and as the application will never send 
or receive media to the conference it was deemed inappropriate to demand 
the application to have a SIP stack and send a no-media INVITE to create 
the conference. Hence some non-SIP method will be used to create the 
conference. A non-sip method will be used to create the conference (enters 
CPCP) and this create-conference will be sent to the top-level policy 
server URI which in return will send the conference URI and the policy 
server URI for that conference. The only benefot that this method has
over number 1 is that the application does not have to support SIP.

So a conference server needs to have a SIP stack, CPCP/MPCP and the 
conference package but a client might only have a SIP stack, a CPCP/MPCP 
implementation or both.

On a separate topic, it was mentioned before that when a conference is 
created a future start time can be specified. I see lots of complications 
with that to do with time zones etc. Already the client that created the 
conference has to deal with that and I do not see any benefit in extending
that to the conference server as well. So I see benefits in specifying a 
conference duration but no benefit in specifying conference start time.
If the client creating the conference wishes the conference to start 
accepting users in 5 minutes time then it needs to delay sending the create 
conference 5 minutes.

nermeen

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 4 Dec 2003 09:03:23 -0000

>From: Nermeen Ismail [mailto:[email-masked]]
>Sent: 04 December 2003 03:56
>To: Rosen, Brian
>Cc: [email-masked]
>I have just seen this thread so I might be repeating what is laredy
been
>said.

[Chris Boulton] I'm not disagreeing with this point just thinking about
it a bit more.  I guess the main concern I have is related to the
scheduling of resources.  Are you saying that resources would not be
scheduled (not reserved) for this conference until the moment it starts.
So if I schedule a conference for a weeks time - then on the day of the
conference, one of my colleagues schedules + starts a conference 10
minutes before mine and uses up all of my companies port allocation -
that means it's tough for me????  (And the answer isn't to buy more
ports before anyone suggests it ;-)

>> > >So, if The Example Company already has their public web server
home
>> > page at
>> > >example.com where everyone goes to download the latest examples,
this
>> > web
_
_

---

From: [email-masked]
Date: Thu, 4 Dec 2003 11:53:34 +0200

I can't believe people still think time zones are a problem. There are many time zone standards that can be used. The only requirement is that the client and the server need to implement the same one. That is hardly a show stopper.

/Hisham

> Nermeen Ismail
> Sent: 04.December.2003 05:56
> To: Rosen, Brian
> Cc: [email-masked]
> > > >So, if The Example Company already has their public web 
> server home
> > > page at
> > > >example.com where everyone goes to download the latest 
> examples, this
> > > web

---

From: [email-masked]
Date: Thu, 4 Dec 2003 11:56:19 +0200

This is up to your conference server's intelligence. The server should have rejected the second conference creation request if it  has a first come first serve logic. Or it can prioritise according to some method (or you can buy more ports :) I don't think this is a show stopper either.

/Hisham

> Chris Boulton
> Sent: 04.December.2003 11:03
> To: Nermeen Ismail; Rosen, Brian
> Cc: [email-masked]
> >2- Creating a conference and never joining it. This is like 
> the case of
> a
> >conference and a focus. In this case and as the application 
> will never
> send
> >that to the conference server as well. So I see benefits in 
> specifying
> a
> >> > >conventions - especially when there are other ways of 
> discovering
> the

---

From: [email-masked]
Date: Thu, 4 Dec 2003 13:51:04 +0200

> [email-masked]
> Sent: 04.December.2003 13:43
> To: [email-masked]
> Cc: [email-masked]
> Inline.
> I don't like to couple these elements unnecessarily using any 
> type of URI naming conventions. An equally possible setup is 
> one where the policy server is in fact separate XCAP server, 
> and both the conference participant and the focus are XCAP clients.
> 
> In any case, aren't we talking about simply passing on some 
> information about the conference to its participants. So, 
> have the focus return in a 200 OK to an INVITE:
> 
> Call-Info: 
> <http://xcapsrv002.phantom.example.com/services/cpcp/userA/pol
> icy12345.xml>;purpose=xcap-cpcp
> 
> This lets the client know where to go and do XCAP CPCP if it 
> wants to manipulate the policy.

This would work for participants who don't want to subscribe to the conference event package. Carrying the policy ID in the event package is also beneficial in that users can manipulate the conference policy without having to actually join the conference. They learn the policy ID using SUB/NOT without having to send INVITE.

So I guess both methods are needed.

Regards,
Hisham

> Aki
> <snip />

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Dec 2003 09:26:42 -0500

Hurray, someone else on the hot seat.

I agree with Hisham, and others, that schedule in advance is
a clear requirement we must support (existing systems do it),
it's not hard, and the resource allocation is local policy at the
conference service.   The simplest way to get around time
zone issues is to simply have the schedule always be in GMT,
and leave it to the clients to deal with local conversion for display
purposes.

Conference system vendors have coped with the scheduling problem for
years, and have sensible, albeit not foolproof heuristics to make
scheduled conferences work pretty well.  The reality these days is
that calculating conference resources is already an inexact science,
and you don't really know if your DSP will run out of horsepower until
it does. Again, vendors often use heuristics and approximations to
give you a "port count".

Brian

> Sent: Thursday, December 04, 2003 4:54 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> I can't believe people still think time zones are a problem. 
> There are many time zone standards that can be used. The only 
> requirement is that the client and the server need to 
> implement the same one. That is hardly a show stopper.
> 
> /Hisham
> 
> > the case of a 
> > will never send 
> > specifying a 
> > discovering the

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Dec 2003 09:41:36 -0500

Although I've caved on the issue of using conference uri to generate
conference policy uri, this message seems to address the issue of one
or two mechanisms to create conferences.  I think that just because we
create SIP mechanisms to create conferences does not prohibit any other
signaling protocol (H.323 for example) from creating conferences,
which could then use CPCP for conference policy control.
They might already have mechanisms to create conferences.

Looking at it another way, why should CPCP create SIP (emphasis added)
uris?  Clearly, it should be independent of the signalling protocol.
To make this work, we would have to have a way to specify what kind
of uri we wanted to create if CPCP can create conferences.  And of
course you are entangling the protocols.  If CPCP can't create
conferences, it can treat the conference ID as opaque, which is what
separate protocols should do to elements from the "other" side.
Oooh, ooh, another problem occurs to me.  I'll start another thread.

Brian
-----Original Message-----
From: Avshalom Houri [mailto:[email-masked]]
Sent: Thursday, December 04, 2003 7:00 AM
To: [email-masked]
Subject: Re: [XCON] Chicken and Egg - Can CPCP create a conference

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
SubjectRe: [XCON] Chicken and Egg - Can CPCP create a conference

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

Rosen, Brian wrote:
> 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.
> 
> 
>>Sent: Wednesday, December 03, 2003 9:44 AM
>>Cc: [email-masked]; [email-masked]; [email-masked];
>>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.
>>
>>>                                  But I really, really doubt that works.
It 
>>>would be easier
>>>>egg I need the address of the egg - having the address of 
>>>
>>>the chicken 
>>>
>>>>A sip address is a URL in that it is sufficient for me to 
>>>
>>locate a 
>>
>>>>identify the policy. But that would require me to know the 
>>>
>>>address of 
>>>
>>>>the server a-priori.
>>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Dec 2003 09:31:03 -0500

I'm going to cave on this one.
I think it will cause problems, as it always does when you have two
identifiers in different name spaces that have to be kept in sync,
but I can see that there is little, if any support for this one.

Brian

> Sent: Wednesday, December 03, 2003 6:41 PM
> To: Rosen, Brian

---

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

Hopefully, the security section addresses this as a potential DoS attack 
avenue.

Mike

At 11:56 AM 12/4/2003 +0200, [email-masked] wrote:
>This is up to your conference server's intelligence. The server should 
>have rejected the second conference creation request if it  has a first 
>come first serve logic. Or it can prioritise according to some method (or 
>you can buy more ports :) I don't think this is a show stopper either.
>
>/Hisham
>

---

From: [email-masked]
Date: Fri, 5 Dec 2003 11:36:20 +0200

> This would work for participants who don't want to subscribe 
> to the conference event package. Carrying the policy ID in 
> the event package is also beneficial in that users can 
> manipulate the conference policy without having to actually 
> join the conference. They learn the policy ID using SUB/NOT 
> without having to send INVITE.
> 

Where should these solutions be documented? in cc conferencing document in sipping?

---

From: [email-masked]
Date: Wed, 10 Dec 2003 10:28:26 +0200

> conferencing document in sipping?

Perhaps, but I'm not the editor of that document so maybe we should take this to the SIPPING mailing list? I would imagine that this might involve defining a new Call-Info purpose token of "cpcp" or similar. Otherwise it's really a walk in the park :) 

Cheers,
Aki