<div dir="ltr">Thanks Richard,<div><br></div><div>That does clear up some confusion on my end.</div><div><br></div><div><i><span style="font-family:arial,sans-serif;font-size:13px">This is caused by the incorrect priorities of the other candidates.</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">Rtpengine added itself as lowest possible priority "host" candidate,</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">which however is still a higher priority than the other candidates,</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">because they have an incorrect(?) priority value.</span></i><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><font color="#000000">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)?</font></div>
<div class="gmail_extra"><font color="#000000">You can see that <span style="font-family:arial,sans-serif;font-size:13px">2130706432 is still higher priority than </span><span style="font-family:arial,sans-serif;font-size:13px">1694498815, which seems to suggest something even weirder is going on.</span></font></div>
<div class="gmail_extra"><font face="arial, sans-serif" color="#000000"><br></font></div><div class="gmail_extra"><font face="arial, sans-serif" color="#000000">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.</font></div>
<div class="gmail_extra"><font face="arial, sans-serif" color="#000000">Very strange indeed. I'm going to try and investigate this further, but any hints or suggestions are very welcome.</font></div><div class="gmail_extra">
<font face="arial, sans-serif" color="#000000"><br></font></div><div class="gmail_extra"><font face="arial, sans-serif" color="#000000">Cheers,</font></div><div class="gmail_extra"><font face="arial, sans-serif"><font color="#000000">Peter</font><br>
</font><br><div class="gmail_quote">On Sat, Jul 5, 2014 at 8:50 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">On 07/05/14 15:27, Peter Villeneuve wrote:<br>
> Hmm, after experiencing some difficulty with a pjsip client that's<br>
> behind symmetric NAT, further inspection of its logs left me somewhat<br>
> confused.<br>
><br>
> Here's the relevant part of the logs of client behind symmetric NAT<br>
> receiving an INVITE<br>
><br>
> D/libpjsip(10600): a=candidate:Sc0a80104 1 UDP 1862270975 85.xx.xx.xx<br>
> 4016 typ srflx raddr 192.168.1.4 rport 4016<br>
> D/libpjsip(10600): a=candidate:Hc0a80104 1 UDP 1694498815 192.168.1.4<br>
> 4016 typ host<br>
> D/libpjsip(10600): a=candidate:Sc0a80104 2 UDP 1862270974 85.xx.xx.xx<br>
> 4032 typ srflx raddr 192.168.1.4 rport 4032<br>
> D/libpjsip(10600): a=candidate:Hc0a80104 2 UDP 1694498814 192.168.1.4<br>
> 4032 typ host<br>
> D/libpjsip(10600): a=sendrecv<br>
> D/libpjsip(10600): a=rtcp:30057<br>
> D/libpjsip(10600): a=candidate:VStiX9ltDBcGrfnS 1 UDP 2130706432<br>
> 190.xx.xx.xx 30056 typ host<br>
> D/libpjsip(10600): a=candidate:VStiX9ltDBcGrfnS 2 UDP 2130706431<br>
> 190.xx.xx.xx 30057 typ host<br>
><br>
><br>
> Now a few things here seem confusing to me.<br>
><br>
> 1) The rtpengine IP (190.) is added as a host candidate (shouldn't it be<br>
> relay instead?).<br>
<br>
</div>The type is "host" unless you use the "force_relay" option. Even though<br>
"host" is technically not correct, generally going through a dedicated<br>
RTP proxy is the next best thing after direct host to host<br>
communication, preferable to other relay methods determined by the peers.<br>
<div class=""><br>
> 2) The candidate priorities seem wrong. ie the local address is<br>
> correctly added as host, but isn't 1694498815 less than 1862270975?<br>
> meaning the srflx candidate has higher priority than the host candidate<br>
> if I understand the RFC correctly - shouldn't that be the other way around?<br>
<br>
</div>Correct. These candidates were inserted by the originating client and so<br>
there's nothing rtpengine can do about them. The priorities weren't<br>
calculated by the RFC recommended method and so seem incorrect.<br>
<div class=""><br>
> 3) The priority of the rtpengine candidate (190.) is 2130706432, which<br>
> again is greater than all the other priorities, meaning my rtpengine<br>
> relay will get the highest priority instead of the opposite.<br>
<br>
</div>This is caused by the incorrect priorities of the other candidates.<br>
Rtpengine added itself as lowest possible priority "host" candidate,<br>
which however is still a higher priority than the other candidates,<br>
because they have an incorrect(?) priority value.<br>
<br>
For your use case, you may have better luck with the "force_relay" option.<br>
<br>
cheers<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">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>