Subject: [Sipping] conferencing terminology in cc-fw

From: "Petri K. Koskelainen" <[email-masked]>
Date: Fri, 28 Jun 2002 14:16:15 -0400 (EDT)

I think conferencing server is a valid name
for a typical SIP server providing
conferencing services (and can be used
e.g. in conf-req document). 

Rohan is talking about terminal-based
call agent which provides only very basic 
conference or multi-party services enabled by 
standard SIP (e.g. no ACLs, no chair control,
no mass-invitation etc).

How should we separate these two cases?

mixer is certainly too RTP-centric term
(for most people it means RTP audio-mixer).

It is a standard SIP UA which is proving
some call control or multi-party services. 
Signaling is centralized. Media may or may not 
be centralized (it may be mixed in audio case
or use different topology e.g. multicast). 
I agree that it is not a conferencing server.

Conferencing requirements document should provide
both clarifications for this kind of simplified
multi-party call handling by standard SIP UAs, and
requirements for true conferencing server functionality 
(including ACLs, chair privileges and other management features) 
for conferencing server.

It seems that common name is not possible
for these entities since they are so
different.

The exact name for cc-fw mixer might
be e.g. "SIP mixer", "basic
SIP conference server", or
"centralized SIP UA", or "multi-party UA"

The "conference server" term should be used for
a SIP server (or terminal) which provides
also management functions (e.g. mass-invitation,
chair control, ACLs etc) for which the requirements
are to be defined.

--
Petri

_______________________________________________
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: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Mon, 1 Jul 2002 10:54:31 -0600

> Rohan writes:
> 
> On Monday, July 1, 2002, at 07:10 AM, Rosen, Brian wrote:
> 
> > Please, can we keep the signalling entity (Conference Server)
> > separate from the mixing entity (Conference Mixer)?  The former
> > is indeed just a UA, the latter need not have any standardized
> > signalling, could use something like Megaco, or could be
> > combined with the Conference Server.
> 
> I want a name for the component which is a SIP UA which accepts SIP 
> requests for the conference URI.  I like the name SIP mixer.  

