RE: [SIPPING] question on draft-johnston-sipping-cc-conferencing -00.txt

["Even, Roni" <[e-mail]>]

Michael,
What I argue is that you assume that the URI is the conference ID like in
audio conferencing the password given to the IVR but I think that it may be
the ID of the conference server (like the phone number) and the conference
server will create a unique conference ID that can be communicated via
notify. So that is why I am saying that the a URI does not have to be
unique. The framework draft in section 4 recommends that the conference URI
will not be constructed or guessed by a user and I think it is a good
recommendation.
Roni Even

> -----Original Message-----
> From: Michael Hammer [mailto:[e-mail]]
> Sent: Wednesday, November 06, 2002 5:04 PM
> To: Even, Roni
> Cc: [e-mail]
> Subject: RE: [SIPPING] question on 
> draft-johnston-sipping-cc-conferencing -00.txt
> 
> 
> Roni,
> 
> This is a lot of words to essentially admit that the protocol 
> elements that 
> prevent one user from stepping into someone else's conference 
> is outside 
> this protocol and that the concern that I have is still valid.
> 
> In today's conferencing systems (or at least with the one I use most 
> often), if you attempt to create a new conference using the 
> same identity, 
> it will be rejected since an existing conference with that 
> same ID already 
> exists for that time period.  (Note: the phone number dialed 
> gets me into a 
> server and the "password" is actually the conference identity.
> 
> So, back to the key question:  Is there some requirement that 
> ensures that 
> a URI will uniquely identify a distinct conference or some 
> other parameter 
> that indicates an attempt to create a new conference, 
> allowing a conference 
> server to inform the requestor that such an identity is 
> already in use.
> 
> Mike
> 
> 
> At 09:20 AM 11/6/2002 +0200, Even, Roni wrote:
> >Michael,
> >When  you use a URI in the INVITE what will happen will depend on the
> >conference policy (look at Rosenberg framework draft) 
> defined for this URI
> >by the conference server.
> >Conferencing application scenarios have some typical characteristics.
> >
> >1. Meet Me per conference server - For this type of 
> conference the user get
> >a URI that is a conferencing service URI, when an INVITE to 
> this URI is
> >received by a conference service it acts according to its 
> conference policy,
> >example behaviors are
> >
> >1. 1. Start an IVR session, or connect to Operator, to get 
> more information
> >- this is how some audio conferencing services work today. 
> This mode can
> >support reserved conferences as well as ad-hoc conferences 
> for UAs that only
> >support RFC3261
> >
> >1.2. The Policy may cause an automatic conference create or 
> join based on
> >the calling user. A conference can be defined earlier 
> (provisioned or by
> >Web) with the participants information and the time for the 
> conference. So
> >when a user sends an INVITE to the conference service URI 
> the focus knows
> >based on the policy what to do with this user.
> >
> >1.3 Create an ad-hoc conference and supply the conference ID 
> using notify to
> >the calling user.
> >
> >2. Meet Me per conference - The URI is a conference URI 
> known to the user.
> >This may cause either a join or create and join. If you are 
> worried about
> >having the same name twice or getting to it by mistake then 
> you can add
> >password to the conference or other authentication 
> mechanisms. This is very
> >common for reserved conferences or for general discussion rooms
> >
> >3. Meet me per User - In this type each user gets a URI that 
> he uses to call
> >the service. Based on the conference policy for this URI an action is
> >performed. This is also an available audio conferencing 
> service where you
> >get a number to call that will create a conference. You get 
> two passwords
> >one for you that you keep secret in order to start it and get some
> >privileges and the other you can give to the rest of the 
> participants that
> >enables them to join. The passwords can be fixed or changed 
> by some external
> >system.
> >
> >
> >What I am saying here is that the URI is a URI, the result 
> cannot be known
> >by the URI but is based on the policy server and that is 
> what happens in the
> >example when the first time the URI is used it creates the 
> conference (Here
> >I mean that the conference can even be initiated, if reserved, at the
> >scheduled time before the first user joins for example to 
> assign the needed
> >resources and because you get billed on it) the second one 
> joins, concern
> >for security can be solved by authentication.
> >
> >Roni Even
> >Polycom
> >
> >
> > > -----Original Message-----
> > > From: Michael Hammer [mailto:[e-mail]]
> > > Sent: Tuesday, November 05, 2002 11:16 PM
> > > To: Jonathan Rosenberg
> > > Cc: [e-mail]
> > > Subject: Re: [SIPPING] question on
> > > draft-johnston-sipping-cc-conferencing-00.txt
> > >
> > >
> > > Jonathan,
> > >
> > > Perhaps, I am misreading this or being mislead by the
> > > diagrams.  In Figure
> > > 2, Alice is creating the conference, and in Figure 3, Carol
> > > is joining a
> > > conference in progress.  My understanding is that the value
> > > represented by
> > > "Conf-ID" is identical in these two figures.  Could you
> > > explain to me where
> > > the difference lies?
> > >
> > > Mike
> > >
> > >
> > > Figure 2:
> > >
> > >       Alice                Focus                 Bob
> > >       Carol
> > >         |                    |                    |
> > >          |
> > >         | Alice creates the conference and chooses the
> > > conference URI.
> > > |
> > >         |                    |                    |
> > >          |
> > >         | INVITE sip:Conf-ID F1                   |
> > >          |
> > >         |------------------->|                    |
> > >          |
> > >         |   180 Ringing F2   |                    |
> > >          |
> > >         |<-------------------|                    |
> > >          |
> > >         |   200 OK Contact:Conf-ID;isFocus F3     |
> > >          |
> > >         |<-------------------|                    |
> > >          |
> > >         |        ACK F4      |                    |
> > >          |
> > >         |------------------->|                    |
> > >          |
> > >
> > >
> > > Figure 3:
> > >
> > >       Alice                Focus                 Bob
> > >       Carol
> > >         |                    |
> > >          |
> > >         |<==================>|
> > >          |
> > >         |                    |    Carol "dials in" to the
> > > conference   |
> > >         |                    |
> > >          |
> > >         |                    |              INVITE
> > > sip:Conf-ID F1      |
> > >         |
> > > |<----------------------------------------|
> > >         |                    |               180 Ringing F2
> > >          |
> > >         |
> > > |---------------------------------------->|
> > >
> > >         |                    |     200 OK Contact:Conf-ID;isFocus
> > > F3   |
> > >         |
> > > |---------------------------------------->|
> > >
> > >         |                    |                   ACK F4
> > >          |
> > >         |
> > > |<----------------------------------------|
> > >
> > >
> > >
> > > At 03:40 PM 11/5/2002 -0500, Jonathan Rosenberg wrote:
> > >
> > >
> > > >Michael Hammer wrote:
> > > >>In this draft the creating of a new conference and the
> > > joining of an
> > > >>existing conference appear identical.  Given that
> > > conference servers may
> > > >>host many conferences, and given that collision of selected
> > > identifiers
> > > >>could occur, is there any way for a user to indicate that
> > > they wish to
> > > >>connect to an existing conference versus creating a new one?
> > > >
> > > >The draft proposes two separate URIs for creating a new
> > > conference, and
> > > >joining an existing one. Therefore, a UA would indicate
> > > which case they
> > > >desire by using the appropriate URI. THis presumes that
> > > there is some
> > > >other means for propagatign those URIs. I believe the
> > > genreal model is
> > > >that the "Conference factory URI" - used for creating
> > > conferences - would
> > > >be learned through configuration. THe conference URI 
> itself would be
> > > >handed out as a result of sending an INVITE to the
> > > conference factory URI.
> > > >You could also get one through email, IM, web links, etc.,
> > > in which case
> > > >the context is provided to the user - "click here to JOIN
> > > the conference".
> > > >
> > > >
> > > >>A value such as "isnew" or "existing" could also permit, in
> > > the first
> > > >>case, an error indicating that a conference by that name
> > > already exists,
> > > >>or in the second case, an error indicating that a
> > > conference by that name
> > > >>does not exist.
> > > >
> > > >In the case of creation, the client does not provide the
> > > conference URI,
> > > >it is given the conference URI by the server. So, there 
> can never be
> > > >collisions. In terms of trying to join a conference that
> > > doesnt exist -
> > > >well, we have an error for that. Its 404 (Not Found).
> > > >
> > > >
> > > >>The presumption is that you do not want to interrupt an existing
> > > >>conference already in progress (case 1) or you do not want
> > > to create a
> > > >>conference (and pay corresponding charges) as an invitee if
> > > the invitor
> > > >>is not present (case 2).
> > > >>Is such a protection covered elsewhere in another draft?
> > > >
> > > >I dont think its needed. As above, the intent is encoded in
> > > the URI which
> > > >is used...
> > > >
> > > >-Jonathan R.
> > > >
> > > >--
> > > >Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > > >Chief Scientist                             First Floor
> > > >dynamicsoft                                 East 
> Hanover, NJ 07936
> > > >[e-mail]                     FAX:   [phone]
> > > >http://www.jdrosen.net                      PHONE: [phone]
> > > >http://www.dynamicsoft.com
> > >
> > > _______________________________________________
> > > Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments of core SIP
> >
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP