/* 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
};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,PeterOn Sun, Jul 6, 2014 at 7:39 PM, Richard Fuchs <rfuchs@sipwise.com> wrote:
On 07/06/14 08:32, Peter Villeneuve wrote:> /This is caused by the incorrect priorities of the other candidates.
> Thanks Richard,
>
> That does clear up some confusion on my end.
>
> Rtpengine added itself as lowest possible priority "host" candidate,> because they have an incorrect(?) priority value./
> which however is still a higher priority than the other candidates,
>The recommended formula from the RFC is:
> 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.
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
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev