Subject: RE: [Sipping] conf: comments on draft-even-sipping-conference-sce narios-00

From: "Even, Roni" <[email-masked]>
Date: Sun, 23 Mar 2003 15:59:48 +0200

Eric,
Thanks, See in-line
Roni

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, March 20, 2003 9:44 PM
> To: Sipping (E-mail)
> Subject: [Sipping] conf: comments on 
> draft-even-sipping-conference-scenarios-00
> 
> 
> Section 1:
> Why is the "special member" the one that initiates the 
> conference?  Moderation, ownership, and the person that 
> happened to hit the bridge first are three distinct concepts. 
>  Pick a term, like Moderator, Owner, or Special Member, and 
> be sure it gets into the conferencing framework document.  I 
> would strongly suggest NOT using Conference Initiator.
> 
I agree, I wrote it before the other documents and I need to get back at it.
I think that there is a participant who has the right to reserve or start
conferences using CPCP directly or through some application. In some cases
he is the one who will  be billed for using the conference bridge so some
policies are needed for him, for example, if he hangs up does the conference
terminate. 

> 
> Section 3.3:
> I don't get this section at all.  A participant in a 
> SIP-based conference will be gatewayed into the SIP signaling 
> realm.  From the point of view of a focus, the *gateway* is 
> the SIP end point.  There is nothing special, nor any special 
> treatment, about the device on the other side of the gateway.
> 
I will take this one out
> 
> Section 3.4:
> Same comment as for Section 1 on Initiator vs. Moderator.  
> Here the draft is clearly talking about the moderator.
> 
>
I think like my comment for 1 that there may be the participant who has the
right to reserve or create conference (maybe get billed). He may make
another member to be the Moderator. For example I want you to present to may
company. I reserved the conference, and will pay for it, while you will be
the moderator and give the right to speak to the participants.
 
> Section 3.5:
> Authentication - Is the proposal to use digest authentication 
> with a password?  Is the proposal to use an IVR system to 
> collect a password?  Those are two very different cases with 
> very different protocol implications.
In the section I did not address the password mechanism, I suggested that
one method is for the focus to authenticate users (based on digest or IVR or
by knowing their IP address or any other known way) the other method is for
the authentication to be done by the conference owner(maybe a better term to
initiator), this can be done for example by  putting the owner and the new
member in a side bar and let the owner verify that he wants the new member
to join, this can also be done by an operator in a conference entry queue.
> 
> Control "the member may be able to manage" - Which member?  
> Do you really mean an arbitrary conference participant?  I 
> didn't think so.  In addition, letting a first participant 
> mute an arbitrary second participant in their mix is a really 
> neat trick.  Does anyone do that in the real world?  
> Likewise, most conferencing services allow the participant to 
> mute *their* stream, not *other* streams.  Muting other 
> streams is usually left to the moderator, for obvious reasons.
I agree that it is only for members who have the right privileges to do
these operations.

> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP