Subject: [siprec] Question on current speaker video

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jul 2011 15:37:16 +0200

Consider a CS with a single video medium that is used by an MCU to show the current speaker. All participants receive that medium. However, at any one time only one participant is contributing to the medium.

Now suppose there is an SRC that sends that medium (unmixed with any other medium) to an SRS. The metadata would represent this as a single MS element. There would also be n Participant elements (assuming sufficient information is available to the SRC). I assume that we would simply say that all n Participants are contributing to that MS, and all n Participants are recipients of that MS. Then there is no need to update the metadata every time the speaker changes (which could be very frequently).

Similarly for an audio bridge that filters out all but the loudest speaker or speakers. That could be signalled in RTP using https://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client-audio-level/, but would not be signalled by rapid updates of metadata.

Can folks confirm this is a correct understanding? It might require mention in the metadata draft, or possibly in the architecture draft.

John

---

From: Leon Portman <[email-masked]>
Date: Thu, 7 Jul 2011 16:52:23 +0300

There is also similar use case for trading floor speaker channels, where multiple traders (hundreds or thousands) listen to the same channel and some time push to talk to this channel. In such case, for example it is a separate event (push to talk) that can be sent over RTP stream as well

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, July 07, 2011 4:37 PM
To: [email-masked]
Subject: [siprec] Question on current speaker video

John
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 8 Jul 2011 23:01:49 +0530

Hi John,

Please see inline for my comments. I am adding Charles to provide his
comments here.

> Sent: Thursday, July 07, 2011 7:07 PM
> To: [email-masked]
> Consider a CS with a single video medium that is used by an MCU to
show
> the current speaker. All participants receive that medium. However, at
> any one time only one participant is contributing to the medium.
> 
> Now suppose there is an SRC that sends that medium (unmixed with any
> other medium) to an SRS. The metadata would represent this as a single
> MS element. There would also be n Participant elements (assuming
> sufficient information is available to the SRC). I assume that we
would
> simply say that all n Participants are contributing to that MS, and
all
> n Participants are recipients of that MS. Then there is no need to
> update the metadata every time the speaker changes (which could be
very
> frequently).

This could be modeled different ways depending on how we look at
(whether MCU mixing or just selecting active speaker video). 

In case the SRC is also the MCU, it will have the knowledge of which
participant sent the video medium. So the model at *that* instance could
like only one participant(active speaker) sending a MS and all n
Participants receiving the MS. 

     P1         P2         ..Pn
Recv ||sends     |recv        | recv
     MS          MS          MS 
     (video medium)

In case the SRC is another user in the conference and just receives a
medium from MCU it may not be able to find out the contributor directly
( without subscribing to Conf package).Assuming it learns, the model
instance would be same as I mentioned above.

I understand your concern on frequently updating the metadata every time
a speaker changes. If we wish to avoid we would have to model it the way
you said.  In that case I would think we have to inform the active
speaker through metadata at the least. I would like to hear from others
if they are ok to not have the finer details( like current speaker) at
SRS.

> 
> Similarly for an audio bridge that filters out all but the loudest
> speaker or speakers. That could be signalled in RTP using
> https://datatracker.ietf.org/doc/draft-ietf-avtext-mixer-to-client-
> audio-level/, but would not be signalled by rapid updates of metadata.

Here again the question is how the model would look. Will we have a
single MS and say all Participants (P1.. Pn) sends it or just the Px (
loudest speaker) send it ?

Regards,
Ram

> 
> Can folks confirm this is a correct understanding? It might require
> mention in the metadata draft, or possibly in the architecture draft.
> 
> John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jul 2011 15:09:34 -0400

Couldn't it also be the case that the metadata is as John described, but 
the RTP of the video changes SSRC according to who the video is from?

(That then would leave the SRS with the problem of mapping SSRC to 
participant.)

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 8 Jul 2011 13:50:44 -0700

I agree. RTP/RTCP already provides an efficient mechanism for this, and
I think we should use it rather than modeling in such a way that it
forced a metadata change every time the active speaker changes. I
suppose the model itself should be, and is, flexible enough to allow one
to represent such a case as a single MS with 'n' participants, or 'n'
MSs each with a single participant; but I expect the former to be a much
more common implementation approach.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
> Sent: Friday, July 08, 2011 12:10 PM
> To: [email-masked]
> Subject: Re: [siprec] Question on current speaker video
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 9 Jul 2011 07:35:14 +0530

Charles,

I do agree that RTP/RTCP has mechanisms for the same. I am fine with
this approach in case everyone agrees.

Regards,
Ram

> Behalf Of Charles Eckel (eckelcu)
> Sent: Saturday, July 09, 2011 2:21 AM
> To: Paul Kyzivat; [email-masked]
> > >> Behalf Of Elwell, John
> > >> the current speaker. All participants receive that medium.
> However,
> at
> > > In case the SRC is another user in the conference and just
receives
> a
> > > I understand your concern on frequently updating the metadata
every
> time
> > > a speaker changes. If we wish to avoid we would have to model it
> the
> way
> > > if they are ok to not have the finer details( like current
speaker)
> at
> > > single MS and say all Participants (P1.. Pn) sends it or just the
> Px
> (