<div dir="ltr">Just to follow up, it seems you are correct in that PJSIP seems to reverse the priorities for host and srflx.<div>No clue why they do this, but it's a pain.</div><div><br></div><div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">
<br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><a href="http://svn.pjsip.org/repos/pjproject/trunk/pjnath/src/pjnath/ice_strans.c" target="_blank" style="margin:0px;padding:0px;border:0px;vertical-align:baseline;text-decoration:none;color:rgb(102,17,204)">http://svn.pjsip.org/repos/pjproject/trunk/pjnath/src/pjnath/ice_strans.c</a><br>
</div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px">
<br></div><div style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Arial,Helvetica,sans-serif;font-size:13px"><pre style="margin-top:0px;margin-bottom:0px;padding:0px;border:0px;vertical-align:baseline;color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">
/* The candidate type preference when STUN candidate is used */
static pj_uint8_t srflx_pref_table[PJ_ICE_CAND_TYPE_MAX] =
{
#if PJNATH_ICE_PRIO_STD
    100,    /**< PJ_ICE_HOST_PREF        */
    110,    /**< PJ_ICE_SRFLX_PREF       */
    126,    /**< PJ_ICE_PRFLX_PREF       */
    0       /**< PJ_ICE_RELAYED_PREF    */
#else
    /* Keep it to 2 bits */
    1,  /**< PJ_ICE_HOST_PREF            */
    2,  /**< PJ_ICE_SRFLX_PREF           */
    3,  /**< PJ_ICE_PRFLX_PREF           */
    0   /**< PJ_ICE_RELAYED_PREF    */
#endif
};</pre></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 6, 2014 at 7:51 PM, Peter Villeneuve <span dir="ltr"><<a href="mailto:petervnv1@gmail.com" target="_blank">petervnv1@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="HOEnZb"><div class="h5"><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>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>> 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>><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><div><br>
cheers<br>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">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>
</div></div></blockquote></div><br></div>