[sr-dev] rtpengine ICE droppings

[Peter Villeneuve]

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 <rfuchs at sipwise.com> 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
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140706/61325470/attachment.html>