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

[Michael Hammer <[e-mail]>]

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