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

[Olivier Crête]

On Mon, 2008-05-05 at 22:21 +0100, Dafydd Harries wrote:
> Ar 05/05/2008 am 17:12, ysgrifennodd Olivier Crête:
> > 
> > On Mon, 2008-05-05 at 22:07 +0100, Dafydd Harries wrote:
> > > 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.
> > 
> > Yes it is, the problem is that I was waiting for all components to reach
> > the same state before changing the "stream state", but the only state
> > where all the components are is "disconnected" and "ready". I guess
> > there should be a more complex component->stream state function (like if
> > only one component is in connecting, then place the whole stream in
> > connecting and stuff like that).
> 
> If the stream state is application-specific, I'm not sure how useful it is to
> have libnice try to calculate one itself.

You may be right..

-- 
Olivier Crête
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/nice/attachments/20080505/5a0f3191/attachment.pgp