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

From: "Even, Roni" <[email-masked]>
Date: Wed, 13 Mar 2002 09:21:36 +0200

Hi,
Another option maybe the 3GPP name which is Multimedia Resource Function or
we can use Server (MRF or MRS) but then we will need to specify what are the
general functions of this server. About Instant messaging conversations I
would think that this is an application composed from an application server
based on IM that uses an audio conferencing bridge and I wonder if we are
going to define applications or just supply primitive to enable application
development.
Thanks
Roni Even

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2002 5:54 PM
> To: Even, Roni
> Cc: [email-masked]
> Subject: RE: FW: [Sipping] comments on 
> draft-ietf-sipping-cc-framework-00.txt
> 
> 
> 
> Hi,
> 
> While this works fine for audio and video, I'm not sure 
> someone would ever
> apply this name to multiparty instant messaging converstations for
> example.  I'm not opposed to using the old name, but if we can find
> something better I'd rather use the new name.
> 
> thanks,
> -rohan
> 
> On Tue, 12 Mar 2002, Even, Roni wrote:
> > 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:[email-masked]]
> > > Sent: Monday, March 11, 2002 8:12 PM
> > > To: Even, Roni
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > > Sent: Tuesday, March 05, 2002 2:11 PM
> > > > To: [email-masked]
> > > > 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: +972-3-9251200
> > > > Mobile: +972-55-481099
> > > > Fax: +972-3-9211571
> > > > Email: [email-masked]
> > > >
> > > >
> > > > _______________________________________________
> > > > 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

---

From: "Garland Sharratt" <[email-masked]>
Date: Sun, 17 Mar 2002 16:28:05 -0800

It is certainly important the architecture support the separation of the
controller (signaling, call control) from the mixer (mixing, RTP).  Vendors
can choose to bundle the controller with the mixer if they choose.

I like the term Media Resource Function (MRF) for a logical element that
does media processing but does not do signaling.  (Media Server is the
common physical element name.)

Garland

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Even, Roni
Sent: Tuesday, March 12, 2002 23:22
To: 'Rohan Mahy'; Even, Roni
Cc: [email-masked]
Subject: RE: FW: [Sipping] comments on
draft-ietf-sipping-cc-framework-00.txt

Hi,