[sr-dev] rtpengine ICE droppings

[Peter Villeneuve]

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.

Cheers,
Peter

On Sat, Jul 5, 2014 at 8:50 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 07/05/14 15:27, Peter Villeneuve wrote:
> > Hmm, after experiencing some difficulty with a pjsip client that's
> > behind symmetric NAT, further inspection of its logs left me somewhat
> > confused.
> >
> > Here's the relevant part of the logs of client behind symmetric NAT
> > receiving an INVITE
> >
> > D/libpjsip(10600): a=candidate:Sc0a80104 1 UDP 1862270975 85.xx.xx.xx
> > 4016 typ srflx raddr 192.168.1.4 rport 4016
> > D/libpjsip(10600): a=candidate:Hc0a80104 1 UDP 1694498815 192.168.1.4
> > 4016 typ host
> > D/libpjsip(10600): a=candidate:Sc0a80104 2 UDP 1862270974 85.xx.xx.xx
> > 4032 typ srflx raddr 192.168.1.4 rport 4032
> > D/libpjsip(10600): a=candidate:Hc0a80104 2 UDP 1694498814 192.168.1.4
> > 4032 typ host
> > D/libpjsip(10600): a=sendrecv
> > D/libpjsip(10600): a=rtcp:30057
> > D/libpjsip(10600): a=candidate:VStiX9ltDBcGrfnS 1 UDP 2130706432
> > 190.xx.xx.xx 30056 typ host
> > D/libpjsip(10600): a=candidate:VStiX9ltDBcGrfnS 2 UDP 2130706431
> > 190.xx.xx.xx 30057 typ host
> >
> >
> > Now a few things here seem confusing to me.
> >
> > 1) The rtpengine IP (190.) is added as a host candidate (shouldn't it be
> > relay instead?).
>
> The type is "host" unless you use the "force_relay" option. Even though
> "host" is technically not correct, generally going through a dedicated
> RTP proxy is the next best thing after direct host to host
> communication, preferable to other relay methods determined by the peers.
>
> > 2) The candidate priorities seem wrong. ie the local address is
> > correctly added as host, but isn't 1694498815 less than 1862270975?
> > meaning the srflx candidate has higher priority than the host candidate
> > if I understand the RFC correctly - shouldn't that be the other way
> around?
>
> Correct. These candidates were inserted by the originating client and so
> there's nothing rtpengine can do about them. The priorities weren't
> calculated by the RFC recommended method and so seem incorrect.
>
> > 3) The priority of the rtpengine candidate (190.) is 2130706432, which
> > again is greater than all the other priorities, meaning my rtpengine
> > relay will get the highest priority instead of the opposite.
>
> 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.
>
> For your use case, you may have better luck with the "force_relay" option.
>
> 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/6e0b6363/attachment.html>