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

[Michael Hammer <[e-mail]>]

Roni,

I would agree to that.  Then this draft should reflect that thought.  I had 
the impression in this draft that the user suggested the identity:

    "For example, an INVITE sent with a Request-URI of
    sip:[e-mail] could be routed to the focus who
    would then create a conference.  This conference URI should be
    registered by the focus to become routable as a conference URI within
    the conf.example.com domain.  The returned Contact would look as
    follows: <sip:[e-mail]>;isFocus.  Note,
    however, that this approach relies on conventions adopted between the
    participant (human) and the focus."

However, this may be primarily a problem with a Type I UA and more of a 
backward compatibility issue, perhaps solvable only through naming 
conventions or other external means.

Mike


At 05:32 PM 11/6/2002 +0200, Even, Roni wrote:
>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