Subject: RE: [Sipping] Conference speaker control

From: "Orit Levin" <[email-masked]>
Date: Tue, 7 Dec 2004 08:55:36 -0800

Roni,
My concern was about conferences with no floor control and no video.

Orit.

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2004 5:19 AM
> To: Orit Levin; David R Oran
> Cc: Magnus Westerlund; sipping
> Subject: RE: [Sipping] Conference speaker control
> 
> Orit,
> I am not sure I understand your concern. Is it the number of
> notifications on change of speakers by the event package that bother
> you.
> For this case it is typically handled by having a minimum time that a
> user must "speak" before he is announced as the current speaker. This
> has to do with not having to do very fast video switch for voice
> activated video switch scenarios
> Roni
> 
> -----Original Message-----
> From: Orit Levin [mailto:[email-masked]]
> Sent: Monday, December 06, 2004 7:46 PM
> To: David R Oran; Even, Roni
> Cc: Magnus Westerlund; sipping
> Subject: RE: [Sipping] Conference speaker control
> 
> I believe that the "architecturally right" way of providing the
"current
> speaker identification" is by including enough information in the
> media/data streams and letting the endpoints to make the correlation.
> Hence the Conference Event package uses a generalized "src-id"
> placeholder to hold RTP's ssrc and others to come. Hence the push to
> have a meaningful and easy to use source identification in MSRP.
> 
> Unfortunately, today RTP MCUs don't implement the RTP mixer
> functionality and don't necessarily include the ssrc information of
the
> mixed sources. Also, in PSTN - there is no way to have this
information
> (as Roni points out).
> 
> Technically, it is really easy to add the "current speaker"
> identification to the Conference Event package itself. The problem is
> how feasible this solution would be for free-going conferences with
the
> "current speaker" being changed all the time. My feeling is that going
> forward in XCON it is worthwhile to add the information to the package
> but use it by the focus for strictly controlled conferences only.
> 
> Orit.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of David R Oran
> > Sent: Saturday, December 04, 2004 2:15 PM
> > To: Even, Roni
> > Cc: Magnus Westerlund; sipping
> > Subject: Re: [Sipping] Conference speaker control
> >
> >
> > On Dec 4, 2004, at 9:04 AM, Even, Roni wrote:
> >
> > > Magnus,
> > > The whole discussion is about the SIP conference package that
> suggests
> > > that a SIP user will know the source of the stream based on SSRC.
So
> if
> > > there are media sessions that are not RTP is a SIP call then SSRC
> does
> > > not work.
> > > Roni
> > >
> > While this is strictly true, that's not the point. The point is
> whether
> > the conferencing work ought to rely on a "correlator" in or
associated
> > with the media stream, and have arrivals on the media stream trigger
> > any UI behavior, in order to identify the
> > source(s)/speakers/arm-wavers/typers/gas-emitters.
> >
> > I believe it should. In the case of RTP, this is the SSRC or the
CNAME
> > or both.
> >
> > If the conferencing system wishes to accommodate a media session
> > without this identification capability there has to be some way to
do
> > the correlation. I'm suggesting that emulating the media session by
> > actually always having one to the UA is a good way to do this rather
> > than sending speaker identification messages in realtime over the
> > conferencing control protocols.
> >
> > What do others think? This is important enough that other folks
ought
> > to weigh in here.
> >
> > Dave.
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
On
> > > Behalf Of Magnus Westerlund
> > > Sent: Friday, December 03, 2004 11:11 AM
> > > To: Even, Roni
> > > Cc: sipping; David R Oran
> > > Subject: Re: [Sipping] Conference speaker control
> > >
> > > Even, Roni wrote:
> > >> Hi,
> > >> This is from the comedia draft, is it RTP, it does not say so.
> > >>
> > >>            m=image 54111 TCP t38
> > >>            c=IN IP4 192.0.2.2
> > >>            a=setup:passive
> > >>            a=connection:new
> > >>
> > >> Roni
> > >
> > > No, that is clearly T38 over TCP which has a mode that is not RTP,
> > > however if you look in the RTP over TCP draft:
> > > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-framing-
> > > contrans-
> > > 03.txt
> > >
> > > You can find the following SDP:
> > > v=0
> > > o=first 2520644554 2838152170 IN IP4 first.example.net
> > > s=Example
> > > t=0 0
> > > c=IN IP4 192.0.2.105
> > > m=audio 9 TCP/RTP/AVP 11
> > > a=setup:active
> > > a=connid:1
> > >
> > > It is also this draft that register the RTP over TCP SDP protocol
> > > identifier.
> > >
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > > Multimedia Technologies, Ericsson Research EAB/TVA/A
> > >
> ----------------------------------------------------------------------
> > > Ericsson AB                | Phone +46 8 4048287
> > > Torshamsgatan 23           | Fax   +46 8 7575550
> > > S-164 80 Stockholm, Sweden | mailto:
[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
> > >
> > David R. Oran
> > Cisco Fellow
> > Cisco Systems
> > 7 Ladyslipper Lane
> > Acton, MA 01720 USA
> > Tel: +1 978 264 2048
> > 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: Cullen Jennings <[email-masked]>
Date: Wed, 08 Dec 2004 08:57:01 -0800

Sending the speaker updates (which are very frequent) in SIP would be a ton
of notifies - much more than any page mode IM system would end up doing
which we felt was a bad use of SIP as a transport. Using the conference
package, without some form of compression, would result in very large
notifies. The latency would be crap compared to the in media approach where
it is exactly synchronized with the media.

If you want some way other than an in media approach to get get this
information, seems like something along the lines of BFCP would work out
much better.