4 Jul
2014
4 Jul
'14
1:46 a.m.
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.
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
4 Jul
4 Jul
1:48 a.m.
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:
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.
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
1:50 a.m.
On 07/03/2014 06:49 PM, Richard Fuchs wrote:
On 07/03/14 18:48, Alex Balashov wrote:
Danke schön!
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
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. 
3:53 a.m.
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(a)evaristesys.com>
wrote:
On 07/03/2014 06:49 PM, Richard Fuchs wrote:
On 07/03/14 18:48, Alex Balashov wrote:
Danke schön!
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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.
3:57 a.m.
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
9:36 a.m.
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
2:13 p.m.
Thanks guys
On Fri, Jul 4, 2014 at 7:36 AM, Juha Heinanen <jh(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
5 Jul
5 Jul
10:27 p.m.
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(a)gmail.com>
wrote:
Thanks guys
On Fri, Jul 4, 2014 at 7:36 AM, Juha Heinanen <jh(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
10:50 p.m.
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
6 Jul
6 Jul
3:32 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:39 p.m.
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
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
10:44 p.m.
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(a)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(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
7 Jul
7 Jul
4:17 p.m.
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
8 Jul
8 Jul
5:36 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
6:43 p.m.
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 - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
3820
days inactive
3825
days old
16 comments
4 participants
participants (4)
-
Alex Balashov -
Juha Heinanen -
Peter Villeneuve -
Richard Fuchs