Subject: RE: [Sipping] Conference speaker control

From: "Even, Roni" <[email-masked]>
Date: Mon, 29 Nov 2004 16:31:49 +0200

Brian,
My view is that it should include this information and I talked with
Orit about it. I think that Orit suggested adding the speaker
information when we extend it for XCON
Roni

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, November 29, 2004 4:23 PM
To: Even, Roni; 'Johnston, Alan'; 'Oliver Schwaneberg'; 'sipping'
Subject: RE: [Sipping] Conference speaker control

Roni

Are you proposing to change the SIP Conference Package?

Brian

> -----Original Message-----
> From: Even, Roni [mailto:[email-masked]]
> Sent: Monday, November 29, 2004 9:11 AM
> To: Brian Rosen; Johnston, Alan; Oliver Schwaneberg; sipping
> Subject: RE: [Sipping] Conference speaker control
> 
> Brian,
> I am sorry to continue to argument. I thought the view in my reply was
> clear. I think that since SIP has a dialog between two endpoint and
not
> just an RTP session, and since the meaningful information that needs
to
> be displayed to the user is who is speaking and not what is the ssrc
of
> the stream that it received, it will make more sense to have this
> information coming from a SIP conference bridge as the speaker
> indication.
> Roni
> 
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, November 29, 2004 3:59 PM
> To: Even, Roni; 'Johnston, Alan'; 'Oliver Schwaneberg'; 'sipping'
> Subject: RE: [Sipping] Conference speaker control
> 
> Roni
> 
> I'm leery of providing more than one way to do the same thing.  I'll
> agree
> that the labeling of windows is not covered by existing RTP specs, but
I
> would hope what we do in XCON does not involve any new system, but
> merely
> extends the information we have to, for example, correlating the SSRCs
> of
> the video stream with the SSRCs of the audio stream, and correlating
> things
> like display names to SSRCs.  We'll have to explore the details, of
> course,
> to see exactly what is needed, and how best to provide it, but I hope
we
> don't create new mechanisms when existing ones are satisfactory, or
can
> be
> made satisfactory with minimal work.
> 
> Here in SIPPING, I think that Alan's response is correct, and nothing
> else
> should be said.
> 
> Brian
> 
> > -----Original Message-----
> > From: Even, Roni [mailto:[email-masked]]
> > Sent: Monday, November 29, 2004 8:42 AM
> > To: Brian Rosen; Johnston, Alan; Oliver Schwaneberg; sipping
> > Subject: RE: [Sipping] Conference speaker control
> >
> > Brian,
> > I will start with my current view of the market.
> > PSTN bridge do not do RTP so they cab only identify the speaker by
> > external means.
> > H.320 conferencing bridges (Video conferencing over ISDN) are not
> using
> > RTP and use the control/application layer to specify who the speaker
> is
> > and who is being seen.
> > H.323 conferencing bridges use H.245 means to specify the speaker.
The
> > reasons are that the part that decides who is being seen and who is
> the
> > speaker is under the control of what we call the focus and not the
RTP
> > mixer. The bridge is sending more meaningful information then the
SSRC
> > of the current stream like the user name. This applies both to point
> to
> > point calls as well as for multipoint calls.
> >
> > RFC3550 defines mixers and translators in section 7 " In addition to
> end
> > systems, RTP supports the notion of "translators" and "mixers",
which
> > could be considered as "intermediate systems" at the RTP level."
> > These entities are working on the RTP level and are defined to work
> > without any signaling layer on top of them. That is why RFC3550
> > describes how they can work without an upper conferencing layer and
> > explain what they should do with the RTP and RTCP.
> > We do not have a clear definition of what is a SIP conference bridge
> but
> > my assumption is that it has a conferencing application layer on top
> of
> > RTP and therefore can give a better description on the application
> layer
> > about the speakers. RFC3550 for example do not address multi windows
> > (Continuous presence) so the contributing sources are not enough to
> > convey the information about who is being seen in each window.
> > My suggestion is that we should provide other mechanism to describe
> the
> > speaker or who is being viewed that will be based on the conference
> > application layer and will send the user identification known to the
> > conference bridge.
> > Roni
> >
> >
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Monday, November 29, 2004 3:11 PM
> > To: Even, Roni; 'Johnston, Alan'; 'Oliver Schwaneberg'; 'sipping'
> > Subject: RE: [Sipping] Conference speaker control
> >
> > Roni
> >
> > I'm not following this.  Most conference bridges are not RTP mixers,
> but
> > if
> > they aren't RTP mixers than they aren't being used for SIP
> conferencing.
> > So
> > what?  If you have a SIP conference, then you would have an RTP
mixing
> > bridge, you would have SSRCs, and the conference package would work
as
> > Alan
> > suggested, right?  What am I missing here?  Are you suggesting that
> some
> > SIP
> > conference bridges don't do this?  If so, should we provide other
> > mechanisms, or suggest that the bridges should follow the RFC?
> >
> > Agree that we need more here than the package as specified provides,
> but
> > agree that it's XCON that will work on it.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
On
> > Behalf
> > > Of Even, Roni
> > > Sent: Monday, November 29, 2004 5:12 AM
> > > To: Johnston, Alan; Oliver Schwaneberg; sipping
> > > Subject: RE: [Sipping] Conference speaker control
> > >
> > > Hi Alan,
> > > The approach described in the SIP conference package section
6.1.7.3
> > > describes how a RTP mixer will behave, Most conference bridges are
> not
> > > RTP mixers and will not supply the list of contribution resources.
> > > The current draft is missing this function that identify the
current
> > > talked as well as who is being seen in each of the sub windows in
a
> > > multi window view.
> > > I expect that there will be more information when the package will
> be
> > > extended as a result of the work in the XCON group.
> > > Roni Even
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
On
> > > Behalf Of Johnston, Alan
> > > Sent: Monday, November 22, 2004 10:23 PM
> > > To: 'Oliver Schwaneberg'; sipping
> > > Subject: RE: [Sipping] Conference speaker controll
> > >
> > > Hi Oliver,
> > >
> > > An RTP (SSRC) approach is possible using the SIP conference
package.
> > > See
> > > Section 6.1.7.3 of draft-ietf-sipping-conference-package-06.txt.
> This
> > > has
> > > the advantage of being synchronized with the media (unlike a SIP
> > NOTIFY
> > > approach) but does require the RTP mixer to include SSRC
> identifiers.
> > >
> > > Thanks,
> > > Alan Johnston
> > > sip:[email-masked]
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Oliver
Schwaneberg
> > > > Sent: Monday, November 22, 2004 9:27 AM
> > > > To: sipping
> > > > Subject: [Sipping] Conference speaker controll
> > > >
> > > >
> > > > Hi everybody!
> > > > I'm new here and I like to know if there's any approach to
> > > > determine which participant of an conference is actually
talking?
> > > >
> > > > For example:
> > > > If you're using a central mixer it would be possible to scan
> > > > for talking participants (silence sound suppression, level
> > > > detection, etc.). In that case the Mixer could send
> > > > NOTIFY-Messages in order to inform every participant about
> > > > the talking-state of every other participant.
> > > >
> > > > So back to my question: Is there already something like this?
> > > >
> > > > Thank you in advance!
> > > >
> > > > Oliver Schwaneberg
> > > >
> > > >
> > > > _______________________________________________
> > > > 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: David R Oran <[email-masked]>
Date: Mon, 29 Nov 2004 10:19:28 -0500

I come down pretty strongly on the side of simply declaring that 
SIP/XCON conference bridges use RTP in the media plane and hence mix 
using RFC2550 mixing procedures. This means they include CSRCs in the 
output stream(s).

Following from this, it seems that the conference control and info 
protocol machinery should indicate who is/are speaking by referencing 
the CSRCs of the contributing streams. The actual identity could either 
be derived from the SDES of the input stream or a purely SIP control 
plane mechanism.

Remember that this applies to video as well in the case of video mixers 
that do compositing.

I'd further like to note that there are a number of very good reasons 
why an XCOM-compliant conference bridge ought to be an 
RFC3550-compliant RTP mixer/translator - the speaker identification 
machinery is only one of many.

Dave.

>>>> 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]