<div dir="ltr"><span class="im" style="font-size:12.8000001907349px">> <span style="font-size:12.8000001907349px">Why do you think it’s a bad approach?</span><div><span style="font-size:12.8000001907349px"><br></span></div></span><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">It just seemed like a pretty crude way of doing things, because I am just messing with the sdp string.</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Also, the candidate numbers are no longer sequential (not sure if that matters).</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Lastly, and most importantly - it does not work. Should it?</span></div><span class="im" style="font-size:12.8000001907349px"><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">I actually implement this using iptables rules which block UDP </span><span style="font-size:12.8000001907349px">traffic on localhost.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div></span><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Good idea, however it would still be great to somehow do this in-app to write integration tests a bit</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">easier. Messing with the environment to run tests does not  really resonate with me - Further, we<br></span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">are targeting Windows specifically.</span></div><span class="im" style="font-size:12.8000001907349px"><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">Good idea. GitHub project added</span></div><div><span style="font-size:12.8000001907349px"><br></span></div></span><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Awesome! Star added, fork created. I will have some pull requests coming your way soon to fix</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">compilation on windows.</span></div><span class="im" style="font-size:12.8000001907349px"><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> Note that while pull requests on GitHub are fine, I don’t think we want</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> to use GitHub’s issue tracking, or we’ll end up with bug reports there</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">> and on Bugzilla, and everything will get very confusing.</span><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div></span><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">This is up to you, but the issue list is essentially the mailing list AND the bug tracker in one. It is</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">a place for both feature suggestions and bug tracking (although can be used with external, more</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">formal </span><span style="font-size:12.8000001907349px">bug tracker - since github is pretty loose). I would highly suggest making the move, there</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">are not too many bugs reported and the transition would be easy. Here is what you get out of it:</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px"><br></span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">* Markdown - code blocks / fenced code blocks / highlighting - yes please</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">* Links to commits via shas</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">* Links to authors, using @mentions</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">* Links to other issues and pull requests using #123</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">* Close issues and pull requests using commit messages: "Closes #123"</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">* Potentially a lot more reports (*)</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">* ...</span></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">(*) I clicked the "bugzilla" link on the `<a href="http://nice.freedesktop.org/wiki" target="_blank">nice.freedesktop.org/wiki`</a> and it takes me to a sign up page.</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">From there I am puzzled as to where to click to see the list of already reported bugs.</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Ah I click the unseeming "reports" link, hm that takes me to another page without a listing, maybe I</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">click "search" on this page, nope, maybe I click "tabular chargs", nope... sigh. Back to the top row,</span></div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">maybe I click "browse"? That gets me the issues of all projects. How useful is that?...</span></div><div class="gmail_extra"><br></div><div class="gmail_extra">...Sorry Philip you received this mail twice, I realized I forgot to add the mailing list address in the</div><div class="gmail_extra">recipients...</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 25, 2015 at 2:52 AM, Philip Withnall <span dir="ltr"><<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<span class=""><br>
On Tue, 2015-06-23 at 21:09 +1200, Felix Schlitter wrote:<br>
> I am wondering if it is possible to force libnice to ignore host<br>
> candidates?<br>
> I have a use case where I would like to test the connection locally<br>
> on the<br>
> same machine as if there were actually two machines involved:<br>
</span>*snip*<br>
<br>
There is no API for this, but it’s a problem I’ve come across in the<br>
past and I think it would be reasonable to add something. Patches<br>
welcome!<br>
<br>
The approach I vaguely had in mind is to allow the priority table to be<br>
overridden by the user, with something like:<br>
<br>
   void<br>
   nice_agent_set_ice_priorities (NiceAgent *agent,<br>
                                  const guint8 priorities[],<br>
                                  guint n_priorities);<br>
<br>
However, I do worry that this would be exposing too much of the<br>
protocol innards in the public API. Your approach of selectively<br>
eliding some of the candidates from the signalling between the peers is<br>
potentially better, actually. Why do you think it’s a bad approach?<br>
<br>
While I toyed with that priorities idea for a while, when I test with<br>
libnice I actually implement this using iptables rules which block UDP<br>
traffic on localhost. You can constrain the set of ports libnice<br>
listens on if you want to make the rule more specific (use<br>
nice_agent_set_port_range()).<br>
<span class=""><br>
> PS: It would be great to see this project hosted on github... using<br>
> the mailing<br>
> list is pretty off-putting - the search function does not seem to<br>
> work, so I could not search<br>
> if someone had asked sth like this before, unless I click manually<br>
> through 5 years<br>
> worth of threads... Also submitting pull requests would be a lot<br>
> easier than attaching patches<br>
> which may go stale. I would be happy to volunteer time to help this<br>
> transition.<br>
<br>
</span>Good idea. GitHub project added:<br>
<br>
<a href="https://github.com/libnice/libnice" rel="noreferrer" target="_blank">https://github.com/libnice/libnice</a><br>
<br>
I’ve also updated the website to link to Bugzilla and GitHub, since it<br>
inexplicably wasn’t linked to Bugzilla before.<br>
<br>
Note that while pull requests on GitHub are fine, I don’t think we want<br>
to use GitHub’s issue tracking, or we’ll end up with bug reports there<br>
and on Bugzilla, and everything will get very confusing.<br>
<span class="HOEnZb"><font color="#888888"><br>
Philip</font></span></blockquote></div><br></div></div>