[libnice] Ignore host candidates for testing

Thu Jun 25 01:26:10 PDT 2015

On Thu, 2015-06-25 at 05:58 +1200, Felix Schlitter wrote:
> > Why do you think it’s a bad approach?
> 
> It just seemed like a pretty crude way of doing things, because I am 
> just messing with the sdp string.
> Also, the candidate numbers are no longer sequential (not sure if 
> that matters).
> Lastly, and most importantly - it does not work. Should it?

I’m likening it to manually transferring the candidates between the
peers using the new-candidate-full signal and selectively dropping some
of them.

Your peers might be generating reflexive candidates from the other ones
which you do forward, but I can’t really tell without seeing a log.
Blocking the UDP traffic may be a better option.

> > I actually implement this using iptables rules which block UDP
>  traffic on localhost.
> 
> Good idea, however it would still be great to somehow do this in-app 
> to write integration tests a bit
> easier. Messing with the environment to run tests does not  really 
> resonate with me - Further, we
> are targeting Windows specifically.

Unfortunately that’s the current state of things with libnice — it is
not easy to test. Improving this is high on my list of things to do
when I find some time. My current plan is to abstract the socket
interface libnice uses, so that you could pass in fake sockets, rather
than libnice using real ones created by calling socket(). The fake
sockets could drop all packets for connections you want to ignore, for
example.

> > Good idea. GitHub project added
> 
> Awesome! Star added, fork created. I will have some pull requests 
> coming your way soon to fix
> compilation on windows.

That would be lovely, thank you!

> > Note that while pull requests on GitHub are fine, I don’t think we 
> want
> > to use GitHub’s issue tracking, or we’ll end up with bug reports 
> there
> > and on Bugzilla, and everything will get very confusing.
> 
> This is up to you, but the issue list is essentially the mailing list 
> AND the bug tracker in one. It is
> a place for both feature suggestions and bug tracking (although can 
> be used with external, more
> formal bug tracker - since github is pretty loose). I would highly 
> suggest making the move, there
> are not too many bugs reported and the transition would be easy. Here 
> is what you get out of it:

I’ll discuss this with Olivier and Youness, but I’m quite against
hosting core libnice infrastructure on a non-free service which is not
under community control. I was burned quite badly when gitorious
disappeared, which has made me (perhaps unduly) wary.

If only there were a distributed bug tracking system which could mirror
bug reports just like we mirror git repositories.

> (*) I clicked the "bugzilla" link on the `nice.freedesktop.org/wiki` 
> and it takes me to a sign up page.
> From there I am puzzled as to where to click to see the list of 
> already reported bugs.
> Ah I click the unseeming "reports" link, hm that takes me to another 
> page without a listing, maybe I
> click "search" on this page, nope, maybe I click "tabular chargs", 
> nope... sigh. Back to the top row,
> maybe I click "browse"? That gets me the issues of all projects. How 
> useful is that?...

Yeah, the freedesktop.org Bugzilla is a little unfortunate in how it’s
set up. :-(

List of all open libnice bugs: https://bugs.freedesktop.org/buglist.cgi
?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=R
EOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&list_id=549372&produc
t=nice&query_format=advanced
Report a new libnice bug: 
https://bugs.freedesktop.org/enter_bug.cgi?product=nice

Philip

> On Thu, Jun 25, 2015 at 2:52 AM, Philip Withnall <
> philip at tecnocode.co.uk> wrote:
> > Hey,
> > 
> > On Tue, 2015-06-23 at 21:09 +1200, Felix Schlitter wrote:
> > > I am wondering if it is possible to force libnice to ignore host
> > > candidates?
> > > I have a use case where I would like to test the connection 
> > locally
> > > on the
> > > same machine as if there were actually two machines involved:
> > *snip*
> > 
> > There is no API for this, but it’s a problem I’ve come across in 
> > the
> > past and I think it would be reasonable to add something. Patches
> > welcome!
> > 
> > The approach I vaguely had in mind is to allow the priority table 
> > to be
> > overridden by the user, with something like:
> > 
> >    void
> >    nice_agent_set_ice_priorities (NiceAgent *agent,
> >                                   const guint8 priorities[],
> >                                   guint n_priorities);
> > 
> > However, I do worry that this would be exposing too much of the
> > protocol innards in the public API. Your approach of selectively
> > eliding some of the candidates from the signalling between the 
> > peers is
> > potentially better, actually. Why do you think it’s a bad approach?
> > 
> > While I toyed with that priorities idea for a while, when I test 
> > with
> > libnice I actually implement this using iptables rules which block 
> > UDP
> > traffic on localhost. You can constrain the set of ports libnice
> > listens on if you want to make the rule more specific (use
> > nice_agent_set_port_range()).
> > 
> > > PS: It would be great to see this project hosted on github... 
> > using
> > > the mailing
> > > list is pretty off-putting - the search function does not seem to
> > > work, so I could not search
> > > if someone had asked sth like this before, unless I click 
> > manually
> > > through 5 years
> > > worth of threads... Also submitting pull requests would be a lot
> > > easier than attaching patches
> > > which may go stale. I would be happy to volunteer time to help 
> > this
> > > transition.
> > 
> > Good idea. GitHub project added:
> > 
> > https://github.com/libnice/libnice
> > 
> > I’ve also updated the website to link to Bugzilla and GitHub, since 
> > it
> > inexplicably wasn’t linked to Bugzilla before.
> > 
> > Note that while pull requests on GitHub are fine, I don’t think we 
> > want
> > to use GitHub’s issue tracking, or we’ll end up with bug reports 
> > there
> > and on Bugzilla, and everything will get very confusing.
> > 
> > Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/nice/attachments/20150625/1ad7ed92/attachment.sig>