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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Dec 2003 17:06:35 -0500

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.

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.

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.

	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.

  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

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: Monday, December 01, 2003 4:12 PM
> To: Rosen, Brian; 'Orit Levin'; [email-masked]
> Subject: RE: [XCON] Chicken and Egg - Can CPCP create a conference
> 
> 
> At 03:36 PM 12/1/2003 -0500, Rosen, Brian wrote:
> >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,
> 
> 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]
> 
> 
> 
> 
> >Brian
> >
> >
> >
> >
> > > -----Original Message-----
> > > 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!
> > > 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
> > >
> > > 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
> > >
> > >
> > >
> > > _______________________________________________
> > > XCON mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > >
> >
> >_______________________________________________
> >XCON mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/xcon
> 

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

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 1 Dec 2003 14:57:54 -0800

> a conference before someone dials in or the focus dials out.

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