Subject: RE: [Sipping] conferencing terminology in cc-fw

From: Orit Levin <[email-masked]>
Date: Mon, 1 Jul 2002 14:47:29 -0400

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

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.  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
>>
>>
>>
>> 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
>>
>
> _______________________________________________
> 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

_______________________________________________
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: "Don Stanwyck" <[email-masked]>
Date: Mon, 1 Jul 2002 13:18:13 -0600

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

> 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.
> 
> > 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.
> 
> > 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.
> 
> > 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 
> 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
> >>
> >
> > 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: "Don Stanwyck" <[email-masked]>
Date: Mon, 1 Jul 2002 13:30:52 -0600

(gotta learn to re-read my postings before sending. Missing word
supplied below)

> of) media server resources appropriate to the session media 
> to be mixed. Media server resources may be a 2-stream mixer 
> in a SIP *phone* or a multi-thousand port bridge such as are found 
> in carrier-class/carrier-scale media servers.
> 
> Don Stanwyck
> 
> > >> both clarifications for this kind of simplified multi-party call 
> > >> handling by standard SIP UAs, and
> > requirements for