RE: [Sipping] Conference speaker control

["Even, Roni" <[e-mail]>]

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:[e-mail]] 
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:[e-mail]]
> 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:[e-mail]]
> 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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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:[e-mail]
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] 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 [e-mail] for questions on current
> > > sip Use [e-mail] 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 [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP