<div dir="ltr">Thanks for the detailed reply Richard.<div>That does make total sense now. I'm going to dive into the CS source since it appears it's not following the RFC correctly.</div><div>No need to change the formula in RTPengine since it is following the RFC correctly. Makes more sense to fix the client.</div>
<div><br></div><div>Thanks again. Always good to learn something new every day.</div><div><br></div><div>Cheers,</div><div>Peter</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 6, 2014 at 7:39 PM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 07/06/14 08:32, Peter Villeneuve wrote:<br>
> Thanks Richard,<br>
><br>
> That does clear up some confusion on my end.<br>
><br>
</div>> /This is caused by the incorrect priorities of the other candidates.<br>
<div class="">> Rtpengine added itself as lowest possible priority "host" candidate,<br>
> which however is still a higher priority than the other candidates,<br>
</div>> because they have an incorrect(?) priority value./<br>
<div class="">><br>
> Hmm, if that were so, then shouldn't the rtpengine "host" priority be<br>
> smaller than the "true" host priority (let's leave the srflx aside for<br>
> the sake of clarity)?<br>
> You can see that 2130706432 is still higher priority than 1694498815,<br>
> which seems to suggest something even weirder is going on.<br>
><br>
> The clients I'm using are the latest nightly CSipSimple, and AFAIK<br>
> pjsip's ICE implementation follows the RFC, including the algo for<br>
> attributing priority.<br>
> Very strange indeed. I'm going to try and investigate this further, but<br>
> any hints or suggestions are very welcome.<br>
<br>
<br>
</div>The recommended formula from the RFC is:<br>
<br>
   priority = (2^24)*(type preference) +<br>
              (2^8)*(local preference) +<br>
              (2^0)*(256 - component ID)<br>
<br>
The type preference for host candidates is 126 and 100 for server<br>
reflexive. Local preference is 65535 for highest preference, 0 for<br>
lowest. So the primary host candidate should have a priority of<br>
(2^24)*126 + (2^8)*65535 + 256 = 2130706432, and the lowest priority<br>
host candidate would have (2^24)*126 + (2^8)*0 + 256 = 2113929472. So my<br>
last reply actually described things backwards, but the problem still<br>
remains: if you go with the recommended formula, even the lowest<br>
priority host candidate comes out with a higher priority than whatever<br>
CSipSimple is using. I have no idea how it comes up with 1694498815.<br>
<br>
As for the srflx one, highest priority would be (2^24)*100 + (2^8)*65535<br>
+ 256 = 1694498816, which is actually close to the priority of the host<br>
candidate. With a bit of playing around, it looks like CSipSimple uses a<br>
type priority of 110 for srflx and 100 for host candidates, which is not<br>
what the RFC recommends.<br>
<br>
In this case, the only way for rtpengine to insert itself with a lower<br>
priority is to deviate from the recommended formula. In itself that<br>
wouldn't be a problem, but I can't tell if and which side effects that<br>
would have.<br>
<div class="HOEnZb"><div class="h5"><br>
cheers<br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br></div>