Subject: [XCON] CPCP requirements to support IMS

From: [email-masked]
Date: Thu, 20 Nov 2003 11:51:04 +0200

Hello,

as the CPCP issue is one very crucial for 3GPP, I would like to summarize some requirements from the IMS side. Please be aware that these are not official 3G requirements, but are my personal summary. I am the rapporteur of the technical specifications for IMS Conferencing protocol (stage 3) and collected some of the issues raised during the last meetings.

The time frame for finishing IMS conferencing in 3GPP are quite tight again. SIP related stuff for Conferencing is mostly done in the IMS spec, but for CPCP there is a complete lack and we are desperately looking for progress. The below issues should be decided on until latest mid of February, so that we have a chance to go on with conferencing in IMS.

Here we go:

- creation of a conference URI as well as of a conference-factory URI

Well that's so basic - I do not want to go through all the requirements which are already there 

- indication that user is automatically unsubscribed from conference event subscription when user is leaving

This saves a lot of bandwidht on the air interface, as the user will just receive a NOTIFY with a Subscription-State header set to "terminated" that additionally indicates that it has left the conference (two SIP messages) instead of receiving the notification about his/her own leaving, sending a un-SUBSCRIBE, receiving another NOTIFY (6 messages). 

- Dial-Out lists which state that the focus should either send INVITE or REFER to the invited user. 

Both options (INVITE and REFER) are needed in order to allow different charging models. 

It is not feasable that e.g. the moderator sends the REFER requests to the invited users, as this will put high load to the air interface (REFER + 2 NOTIFYs = 6 messages per REFERED-to user)

- CPCP solution must be based on XCAP

The interface for Data Manipulation in 3GPP IMS is the Ut interface. Over that the following issues will be handled:
	- Presence related data manipulation
	- CPCP 
	- Floor Control
	- generic data manipulation

In order to have one common interface, that could also be handled by the UE (and the related service applications in the network) in a common way, it is highly required that all these issues are solved by one protocol. 

This would also gurantee common security, charging, etc. models for the Ut interface.

Please ask if you need information on the IMS related issues. 

Thanks and best regards
Georg

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

---

From: [email-masked]
Date: Thu, 20 Nov 2003 16:55:04 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 20.November.2003 11:51
> To: [email-masked]
> Subject: [XCON] CPCP requirements to support IMS
> 
> 
> Hello,
> 
> as the CPCP issue is one very crucial for 3GPP, I would like 
> to summarize some requirements from the IMS side. Please be 
> aware that these are not official 3G requirements, but are my 
> personal summary. I am the rapporteur of the technical 
> specifications for IMS Conferencing protocol (stage 3) and 
> collected some of the issues raised during the last meetings.
> 
> The time frame for finishing IMS conferencing in 3GPP are 
> quite tight again. SIP related stuff for Conferencing is 
> mostly done in the IMS spec, but for CPCP there is a complete 
> lack and we are desperately looking for progress. The below 
> issues should be decided on until latest mid of February, so 
> that we have a chance to go on with conferencing in IMS.
> 
> Here we go:
> 

That's already convered in the requirements. In IMS, who will create this conference URI? is it a requirement that the client must create it? the server must create it? or both must be able to create it?

> 
> 
> - indication that user is automatically unsubscribed from 
> conference event subscription when user is leaving

You would like that to be conference instance specific using CPCP? or is this an implementation issue for conference server implementers? What I mean is that  do you see a use case for having to signal such thing in CPCP? or will the IMS just behave as you describe below every time? If it is the latter, then there is no need to standardise such thing.

> 
> This saves a lot of bandwidht on the air interface, as the 
> user will just receive a NOTIFY with a Subscription-State 
> header set to "terminated" that additionally indicates that 
> it has left the conference (two SIP messages) instead of 
> receiving the notification about his/her own leaving, sending 
> a un-SUBSCRIBE, receiving another NOTIFY (6 messages). 
> 
> 
> 
> - Dial-Out lists which state that the focus should either 
> send INVITE or REFER to the invited user. 

Yes, we have discussed this before. It was supposed to be in the requirements, but Petri must have missed it. Petri?

> It is not feasible that e.g. the moderator sends the REFER 
> requests to the invited users, as this will put high load to 
> the air interface (REFER + 2 NOTIFYs = 6 messages per REFERED-to user)
> 
> 
> 

This is a very strong requirement. We can leave that debate until we get a general consensus of the current requirements, but others can feel free to make their comments about this.

Thanks for the comments,
Hisham

> 
> The interface for Data Manipulation in 3GPP IMS is the Ut 
> interface. Over that the following issues will be handled:
> In order to have one common interface, that could also be 
> handled by the UE (and the related service applications in 
> the network) in a common way, it is highly required that all 
> these issues are solved by one protocol. 
>

---

From: [email-masked]
Date: Thu, 20 Nov 2003 16:59:15 +0200

> Leis Peter
> Sent: 20.November.2003 13:43
> To: [email-masked]
> Cc: Mayer Georg (NMP-MSW/Helsinki)
> Subject: AW: [XCON] CPCP requirements to support IMS
> 
> 
> hi Georg,
> 
> I think XCAP is not the right decission for floor control. 
> Floor control certainly has some real time requirements while 
> XCAP is a protocol for data administration. In addition the 
> decission to use XCAP (over Ut interface) for floor control 
> is not yet made within 3GPP. 

I agree, but I think floor control is different that floor control policy.

> 
> Another issue is compression. As far as I know there is no 
> procedure for compression of XCAP (at least up till now). But 
> for floor control which might happen quite frequently during 
> an active conference we need a protocol that can be compressed.

That's a HTTP issue. You can compress HTTP. I'm not sure if there already exists a HTTP dictionary. We might also need a dictionary for the XML document carried in HTTP (XCAP). But is this issue so important in the first phase of this work that a requirement is needed that state that the protocol must be compressible (if such work exists:)?

Regards,
Hisham

> 
> 
> Peter
> 
> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Donnerstag, 20. November 2003 10:51
> An: [email-masked]
> Betreff: [XCON] CPCP requirements to support IMS
> 
> 
> Hello,
> 
> It is not feasable that e.g. the moderator sends the REFER

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 20 Nov 2003 10:23:09 -0500

> requirements which are already there 
Creation of a conference factory URI?  Is configuration good enough, or
are you looking for a discovery protocol?

> a un-SUBSCRIBE, receiving another NOTIFY (6 messages).
This might be good idea, but you could unsubscribe and then leave,
saving two messages.
 
> the air interface (REFER + 2 NOTIFYs = 6 messages per REFERED-to user)
So, by REFER, without an existing dialog, you want to invite
someone to a conference, but force him to send his own INVITE because
then you charge him for an outgoing call, rather than an incoming call?
Really?

Brian

---

From: [email-masked]
Date: Thu, 20 Nov 2003 20:02:52 +0200

Hi,
 
> Yes, we have discussed this before. It was supposed to be in 
> the requirements, but Petri must have missed it. Petri?
>

This is covered already. I guess G5 should be changed to MUST.

   REQ-G1: It MUST be possible to define a dial-out list of users that
   the conference focus invites.

   REQ-G5: It SHOULD be possible to define list of users who the focus
   should refer to the conference (so that the referred users will dial
   in the conference).

--
Petri

---

From: "Orit Levin" <[email-masked]>
Date: Fri, 21 Nov 2003 08:18:13 -0800

I certainly agree that XCAP is not the way to go.
That is at least for the reason mentioned below,
 
Orit.

> I think XCAP is not the right decission for floor control. Floor control
 > certainly has some real time requirements while XCAP is a protocol
for data
 > administration.

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 21 Nov 2003 16:54:37 -0000

Which functionality is floor control policy.

As far as I understand the conferencing framework document, we have

-	conference control policy protocol, which in itself is divided into:
	-	membership policy
	-	media policy

and
-	floor control

I have not seen any mention of floor control policy. I believe requirements concerning creation and removal of floors are now considered to be CPCP, but I am not sure where they fall in the above divisions.

The floor control requirements already contain REQ-15	
"Bandwidth and terminal limitations SHOULD be taken into account in order to ensure that floor control can be efficiently used in mobile environments."

In order to meet the very immediate response needs of floor control, for 3GPP2 I would understand that floor control really needs to sit in their short data bursts, which has a limit of something like 50 octets. When I give the floor to someone, I certainly want them to be able to start speaking almost immediately. When I take the floor away from someone, I absolutely do not want them to continue for another 10 sentences (assuming they were speaking in sentences in the first place!!!!).

