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

[Dafydd Harries]

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.

-- 
Dafydd