Subject: RE: [Sipping] Conference speaker control

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

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: "Brian Rosen" <[email-masked]>
Date: Mon, 29 Nov 2004 09:23:23 -0500

Roni

Are you proposing to change the SIP Conference Package?

Brian

> Sent: Monday, November 29, 2004 9:11 AM

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Nov 2004 16:11:28 +0100

Hi Roni,

Sorry if I do not have a full picture of the architecture of the 
conferencing. Please enlighten me if I overstep any previous agreements.

> information coming from a SIP conference bridge as the speaker

RTP with RTCP does have the mechanism to provide a receiver with the 
name or at least the CNAME for all SSRCs that are used in all media 
streams. That way one can identify the actual media senders. It might be 
beneficial depending on the conferencing side functions to bind the 
CNAME to some RTP/RTCP external user identification. Thus including 
CNAME in the state package may be beneficial, instead of needing to 
provide SSRC for all participants in all media streams. It would reduce 
the data  points with a factor equal to the number of media.

Is the issue that you don't think media reception from a specific SSRC a 
good indication that the source is active? Otherwise I don't see the 
reason to not utilize the functionality present in RTP/RTCP.

In regards to RTP mixer I would like to point out that the conference 
bridge must not necessarily be a mixer, it could be a relay. If the 
bridge simply forwards all packets from all participants RTP and RTCP to 
  everybody, no mixing is necessary. The downside is that the media 
amount gets increased every time more than one transmits data. This of 
course has its issue with users that has a limited bandwidth. The higher 
the bit-rate of the media the more sensible it seems to do mixing. But 
mixing T.140 conference text seems rather unnecessary.

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]