Subject: RE: [XCON] CPCP requirements to support IMS

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Dec 2003 10:43:39 -0500

> 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.)
There might be more than one conference factory uri, but I think
that is because there might be more than one conference service
available to you.  The example you give is not correct,
as you would use CPCP to control the number of allowed participants.

> 
> 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.
No, this is not my understanding.

You don't get a conference by calling the conference factory uri,
you only get a Contact with the conference uri.  Nothing happens
until you call the conference uri.  You could gave some
resources reserved prior to actually starting the conference,
but that comes as a result of using CPCP on the conference URI
that you get from the conference factory.  When you call the
conference URI, the conference "starts" (although conferencing
with one user is not a conference, right?  And you may only get
music on hold until the "organizer" arrives).

So, they are not at all the same.
> 
> 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. 
No, I don't thing CPCP will give you the conference URI.  You need
the conference URI in order to use CPCP.  You get the conference
URI from the conference factory, from a REFER, from an INVITE (in
the case of a dial out conference) or possibly some out-of-band
mechanism.

In the latter cases, it will usually be the case that one participant
(the conference organizer) obtains the conference uri from the
conference factory uri.  Thereafter, she will arrange to give
other participants the conference uri she gets from the conference
factory via REFER, or manipulating CPCP to cause an INVITE, or
by email :).  You might also generate a conference URI from a 
web page (as opposed to the conference factory uri), or your calendar
program, but those are out of scope of our work.

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

---

From: Heil Franca Marcelo <[email-masked]>
Date: Mon, 1 Dec 2003 18:20:20 +0100

Brian, Georg,

Please see my comments inline.

Marcelo 
> So, they are not at all the same.

I see no reason why a conference cannot be created by a conference server when a request (INVITE) addressed to the conference-factory-URI is received (on an ad-hoc basis). The conference-URI generated for the conference is returned in the 200 OK response, and, at this time, the conference already started and the requesting UA is already taking part on it.

> the case of a dial out conference) or possibly some out-of-band

If you use CPCP to create a conference, you will get the conference URI back upon successful creation.

---

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

Of course, there is no right or wrong here, but I would prefer that
the conference factory URI never actually create a conference.
Among other things, a single conference factory URI may "front" a number
of entities that provide the focus function, and the conference
factory would create a conference uri on the appropriate entity in order
to do things like load balance.  

I also appear to be mistaked in that CPCP can be used to create a
conference.  We might want to revisit this, as in general, it's not
a good idea to have two ways to do the same thing.  I'm going to start
a new thread on this one.

Brian

> -----Original Message-----
> From: Heil Franca Marcelo [mailto:[email-masked]]
> Sent: Monday, December 01, 2003 12:20 PM
> To: 'Rosen, Brian'; [email-masked]'
> Cc: [email-masked]
> Subject: AW: [XCON] CPCP requirements to support IMS
> 
> 
> Brian, Georg,
> 
> I see no reason why a conference cannot be created by a 
> conference server when a request (INVITE) addressed to the 
> conference-factory-URI is received (on an ad-hoc basis). The 
> conference-URI generated for the conference is returned in 
> the 200 OK response, and, at this time, the conference 
> already started and the requesting UA is already taking part on it.
> 
> 
> > > 
> If you use CPCP to create a conference, you will get the 
> conference URI back upon successful creation.  
>

---

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

Brian,

The way a conference factory URI is defined to be used is to create an ad-hoc conference when sending an INVITE.

With CPCP, the conference is not ad-hoc, but is rather scheduled with predefined participants. No conference factory URI is used here. In this case, it is up to the conference server (or a parameter in CPCP) to start the conference on the scheduled time and wait for participants to join or to only start the conference when the first INVITE arrives.

They are not the same thing.

/Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Rosen, Brian
> Sent: 01.December.2003 20:12
> To: 'Heil Franca Marcelo'; Mayer Georg (NMP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: RE: [XCON] CPCP requirements to support IMS
> 
>

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 3 Dec 2003 22:53:43 -0500

Said differently, SIP just works!

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thu, November 20, 2003 9:55 AM
> To: [email-masked]; [email-masked]
> > [email-masked]
> > Sent: 20.November.2003 11:51
> > To: [email-masked]
> > Subject: [XCON] CPCP requirements to support IMS
[snip]
> > - 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.
[snip]

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 3 Dec 2003 22:53:43 -0500

Can you give ANY justification for the statement that one protocol that does everything is better than focused protocols that get the job done?

I would offer, especially for devices of limited capability (like wireless), that a small set of focused protocols would result in less code and less memory usage than a kitchen sink protocol that does everything.  If "one protocol" is a goal, I would suggest H.323v99 :-)

> From: [email-masked] [mailto:[email-masked]]
> Sent: Mon, November 24, 2003 8:14 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Hello Keith et al,
> > 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.
> 
> 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.
[snip]

---

From: Marjou Xavier <[email-masked]>
Date: Thu, 4 Dec 2003 17:13:23 +0100

> You send an INVITE to the conference factory uri, 
> and it returns a Contact which is a conference uri.

Although I understand the need for this for an ad-hoc conference, is it really inline with SIP to return a specialized Contact header in a response to an INVITE message?

In my opinion, returning a specialized Contact header is only possible during the REGISTER step. (However, I agree I did not find this explicitly written in 3261) 

Xavier

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 4 Dec 2003 11:22:34 -0500

Look at how 3XX responses are handled in RFC3261
The Contact header has the URI for the client to use.

Brian

> From: Marjou Xavier [mailto:[email-masked]]
> Sent: Thursday, December 04, 2003 11:13 AM
> To: [email-masked]
> Although I understand the need for this for an ad-hoc 
> conference, is it really inline with SIP to return a 
> specialized Contact header in a response to an INVITE message?
> 
> In my opinion, returning a specialized Contact header is only 
> possible during the REGISTER step. (However, I agree I did 
> not find this explicitly written in 3261) 
> 
> Xavier
> 
> 
> 
> 
>

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 5 Dec 2003 08:37:31 -0000

Agreed - that is the whole point of contact.  You initiate a request
with a generalized location and get pointed to a specific location for
subsequent requests.  This fits perfectly.

Chris.

>From: Rosen, Brian [mailto:[email-masked]]
>Sent: 04 December 2003 16:23
>To: 'Marjou Xavier'; [email-masked]
>_______________________________________________________________________
_
>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: Adam Roach <[email-masked]>
Date: Thu, 11 Dec 2003 15:39:34 -0600

[as chair]

[email-masked] [mailto:[email-masked]] wrote:

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

Media policy was pushed to July precisely because it is more complex
and (at this point, at least) more contentious.

I fear that diverting resources to getting a bare-bones media policy
out the door early will only cause significant delays to not just
advanced media policy, but to all of our deliverables. That seems
a steep price to pay for a two-month advance on publication.

Hopefully, by the time the membership manipulation document is ready
for publication, the media policy draft will be stable enough to give
you a basis to start implementation.

What is important to keep in mind is that we are not performing these
tasks serially. The documents should develop pretty much in parallel.

/a

---

From: [email-masked]
Date: Fri, 12 Dec 2003 16:31:38 +0200

The issue I have is that we at least need to know the media to be used in the conference (audio, video, text), to enable the server to reserve resources and to enable the focus to include/exclude certain media from the INVITEs SDP it sends out to the dial-out list, and also enables the focus to reject the media streams in the SDP of INVITE request coming from dial-in participants.

I don't think in the basic media policy needs to define what the codecs to be used are, this can be a normal offer answer exchange between the client and the server.

This is a basic requirement and enables CPCP to work without the complicated media policy. If the people working on the media policy could work on a basic one like this, it would be great. We can then work on an advanced media policy as a second step.

Regards,
Hisham

> Adam Roach
> Sent: 11.December.2003 23:40
> To: Koskelainen Petri (NRC/Tampere); [email-masked]
> [email-masked] 
> [mailto:[email-masked]] wrote:
>

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 12 Dec 2003 15:31:08 -0500

Why do we need an explicit policy at all?

Wouldn't the bridge, by its nature, accept or reject the different media types?

> Sent: Fri, December 12, 2003 9:32 AM
> To: [email-masked]; [email-masked]; [email-masked]
> The issue I have is that we at least need to know the media 
> to be used in the conference (audio, video, text), to enable 
> the server to reserve resources and to enable the focus to 
> include/exclude certain media from the INVITEs SDP it sends 
> out to the dial-out list, and also enables the focus to 
> reject the media streams in the SDP of INVITE request coming 
> from dial-in participants.
> 
> I don't think in the basic media policy needs to define what 
> the codecs to be used are, this can be a normal offer answer 
> exchange between the client and the server.
> 
> This is a basic requirement and enables CPCP to work without 
> the complicated media policy. If the people working on the 
> media policy could work on a basic one like this, it would be 
> great. We can then work on an advanced media policy as a second step.
> 
> Regards,
> Hisham
>

---

From: [email-masked]
Date: Mon, 15 Dec 2003 09:54:52 +0200

Are you suggesting that that creator of a conference has no say in what media the conference will offer?

/Hisham

> Eric Burger
> Sent: 12.December.2003 22:31
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked]

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 15 Dec 2003 12:05:46 -0500

I suppose if the policy is "this conference can accept [one or more of {audio, video, text, application}]", then that works.

Note that does not prevent a "(audio, video)" conference from accepting a "(audio)"-only participant.  Or does it?  I would vote "no."

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]]
Sent:	Mon 12/15/2003 2:54 AM
To:	Eric Burger; [email-masked]
Cc:	
Subject:	RE: [XCON] CPCP requirements to support IMS

/Hisham