RE: FW: [Sipping] comments on draft-ietf-sipping-cc-framework-00. txt

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

Rohan,
The name for the whole thing can be conferencing bridge (the name for audio)
or MCU (multipoint control unit). These names are used in the industry and
are not related to a specific signalling protocol. Since this is a sipping
draft we can either assume or specify that this is a SIP conferencing bridge
or SIP MCU. I agree that the document should address the composed device but
maybe explain that it has the control part and the media processing part,
this will address the different mixing models like the one in 4.3.3.2

thanks
Roni Even

> -----Original Message-----
> From: Rohan Mahy [mailto:[e-mail]]
> Sent: Monday, March 11, 2002 8:12 PM
> To: Even, Roni
> Cc: [e-mail]
> Subject: Re: FW: [Sipping] comments on 
> draft-ietf-sipping-cc-framework-00.txt
> 
> 
> Hi Roni,
> 
> Thanks for your comments.  A few replies inline...
> 
> thanks,
> -rohan
> 
> On Mon, 11 Mar 2002, Even, Roni wrote:
> > -----Original Message-----
> > From: Even, Roni [mailto:[e-mail]]
> > Sent: Tuesday, March 05, 2002 2:11 PM
> > To: [e-mail]
> > Subject: [Sipping] comments on 
> draft-ietf-sipping-cc-framework-00.txt
> >
> >
> > Hi,
> >
> > I read the draft and I think it is a good idea to put a 
> framework document
> > for multiparty. I have a couple of comments
> >
> > 1. The document include a reference to a conferencing 
> bridge and to a mixer.
> > I think that the terms should be clear. My understanding of 
> a mixer as
> > defined in RTP (see 4.5.1.1) is that it handles only the 
> media streams and
> > is not dependent on a signalling protocol. I think that the 
> decomposed
> > approach of a conference bridge that is build from 
> controller and media
> > processor (mixer) may be used. In section 4.3.2 it says "In 
> a centralized
> > mixing model, all participants have a pairwise SIP and 
> media relationship
> > with the mixer."  a mixer does not have SIP relationship. 
> Same in 4.4 "For
> > example, a mixer involved in a conversation space may wish 
> to provide URLs
> > for conference status, and/or conference/floor control. "
> 
> OK, I meant to define the characteristics of the 
> un-decomposed conference
> bridge.  I agree that you can decompose this into a mixer and a
> controller.  I think it is a good idea to add this to the draft, but I
> need a good name that is not overloaded for the larger thing. 
>  Perhaps:
> "SIP mixing service"?
> 
> > 2. In section 4.3.2.2 "Once the server is discovered, a 
> conference ID is
> > chosen. This ID must be globally unique." I think that we 
> need to specify
> > how this is done. Does the server select the ID for the 
> ad-hoc conference.
> > If the user defines it, we need to specify how to inform 
> that the conference
> > ID is not unique.
> 
> sounds reasonable
> 
> > 3. Section 4.4 presents the topic of conveying Information 
> and Events based
> > on draft-rosenberg-sip-call-package-00.txt. How do you see 
> the relationship
> > between the documents, does this document present 
> requirements for the
> > draft-rosenberg-sip-call-package-00.txt document. I think 
> that this is a
> > question about the way we address other requirements that 
> are related to
> > other documents.  I have some specific events that make sense in a
> > conferencing environment. For example in audio conference 
> to notify who is
> > the loudest speaker currently (enabling an application that 
> will present it
> > to the participants) In video conference the requirement is 
> to know who is
> > being seen by the others.
> 
> are all of these events described in the levin draft?  If 
> not, we need to
> get a list of these.  I think we may need to partition some of these
> events into multiple packages, as the current speaker and who is being
> seen will likely change much more often than which participants are
> represented.
> 
> > 4. In 4.5.1.1 "For example, the default combining for an 
> audio conference
> > would be an N-1 configuration. In other words, each user 
> receives a mixed
> > media stream that represents the combined audio of all the 
> users except
> > himself or herself. " This statement may be true for a 
> small conference. In
> > large conferences the policy is to mix M loudest speakers 
> out of the N
> > participants (M is typically 3).
> 
> of course, or mix the last, loundest, and longest speakers... 
>   I'll add
> some text to that effect.
> 
> thanks,
> -rohan
> 
> > Thanks
> > Roni Even
> >
> > ***********************
> > Roni Even
> >
> > Polycom Network Systems
> > Tel: [phone]
> > Mobile: [phone]
> > Fax: [phone]
> > Email: [e-mail]
> >
> >
> > _______________________________________________
> > 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