[Nice] a Farsight 2 nice transmitter, a git repo and various related thougths

[Dafydd Harries]

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.

-- 
Dafydd