Just to follow up, it seems you are correct in that PJSIP seems to reverse the priorities for host and srflx. No clue why they do this, but it's a pain.
http://svn.pjsip.org/repos/pjproject/trunk/pjnath/src/pjnath/ice_strans.c /* 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 }; On Sun, Jul 6, 2014 at 7:51 PM, Peter Villeneuve <[email protected]> wrote: > Thanks for the detailed reply Richard. > 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. > No need to change the formula in RTPengine since it is following the RFC > correctly. Makes more sense to fix the client. > > Thanks again. Always good to learn something new every day. > > Cheers, > Peter > > > On Sun, Jul 6, 2014 at 7:39 PM, Richard Fuchs <[email protected]> wrote: > >> On 07/06/14 08:32, Peter Villeneuve wrote: >> > Thanks Richard, >> > >> > That does clear up some confusion on my end. >> > >> > /This is caused by the incorrect priorities of the other candidates. >> > Rtpengine added itself as lowest possible priority "host" candidate, >> > which however is still a higher priority than the other candidates, >> > because they have an incorrect(?) priority value./ >> > >> > Hmm, if that were so, then shouldn't the rtpengine "host" priority be >> > smaller than the "true" host priority (let's leave the srflx aside for >> > the sake of clarity)? >> > You can see that 2130706432 is still higher priority than 1694498815, >> > which seems to suggest something even weirder is going on. >> > >> > The clients I'm using are the latest nightly CSipSimple, and AFAIK >> > pjsip's ICE implementation follows the RFC, including the algo for >> > attributing priority. >> > Very strange indeed. I'm going to try and investigate this further, but >> > any hints or suggestions are very welcome. >> >> >> The recommended formula from the RFC is: >> >> priority = (2^24)*(type preference) + >> (2^8)*(local preference) + >> (2^0)*(256 - component ID) >> >> The type preference for host candidates is 126 and 100 for server >> reflexive. Local preference is 65535 for highest preference, 0 for >> lowest. So the primary host candidate should have a priority of >> (2^24)*126 + (2^8)*65535 + 256 = 2130706432, and the lowest priority >> host candidate would have (2^24)*126 + (2^8)*0 + 256 = 2113929472. So my >> last reply actually described things backwards, but the problem still >> remains: if you go with the recommended formula, even the lowest >> priority host candidate comes out with a higher priority than whatever >> CSipSimple is using. I have no idea how it comes up with 1694498815. >> >> As for the srflx one, highest priority would be (2^24)*100 + (2^8)*65535 >> + 256 = 1694498816, which is actually close to the priority of the host >> candidate. With a bit of playing around, it looks like CSipSimple uses a >> type priority of 110 for srflx and 100 for host candidates, which is not >> what the RFC recommends. >> >> In this case, the only way for rtpengine to insert itself with a lower >> priority is to deviate from the recommended formula. In itself that >> wouldn't be a problem, but I can't tell if and which side effects that >> would have. >> >> cheers >> >> _______________________________________________ >> sr-dev mailing list >> [email protected] >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> > >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
