[Nice] a Farsight 2 nice transmitter, a git repo and various related thougths
dafydd.harries at collabora.co.uk
Mon May 5 14:07:18 PDT 2008
Ar 05/05/2008 am 17:04, ysgrifennodd Olivier Crête:
> On Mon, 2008-05-05 at 21:55 +0100, Dafydd Harries wrote:
> > Ar 30/04/2008 am 14:25, ysgrifennodd Kai.Vehmanen at nokia.com:
> > > Hi,
> > >
> > > On 30 April 2008, Olivier Crête wrote:
> > > >Why is the state-changed signal per-component and not
> > > >per-stream? Should I care about the component state? I
> > > >currently wait until all components reached one state before
> > > >reporting it upwards, it that good?
> > > >Also, I guess the whole stream should be failed if one
> > > >component fails..
> > >
> > > this is another design choice made for old-jingle compatibility.
> > > In old-jingle, one could start sending media immediately after
> > > connectivity was established over some candidate-pair. Reporting
> > > the states on per-component basis allows this mode of operation,
> > > as well as others. So basicly we move the decision whether to send
> > > immediately, or whether to wait for a) all components of a stream,
> > > b) all streams, c) something else ... onto the client -> library
> > > allows different usage models.
> > >
> > > But I'm open for changing this. For instance making the signals
> > > per-stream should be ok. There might be a small delay in starting
> > > to send media (you have to wait for other components as well), but
> > > OTOH, this is somewhat questionable optimization to start with as at
> > > that point you don't yet know whether connectivity can be established
> > > for the other components of a stream. The per-component signals are
> > > definitely a hassle for most clients, as they need to track the
> > > state of their streams based on component signals (see nice/docs/design.txt
> > > and the considerations for SIP clients).
> > >
> > > Of course one option is to emit both per-component and per-stream
> > > signals.
> > Sending RTCP without RTP seems a bit strange to me, though perhaps RTP without
> > RTCP makes more sense. I suspect it's probably ok to just make the signal
> > per-stream though.
> RTP without rtcp makes sense in many cases, such as muxing rtcp into rtp
> or just having one end that doesn't support rtcp (such as old google
> jingle). There should be some way for libnice to express that one
> component failed without failing the whole stream (and let the
> application decide), at least, that's where my current thoughts are on
> the matter.
Isn't this what the current API is? You monitor the signals on each component,
and decide for yourself if the stream is ok or not.
More information about the Nice