On 07/03/2014 06:49 PM, Richard Fuchs wrote:

On 07/03/14 18:48, Alex Balashov wrote:

...

I see there's an ICE=remove option in the devel rtpengine module. Is there anything in the 4.1 rtpproxy-ng module?

The '-' flag should do the same.

Danke schön!

On 07/03/14 20:53, Peter Villeneuve wrote:

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.

That's the default behaviour: it adds itself as lowest-priority candidate.

cheers

Thanks guys

On Fri, Jul 4, 2014 at 7:36 AM, Juha Heinanen jh@tutpro.com wrote:

Peter Villeneuve writes:

...

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.

you can use ICE=force_relay if you want to keep the existing non-relay candidates.

-- juha

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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

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

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:

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:

...

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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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:

On 07/06/14 15:44, Peter Villeneuve 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.

FWIW, I've just pushed a commit which should allow rtpengine to deal with situations like this better.

cheers

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev