Subject: RE: [Sipping] Conference speaker control

From: "Orit Levin" <[email-masked]>
Date: Mon, 6 Dec 2004 09:45:50 -0800

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: "Chris Boulton" <[email-masked]>
Date: Tue, 7 Dec 2004 13:15:21 -0000

<<Comment in-line>>

[Chris Boulton] Agreed that this should be included and that it will not
always be that useful.  It might be worth while including appropriate
attributes that allow the current speaker to be controlled e.g. timeout
(if no update is received then return to default) + this could help to
enforce rate limitation.

Chris.

Orit.

Behalf
suggests
if
does
whether

This email and any attached files are confidential and copyright protected.  If you are not the addressee, any dissemination, distribution or copying of this communication is strictly prohibited.  Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 7 Dec 2004 15:18:44 +0200

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

Orit.

Behalf
suggests
if
does
whether