At this moment in time it is premature to make any decisions about protocol, but I would certainly believe that we retain the flexibility to choose a different protocol for each of the above, based on different underlying requirements. If we choose the same protocol for membership policy as for resource list management in presence, then it will be because the requirements are similar.

regards

Keith

> From: [email-masked] [mailto:[email-masked]]
> Sent: 20 November 2003 14:59
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [XCON] CPCP requirements to support IMS
> 
> 
> 
> 
> That's a HTTP issue. You can compress HTTP. I'm not sure if 
> there already exists a HTTP dictionary. We might also need a 
> dictionary for the XML document carried in HTTP (XCAP). But 
> is this issue so important in the first phase of this work 
> that a requirement is needed that state that the protocol 
> must be compressible (if such work exists:)?
> 
> Regards,
> Hisham
> 
> > 
> > 
> > Peter
> >

---

From: [email-masked]
Date: Mon, 24 Nov 2003 11:36:53 +0200

Hello,

I also agree that the protocol for floor control needs further investigation. Nevertheless my initial mail was about CPCP and using XCAP for that. Good to hear nothing against that proposal.

Regards
Georg

> Orit Levin
> Sent: 21 November, 2003 18:18
> To: Roland Hedberg; Leis Peter; [email-masked]
> Subject: RE: AW: [XCON] CPCP requirements to support IMS
> 
> 
> Floor control

---

From: [email-masked]
Date: Mon, 24 Nov 2003 11:49:10 +0200

I see the following for floor control policy, which is not floor control.

- Does the Conference have floor control or not
- Is the conference floor control moderator-driven by human or First come first serve by automata.
- How many users can have the floor at one time.
- If automata driven, how long is the maximum time a user can ask for floor.

There might be other floor control policy type requirements. This list is just from the top of my head.

Regards,
Hisham

> From: ext Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: 21.November.2003 18:55
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]
> I have not seen any mention of floor control policy. I 
> believe requirements concerning creation and removal of 
> floors are now considered to be CPCP, but I am not sure where 
> they fall in the above divisions.
> 
> "Bandwidth and terminal limitations SHOULD be taken into 
> account in order to ensure that floor control can be 
> efficiently used in mobile environments."
> 
> In order to meet the very immediate response needs of floor 
> control, for 3GPP2 I would understand that floor control 
> really needs to sit in their short data bursts, which has a 
> limit of something like 50 octets. When I give the floor to 
> someone, I certainly want them to be able to start speaking 
> almost immediately. When I take the floor away from someone, 
> I absolutely do not want them to continue for another 10 
> sentences (assuming they were speaking in sentences in the 
> first place!!!!).
> 
> At this moment in time it is premature to make any decisions 
> about protocol, but I would certainly believe that we retain 
> the flexibility to choose a different protocol for each of 
> the above, based on different underlying requirements. If we 
> choose the same protocol for membership policy as for 
> resource list management in presence, then it will be because 
> the requirements are similar.
> 
> regards
> 
> Keith
>

---

From: [email-masked]
Date: Mon, 24 Nov 2003 15:13:52 +0200

Hello Keith et al,

> the requirements are similar.

well, I would say that one of the requirements from a wireless SIP device (regardless whether it makes use of IMS or not) is for sure to have a small set of protocols that it needs to faciliate to be able to make use of SIP services.

Furthermore I would like to see common solutions for similar requirements and CPCP looks very similar to the presence related data manipulation to me. Now from the IMS perspective it would be very valuable to have only one protocol for such issues here. We also did not chose a different messaging or presence protocol in IMS, we used SIP for this - so I hope we can have the same for the so-called "data manipulation" issues.

Means: As long as there is not good other reasons (such as Peter pointed out e.g. for floor control), I see good arguments for applying XCAP for CPCP. I think I am not the only one who agrees on that.

Besides that I see that we really need to decide on a protocol for CPCP and cannot allow ourselves to wait longer. So this is in no way premature. 

I do not understand how you can say it is premature. Your argumentation in CN1 is, that IETF solutionw are not mature enough, so that 3G cannot officially (in a TS) state that something is taken from IETF. So let's go for IETF solutions and make them mature even in your eyes. 

Best regards
Georg

> Sent: 21 November, 2003 18:55

---

From: [email-masked]
Date: Mon, 24 Nov 2003 19:14:51 +0200

Hello,

just to clarify - I think Peters comment was on floor control, not on CPCP. So I think Rolands comment 

> Isn't you really putting forth that the amount of bytes moved 
> about by 
> CPCP should be kept lo ?

as floor control protocol realted, not CPCP related.

Best regards
Georg

> Roland Hedberg
> Sent: 21 November, 2003 11:21
> To: Leis Peter; [email-masked]
> Subject: Re: AW: [XCON] CPCP requirements to support IMS
> 
> 
> Leis Peter wrote:
> 
>  > administration. In addition the decission to use XCAP (over Ut 
> interface) for
>  > floor control is not yet made within 3GPP.
> > 
> procedure for 
>  > compression of XCAP (at least up till now). But for floor 
> control which
>  > might happen quite frequently during an active conference 
> we need a 
> protocol that can be compressed.
> 
> Isn't you really putting forth that the amount of bytes moved 
> about by 
> CPCP should be kept lo ?
> If the choice was a protocol like XCAP then compression might be 
> necessary but if another protocol was choosen then it might 
> not be an issue.
> 
> -- Roland
> 
>

---

From: [email-masked]
Date: Mon, 24 Nov 2003 19:22:30 +0200

Hello Brian et al,

thanks for the comments and sorry for the late response!

> are you looking for a discovery protocol?

There should be a possiblity that the user can request a URI, by which (when used in INVITE) a conference gets created. Thinking about it again, I would say it is not important whether it is a conference or a conference-factory URI.

> This might be good idea, but you could unsubscribe and then leave,

But if I unsubscribe (SUBS/200 NOT/200) and then leave, I still have four. Having just two (NOT(S-D:terminated)/200 ) would be better ;) - you know we are counting the bits ;)

But seriously: in 3G CN1 we discussed this issue and the implicit de-registration was a strong requirement from operator side.

> then you charge him for an outgoing call, rather than an 

*blush* yes. Hope that's ok. 
Anyhow I do not understand it as "forcing" somebody, but "offering the possiblity".

Best regards
Georg

> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: 20 November, 2003 17:23
> To: Mayer Georg (NMP-MSW/Helsinki); [email-masked]

---

From: [email-masked]
Date: Mon, 24 Nov 2003 19:28:49 +0200

Hello Hisham,

thanks for the comments, I try to answer them ...

> That's already convered in the requirements. In IMS, who will 
> create this conference URI? is it a requirement that the 
> client must create it? the server must create it? or both 
> must be able to create it?

There is no requirement that the user can say "I want the URI [email-masked]" - so I would suggest the focus is still in charge of giving the conf a URI-name. Nevertheless the client should be able to indicate, that the server should create a conference URI. Sorry for my wording.

> You would like that to be conference instance specific using 
> CPCP? or is this an implementation issue for conference 
> server implementers? 
> What I mean is that  do you see a use 
> case for having to signal such thing in CPCP? or will the IMS 
> just behave as you describe below every time? If it is the 
> latter, then there is no need to standardise such thing.

Well somehow it should be configurable by the user, I'd think. Especially if the default value is "gets automatically unsubscribed" and the user wants to stay subscribed, to be e.g. informed about the people in the conference. 

> This is a very strong requirement. We can leave that debate 
> until we get a general consensus of the current requirements, 
> but others can feel free to make their comments about this.

I think it would be good if we start this discussion early - if we can agree early, then it's good ;). As you might have seen in my mail to Keith (and the group) today, there are some requirements that clearly point in direction of XCAP.

Best regards
Georg

> From: Khartabil Hisham (NMP-MSW/Helsinki) 
> Sent: 20 November, 2003 16:55
> That's already convered in the requirements. In IMS, who will 
> create this conference URI? is it a requirement that the 
> client must create it? the server must create it? or both 
> must be able to create it?
> 
> > 
> > 
> You would like that to be conference instance specific using 
> CPCP? or is this an implementation issue for conference 
> server implementers? What I mean is that  do you see a use 
> case for having to signal such thing in CPCP? or will the IMS 
> just behave as you describe below every time? If it is the 
> latter, then there is no need to standardise such thing.
> 
> > 
> This is a very strong requirement. We can leave that debate 
> until we get a general consensus of the current requirements, 
> but others can feel free to make their comments about this.
> 
> Thanks for the comments,
> Hisham
> 
> >

