[libnice] Ignore host candidates for testing

[Felix Schlitter]

> 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 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.

> 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.

> 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:

* Markdown - code blocks / fenced code blocks / highlighting - yes please
* Links to commits via shas
* Links to authors, using @mentions
* Links to other issues and pull requests using #123
* Close issues and pull requests using commit messages: "Closes #123"
* Potentially a lot more reports (*)
* ...

(*) I clicked the "bugzilla" link on the `nice.freedesktop.org/wiki`
<http://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?...

...Sorry Philip you received this mail twice, I realized I forgot to add
the mailing list address in the
recipients...

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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20150625/42593f95/attachment.html>