"SIP mixer" just invites confusion. It leaves the impression that media is mixed on this device. And what the heck does it mean to "mix" a group of dialogs? Why not call this device the "conference coordinator" or something else less prone to confusion?

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 
                sip:[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Jul 2002 16:37:34 -0400

Yes, I agree with that, at least for now.
Probably, at least for our purposes, have to say "exclusive"
control.

All I care about now is that the mixer is really an independent
entity, because we have cases where it is, and that
centralized star conferences don't automatically imply 
centralized star mixers.

Brian

> -----Original Message-----
> From: Don Stanwyck [mailto:[email-masked]]
> Sent: Monday, July 01, 2002 3:18 PM
> To: [email-masked]
> Subject: RE: [Sipping] conferencing terminology in cc-fw
> 
> 
> I'd argue that a Conference Host MUST (not MAY) have (or have control
> of) media server resources appropriate to the session media 
> to be mixed.
> Media server resources may be a 2-stream mixer in a SIP or a
> multi-thousand port bridge such as are found in
> carrier-class/carrier-scale media servers.
> 
> Don Stanwyck
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Orit Levin
> > Sent: Monday, July 01, 2002 12:47 PM
> > To: [email-masked]
> > Cc: 'Petri K. Koskelainen'; Rosen, Brian; 'Rohan Mahy'
> > Subject: RE: [Sipping] conferencing terminology in cc-fw
> > 
> > 
> > In Star topology, our proposal is to use a "A Conference 
> > Host" for a UA that deals with SIP signaling for constructing 
> > a SIP conference . A Conference Host can be either a terminal 
> > or an application server.
> > 
> > In addition, a Conference Host MAY have a Media Processor 
> > function for "mixing" or/and switching the media.
> > 
> > These definitions appear in the already submitted draft for 
> > conferencing requirements.
> > 
> > Orit.
> > 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[email-masked]]
> > Sent: Monday, July 01, 2002 11:37 AM
> > To: Rosen, Brian
> > Cc: 'Petri K. Koskelainen'; [email-masked]
> > Subject: Re: [Sipping] conferencing terminology in cc-fw
> > 
> > 
> > 
> > > Please, can we keep the signalling entity (Conference 
> > Server) separate 
> > > from the mixing entity (Conference Mixer)?  The former is 
> > indeed just 
> > > a UA, the latter need not have any standardized signalling, 
> > could use 
> > > something like Megaco, or could be combined with the Conference 
> > > Server.
> > 
> > requests for the conference URI.  I like the name SIP 
> mixer.  In the 
> > industry a conference server is a product with lots of 
> features which 
> > includes a bunch of components.  what do you mean by a 
> > conference mixer?
> > 
> > > The Conference Server could use local mixing, or 
> > centralized mixing, 
> > > or a combination.  The server could be a terminal UA, could be 
> > > co-located with a terminal UA or could be a centralized shared 
> > > resource.  With a Star conference, the Conference Server 
> > has one point 
> > > to point SIP dialog with each conference participant.
> > 
> > no this assumes a composed model....
> > 
> > > It understands how the mixing is done, and tells each participant 
> > > where to send/receive media (RTP) streams in the SDP it 
> > sends/accepts 
> > > on the dialog.
> > >
> > > The mixer is one end of some RTP streams.  It could be in a 
> > terminal, 
> > > could be attached to a terminal, or could be a centralized, or 
> > > distributed, shared resource.  The conference server has 
> to tell it 
> > > how to mix streams, but it doesn't need any other signalling.
> > what's wrong with a text mixer?
> > 
> > thanks,
> > -rohan
> > 
> > 
> > > It seems pretty easy to keep these two entities separate, 
> > as long as 
> > > the Conference Server knows where the mixing resources are 
> > and how to 
> > > control them.  For the moment, I'm happy to keep the 
> mechanism that 
> > > the Conference Server uses to find out about Conference 
> > Mixers out of 
> > > the specs (i.e. built in knowledge, provisioning, or something 
> > > proprietary).  After we get all the other parts of the 
> > picture speced, 
> > > we can go back and do "mixer discovery".
> > >
> > > Brian
> > >
> > >> -----Original Message-----
> > >> From: Petri K. Koskelainen [mailto:[email-masked]]
> > >> Sent: Friday, June 28, 2002 2:16 PM
> > >> To: [email-masked]
> > >> Subject: [Sipping] conferencing terminology in cc-fw
> > >>
> > >>
> > >>
> > requirements for 
> > >> true conferencing server functionality (including ACLs, chair 
> > >> privileges and other management features) for 
> conferencing server.
> > >>
> > >> 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
> > 
> > 
> > Use [email-masked] for questions on current 
> > sip Use [email-masked] for new developments of core SIP
> > 
> > Use [email-masked] for questions on current 
> > sip Use [email-masked] for new developments of core SIP
> > 
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 1 Jul 2002 16:32:50 -0400

> > The Conference Server could use local mixing, or centralized
> > mixing, or a combination.  The server could be a terminal UA,
> > could be co-located with a terminal UA or could be a centralized
> > shared resource.  With a Star conference, the Conference Server
> > has one point to point SIP dialog with each conference participant.
> 

I must be very confused, sorry.  I thought we had agreed that
star implies a single central entity that does the signalling
to make a conference.  Are you suggesting that star can mean
mesh of signalling between participants?  I know we had 
agreed to only consider star connected conference models to
start with.

I don't mean to imply anything about how media is mixed.
I don't mean to limit SIP conferences to star models, just
	to limit the first set of specs to star models.

> > sends/accepts on the dialog.
> >
> > distributed, shared resource.  The conference server has to tell it
Sorry, confusion again.  Are you objecting to assuming "RTP"?
You want to "mix" text, and text isn't sent on RTP streams.  Is that it?
I don't have any problem with that.   We need a word.  Just using
"mixer" invites confusion with the RTP mixer.

Brian

---

From: [email-masked]
Date: Tue, 2 Jul 2002 09:49:35 +0300

I had a similar suggestion for Presence Server and Presence client a few weeks back, so I suggest the same here.

Conference Agent: sip entity that provides centralised sip signalling for conferences. It may have knowledge about the media mixing.

Conference Server: a conference agent physically residing in the service provider's network

Edge Conference Server (or Agent): a conference agent co-located with a sip user agent.

Comments?

Regards,
Hisham

> From: ext Petri K. Koskelainen [mailto:[email-masked]]
> Sent: Friday, June 28, 2002 9:16 PM
> To: [email-masked]