6 Jul
2014
6 Jul
'14
9:51 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev