We don't want to use ICE. Is there any way to stop rtpengine from adding this to the SDP body?
a=ice-ufrag:5eI4YS1M a=ice-pwd:xHGuc5ksYWxv19jTcVpxBeIEqqJm a=candidate:0aynDMzbnaYfD3dW 1 UDP 2130706432 xxx.xxx.xxx.xxx 31318 typ host a=candidate:0aynDMzbnaYfD3dW 2 UDP 2130706431 xxx.xxx.xxx.xxx 31319 typ host
It unnecessarily bloats the SDP body and causes problems.
I see there's an ICE=remove option in the devel rtpengine module. Is there anything in the 4.1 rtpproxy-ng module?
On 07/03/2014 06:46 PM, Alex Balashov wrote:
On 07/03/2014 06:49 PM, Richard Fuchs wrote:
Danke schön!
How about with ice candidate priorities in ng? Is it the same as rtpproxy module with ice_candidate_priority_avp? I want my added ice candidates in rtpengine to have the lowest priority so relaying only happens if the peers can't directly communicate.
On Thu, Jul 3, 2014 at 11:50 PM, Alex Balashov abalashov@evaristesys.com 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?). 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? 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.
I must be either wrongly interpreting what's going on, or something in my basic kamailio with rtpengine install is wrong.
Any help?
Thanks
On Fri, Jul 4, 2014 at 12:13 PM, Peter Villeneuve petervnv1@gmail.com wrote:
On 07/05/14 15:27, Peter Villeneuve wrote:
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.
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.
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
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@sipwise.com wrote:
On 07/06/14 08:32, Peter Villeneuve wrote:
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
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@sipwise.com wrote:
Just to follow up, it seems you are correct in that PJSIP seems to reverse the priorities for host and srflx. No clue why they do this, but it's a pain.
http://svn.pjsip.org/repos/pjproject/trunk/pjnath/src/pjnath/ice_strans.c
/* 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 };
On Sun, Jul 6, 2014 at 7:51 PM, Peter Villeneuve petervnv1@gmail.com wrote:
Just recomplied rtpengine with your latest commit. Indeed it seems to be handling non-rfc-compliant host priorities much better.
D/libpjsip( 8663): a=candidate:Sc0a80104 1 UDP 1862270975 85.xx.xx.xx 4025 typ srflx raddr 192.168.1.4 rport 4025 D/libpjsip( 8663): a=candidate:Hc0a80104 1 UDP *1694498815* 192.168.1.4 4025 typ host D/libpjsip( 8663): a=candidate:Sc0a80104 2 UDP 1862270974 85.xx.xx.xx 4006 typ srflx raddr 192.168.1.4 rport 4006 D/libpjsip( 8663): a=candidate:Hc0a80104 2 UDP 1694498814 192.168.1.4 4006 typ host D/libpjsip( 8663): a=sendrecv D/libpjsip( 8663): a=rtcp:30009 D/libpjsip( 8663): a=candidate:Pi2sMxReBtxalHXF 1 UDP *1694498559* 190.xx.xx.xx 30008 typ host D/libpjsip( 8663): a=candidate:Pi2sMxReBtxalHXF 2 UDP 1694498558 190.xx.xx.xx 30009 typ host
Thanks for such a quick response.
Cheers, Peter
On Mon, Jul 7, 2014 at 2:17 PM, Richard Fuchs rfuchs@sipwise.com wrote:
Indeed, and as the original poster of this thread, I also would like to thank you, Richard, for your quick responses in general on rtpengine issues. You are very obliging.
-
Alex Balashov -
Juha Heinanen -
Peter Villeneuve -
Richard Fuchs