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

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

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