---

From: [email-masked]
Date: Tue, 25 Nov 2003 09:43:49 +0200

> From: Mayer Georg (NMP-MSW/Helsinki) 
> Sent: 24.November.2003 19:29
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]'
> There is no requirement that the user can say "I want the URI 
> [email-masked]" - so I would suggest the focus is still in 
> charge of giving the conf a URI-name. Nevertheless the client 
> should be able to indicate, that the server should create a 
> conference URI. Sorry for my wording.
> 
> 
> Well somehow it should be configurable by the user, I'd 
> think. Especially if the default value is "gets automatically 
> unsubscribed" and the user wants to stay subscribed, to be 
> e.g. informed about the people in the conference. 

Most participants in a conference don't have control over the conference policy. It is the moderator's decision to set the conference policy to terminate/not terminate a participant's conference package subscription as soon as s/he leaves the conference. So, what I was asking is: is that what you want? or should it be the policy of the conference server as set by the administrator of the domain?

/Hisham

---

From: [email-masked]
Date: Tue, 25 Nov 2003 12:03:28 +0200

Hello Hisham,

> Most participants in a conference don't have control over the 
> conference policy. It is the moderator's decision to set the 
> conference policy to terminate/not terminate a participant's 
> conference package subscription as soon as s/he leaves the 
> conference. So, what I was asking is: is that what you want? 
> or should it be the policy of the conference server as set by 
> the administrator of the domain?

Of course there can be a default value set by the operator. And I agree that not each participant can set this individually, as she/he will not be allowed to use CPCP. Nevertheless there should be a CPCP option to change the default setting for every user individually. 

So in general: the moderator shall be able to set this value for every user. And in IMS we assume a default value (i.e. auto-un-subscribtion)

Cheers
Georg

> [email-masked]
> Sent: 25 November, 2003 09:44
> Most participants in a conference don't have control over the 
> conference policy. It is the moderator's decision to set the 
> conference policy to terminate/not terminate a participant's 
> conference package subscription as soon as s/he leaves the 
> conference. So, what I was asking is: is that what you want? 
> or should it be the policy of the conference server as set by 
> the administrator of the domain?
> 
> /Hisham
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 25 Nov 2003 11:34:52 -0000

While I agree it is fairly urgent to get a decision made on the protocol, you started this thread with a call for checking and possibly enhancing the requirements.

If we are not going to wait for the requirements to be complete before making a decision on the protocol, then there is not point in having a requirements phase.

I submit that we should only make a decision when we have some agreement that the requirements are reasonably stable. The only decision I saw stepping this direction at the last IETF meeting was that the requirements draft should become a WG item.

regards

Keith

> From: [email-masked] [mailto:[email-masked]]
> Sent: 24 November 2003 13:14
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> well, I would say that one of the requirements from a 
> wireless SIP device (regardless whether it makes use of IMS 
> or not) is for sure to have a small set of protocols that it 
> needs to faciliate to be able to make use of SIP services.
> 
> Furthermore I would like to see common solutions for similar 
> requirements and CPCP looks very similar to the presence 
> related data manipulation to me. Now from the IMS perspective 
> it would be very valuable to have only one protocol for such 
> issues here. We also did not chose a different messaging or 
> presence protocol in IMS, we used SIP for this - so I hope we 
> can have the same for the so-called "data manipulation" issues.
> 
> Means: As long as there is not good other reasons (such as 
> Peter pointed out e.g. for floor control), I see good 
> arguments for applying XCAP for CPCP. I think I am not the 
> only one who agrees on that.
> 
> Besides that I see that we really need to decide on a 
> protocol for CPCP and cannot allow ourselves to wait longer. 
> So this is in no way premature. 
> 
> I do not understand how you can say it is premature. Your 
> argumentation in CN1 is, that IETF solutionw are not mature 
> enough, so that 3G cannot officially (in a TS) state that 
> something is taken from IETF. So let's go for IETF solutions 
> and make them mature even in your eyes. 
> 
> Best regards
> Georg
>

---

From: [email-masked]
Date: Tue, 25 Nov 2003 13:48:44 +0200

Ok, so can we get some comments or the requirements as soon as possible from interested parties :)

Thanks,
Hisham

> Sent: 25.November.2003 13:35
> To: Mayer Georg (NMP-MSW/Helsinki); [email-masked]; Khartabil Hisham
> (NMP-MSW/Helsinki); [email-masked]; [email-masked]
> While I agree it is fairly urgent to get a decision made on 
> the protocol, you started this thread with a call for 
> checking and possibly enhancing the requirements.
> 
> If we are not going to wait for the requirements to be 
> complete before making a decision on the protocol, then there 
> is not point in having a requirements phase.
> 
> I submit that we should only make a decision when we have 
> some agreement that the requirements are reasonably stable. 
> The only decision I saw stepping this direction at the last 
> IETF meeting was that the requirements draft should become a WG item.
> 
> regards
> 
> Keith
>

---

From: [email-masked]
Date: Tue, 25 Nov 2003 13:56:46 +0200

I'm a bit worried about media policy-CPCP integration 
and WG schedule regarding it.

Currently the charter says the following:
May 04  Submit Membership Manipulation Protocol for publication as PS 
Jul 04  Submit Protocol for Media Topology Control for publication

What I would like to have by May 04 is CPCP with the ability to set up typical
real-life conference, e.g. with audio codec X and centralized mixer. 
(in most cases, this does not require overly complex topology definition,
instead something like in current SDP may be enough).

Current media policy seems to be extremely complex and the RFC goal 
is not until July.

Georg can probably comment on 3GPP schedules but in any case, should we 
adopt simple media definition in CPCP itself (or divide media 
policy into basic and advanced parts so basic media policy 
could be ready by May 04)?

--
Petri

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Nov 2003 07:52:24 -0500

Georg

I think one of us has some confusion on a conference URI vs a conference
factory URI.

A conference URI refers to a specific conference.  If you INVITE with
a conference URI, the focus will put you in the conference.  One conference,
one conference URI.  

A conference factory URI is one way to create a conference uri.  You send
an INVITE to the conference factory uri, and it returns a Contact which
is a conference uri.  There is normally only one conference factory URI
per conference service, although you could imagine some kind of 
specialization that would create a need for more than one.  I was imagining 
that the conference factory URI was provisioned, or provided to you via 
some out of band means, although I'd really like the default outgoing 
proxy (the one you normally discover by DHCP or multicast), to tell you 
what it is.

So the conference factory uri is what you use to create a conference uri,
and the conference uri is what you use to refer to a specific conference.

Brian

> Sent: Monday, November 24, 2003 12:23 PM
> To: [email-masked]; [email-masked]
> There should be a possiblity that the user can request a URI, 
> by which (when used in INVITE) a conference gets created. 
> Thinking about it again, I would say it is not important 
> whether it is a conference or a conference-factory URI.
> 
> But if I unsubscribe (SUBS/200 NOT/200) and then leave, I 
> still have four. Having just two (NOT(S-D:terminated)/200 ) 
> would be better ;) - you know we are counting the bits ;)
> 
> But seriously: in 3G CN1 we discussed this issue and the 
> implicit de-registration was a strong requirement from operator side.
> 
>

---

From: [email-masked]
Date: Thu, 27 Nov 2003 18:34:02 +0200

Hello Brian,

I think we have the same understanding. There are two more things I would like to add:

a) there may be different conferece factory URIs for different types of conferences (e.g. for some only a restricted number of participants might be allowed, etc.)

b) if no conference resources have been reserved up till now (i.e. if there is no participant in the conference) from the users point of view the result of sending an INVITE with a conference factory URI or a conference URI is identical. Of course in the case of the factory URI, the conference URI is first created, but afterwards the conference resources are reserved and the user becomes the first participant in it.

What I meant in my mails before was, that the user should get via CPCP aware of a URI that finally allows him to join the conference and automatically reserve the resources for it. 

As I said, I agree that this can be done by a normal conference URI.

Good morning / good night
Georg

> Sent: 25 November, 2003 14:52
> To: Mayer Georg (NMP-MSW/Helsinki)
> Cc: [email-masked]