Hi,
I found some existing topics on this but failed to get a solutions out of them.
We're running into some issues with client devices connecting to our private addresses. The way it is setup now:
CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) with RTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8)
Our Kamaialio and Asterisk are in a private address range, but Kamailio also has a public interface. Most of the clients (about 95%) work well with this setup, but a couple don't. We have one case now where the CLIENT tries to connect to the private address of ASTERISK. And of course, that doesn't work.
I'm kind of stuck as to where I need to fix this. I tried using the externaddr option in Asterisk to solve it on that end. But that didn't help anything. The NAT options in Kamailio are not really suited for this, as they tend to fix client NAT problems.
Any pointer or help would be greatly appriciated.
Cheers, Dirk
On Wednesday 30 September 2015 10:22:51 Dirk Teurlings - SIGNET B.V. wrote:
CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) withRTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8)
I'm kind of stuck as to where I need to fix this. I tried using the externaddr option in Asterisk to solve it on that end. But that didn't help anything. The NAT options in Kamailio are not really suited for this, as they tend to fix client NAT problems.
The asterisk doesn't need to know the network topology beyond its connection with kamailio, so you need to fix it at the place of traversal between public and private: kamailio.
On 30-09-15 11:10, Daniel Tryba wrote:
The asterisk doesn't need to know the network topology beyond its connection with kamailio, so you need to fix it at the place of traversal between public and private: kamailio.
Agreed, I was looking for a workaround at this point, but to no avail.
Cheers, Dirk
On Wednesday 30 September 2015 11:17:54 Dirk Teurlings - SIGNET B.V. wrote:
Agreed, I was looking for a workaround at this point, but to no avail.
A quick and dirty workaround might be the topoh module (which might break other things though).
On 30-09-15 11:28, Daniel Tryba wrote:
A quick and dirty workaround might be the topoh module (which might break other things though).
Already tried that as well, but that doesn't mask the private IP in the important places. It only hides them in the via and record-route headers.
Cheers, Dirk
Dirk, have you tried to grab some trace with with sngrep? Maybe you'll be able to figure out what's happening.
Regards, Bruno
2015-09-30 11:30 GMT+02:00 Dirk Teurlings - SIGNET B.V. < dteurlings@signet.nl>:
On 30-09-15 11:28, Daniel Tryba wrote:
A quick and dirty workaround might be the topoh module (which might break other things though).
Already tried that as well, but that doesn't mask the private IP in the important places. It only hides them in the via and record-route headers.
Cheers, Dirk
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 30 Sep 2015, at 11:10, Daniel Tryba d.tryba@pocos.nl wrote:
On Wednesday 30 September 2015 10:22:51 Dirk Teurlings - SIGNET B.V. wrote:
CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) withRTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8)
I'm kind of stuck as to where I need to fix this. I tried using the externaddr option in Asterisk to solve it on that end. But that didn't help anything. The NAT options in Kamailio are not really suited for this, as they tend to fix client NAT problems.
The asterisk doesn't need to know the network topology beyond its connection with kamailio, so you need to fix it at the place of traversal between public and private: kamailio.
Actually, if you turn on NAT support in Asterisk you should not need RTPproxy between clients and Asterisk. Only if two clients talk with each other without Asterisk RTPproxy is needed in the call. Adding RTPproxy in order to be able to move Asterisk to the private LAN seems like a good way to add latency to the call, which is usually not what you want. If Asterisk needs to be there for other reasons, you will need to check that the internal addresses are not sent out on the other side of Kamailio in the signalling.
/O
On 09/30/2015 04:22 AM, Dirk Teurlings - SIGNET B.V. wrote:
Hi,
CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) withRTPPROXY(v1) <-> PRIVATE LAN <-> ASTERISK (v1.8)
Any pointer or help would be greatly appriciated.
Cheers, Dirk
Are you using -A flag in rttproxy?
So, to bridge to outside from kamailio you'll need to use advertised address with public IP as well as -A flag in rtpproxy (I've been using either the @miconda patched version or 2.0).
Then on inside communications, you'll need to set rtpproxy (override) to use NAT/LAN IP, and use the public IP for the other side.
Something like...
if(dst_ip==ASTERISKIP) { rtpproxy_manage("co","PRIVATEIP"); } else { rtpproxy_manage("co"); }
Fred Posner The Palner Group, Inc. http://www.palner.com (web) +1-503-914-0999 (direct)
On 30-09-15 12:23, Fred Posner wrote:
Are you using -A flag in rttproxy?
Unfortunately we're running a version of RTPPROXY at the moment that doesn't have this flag. I'm considering upgrading to rtproxy 2.0, but will need to test whether this doesn't affect anything else.
It's preferred to find a solution without major changes to software(version). But if anything else fails I might need to...
Cheers, Dirk
Dirk, in case of a change, i would suggest to evaluate the use of rtpengine ( https://github.com/sipwise/rtpengine)
Regards, Bruno
2015-09-30 13:15 GMT+02:00 Dirk Teurlings - SIGNET B.V. < dteurlings@signet.nl>:
On 30-09-15 12:23, Fred Posner wrote:
Are you using -A flag in rttproxy?
Unfortunately we're running a version of RTPPROXY at the moment that doesn't have this flag. I'm considering upgrading to rtproxy 2.0, but will need to test whether this doesn't affect anything else.
It's preferred to find a solution without major changes to software(version). But if anything else fails I might need to...
Cheers, Dirk
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 09/30/2015 07:15 AM, Dirk Teurlings - SIGNET B.V. wrote:
On 30-09-15 12:23, Fred Posner wrote:
Are you using -A flag in rttproxy?
Unfortunately we're running a version of RTPPROXY at the moment that doesn't have this flag. I'm considering upgrading to rtproxy 2.0, but will need to test whether this doesn't affect anything else.
It's preferred to find a solution without major changes to software(version). But if anything else fails I might need to...
Cheers, Dirk
Without a version of rtpproxy using the -A flag, you'll need to either (1) update to a different version of rtpproxy or (2) skip rtpproxy and have your asterisk handle all the rtp.
Fred Posner The Palner Group, Inc. http://www.palner.com (web) +1-503-914-0999 (direct)
On 30-09-15 13:29, Fred Posner wrote:
Without a version of rtpproxy using the -A flag, you'll need to either (1) update to a different version of rtpproxy or (2) skip rtpproxy and have your asterisk handle all the rtp.
I tried rtpproxy v2, with the -A flag in bridge mode ( -A privateip/publicip ). This doesn't reflect anything in the SIP headers.
The problem is a bit more complex I think, because all INVITEs to gateways contain the same internal IPs from Asterisk and Kamaialio in their From and To header. SDP information is correctly being displayed. But it seems that some UAs disregard what's in the SDP descriptors and just look at the SIP headers (To/From/Contact).
Can anyone share their config snippets about how they've delt with the Asterisk behind NAT situation? It would really be appreciated!
Cheers, Dirk
If the SDP is correct, then you might have specific issues related to your specific deployment case. Snippets from others config files won't help. You really need to investigate and understand your particular issue that you are facing and fix it accordingly.
Regards, Ovidiu Sas On Oct 8, 2015 09:04, "Dirk Teurlings - SIGNET B.V." dteurlings@signet.nl wrote:
On 30-09-15 13:29, Fred Posner wrote:
Without a version of rtpproxy using the -A flag, you'll need to either (1) update to a different version of rtpproxy or (2) skip rtpproxy and have your asterisk handle all the rtp.
I tried rtpproxy v2, with the -A flag in bridge mode ( -A privateip/publicip ). This doesn't reflect anything in the SIP headers.
The problem is a bit more complex I think, because all INVITEs to gateways contain the same internal IPs from Asterisk and Kamaialio in their From and To header. SDP information is correctly being displayed. But it seems that some UAs disregard what's in the SDP descriptors and just look at the SIP headers (To/From/Contact).
Can anyone share their config snippets about how they've delt with the Asterisk behind NAT situation? It would really be appreciated!
Cheers, Dirk
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 10/08/2015 09:09 AM, Ovidiu Sas wrote:
If the SDP is correct, then you might have specific issues related to your specific deployment case. Snippets from others config files won't help. You really need to investigate and understand your particular issue that you are facing and fix it accordingly.
Regards, Ovidiu Sas
On Oct 8, 2015 09:04, "Dirk Teurlings - SIGNET B.V." <dteurlings@signet.nl mailto:dteurlings@signet.nl> wrote:
On 30-09-15 13:29, Fred Posner wrote: Without a version of rtpproxy using the -A flag, you'll need to either (1) update to a different version of rtpproxy or (2) skip rtpproxy and have your asterisk handle all the rtp. I tried rtpproxy v2, with the -A flag in bridge mode ( -A privateip/publicip ). This doesn't reflect anything in the SIP headers.
A is advertise which should be different from bridging, and not certain why you'd be in bridged mode. Are you using more than one nic?
Normally, for -A use something like:
rtpproxy -A PUBLICIP -F -l PRIVATEIP -m 10000 -M 55000 -s udp:*:7722 -d INFO
(the -d INFO will increase your logging)
If you continue to have trouble, I'd recommend you post an ngrep of the failure.
Fred Posner http://www.palner.com (web) +1-224-334-3733 (direct)
I struggled with this setup for a while using rtpproxy, i eventually went with rtpengine because it seems to have more features and is still maintained. I wrote a quick how-to (mostly for myself to remember) https://blog.voipxswitch.com/2015/08/11/rtpengine-with-kamailio-as-load-bala...
Here is the kamailio.cfg http://blog.voipxswitch.com/wp-content/uploads/2015/08/kamailio.cfg-rtpengin...
On Fri, Oct 9, 2015 at 8:50 AM, Fred Posner fred@palner.com wrote:
On 10/08/2015 09:09 AM, Ovidiu Sas wrote:
If the SDP is correct, then you might have specific issues related to your specific deployment case. Snippets from others config files won't help. You really need to investigate and understand your particular issue that you are facing and fix it accordingly.
Regards, Ovidiu Sas
On Oct 8, 2015 09:04, "Dirk Teurlings - SIGNET B.V." <dteurlings@signet.nl mailto:dteurlings@signet.nl> wrote:
On 30-09-15 13:29, Fred Posner wrote: Without a version of rtpproxy using the -A flag, you'll need to either (1) update to a different version of rtpproxy or (2) skip rtpproxy and have your asterisk handle all the rtp. I tried rtpproxy v2, with the -A flag in bridge mode ( -A privateip/publicip ). This doesn't reflect anything in the SIPheaders.
A is advertise which should be different from bridging, and not certain why you'd be in bridged mode. Are you using more than one nic?
Normally, for -A use something like:
rtpproxy -A PUBLICIP -F -l PRIVATEIP -m 10000 -M 55000 -s udp:*:7722 -d INFO
(the -d INFO will increase your logging)
If you continue to have trouble, I'd recommend you post an ngrep of the failure.
Fred Posner http://www.palner.com (web) +1-224-334-3733 (direct)
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
If the SDP is correct, then you might have specific issues related to your specific deployment case. Snippets from others config files won't help. You really need to investigate and understand your particular issue that you are facing and fix it accordingly.
Regards, Ovidiu Sas On Oct 8, 2015 09:04, "Dirk Teurlings - SIGNET B.V." dteurlings@signet.nl wrote:
On 30-09-15 13:29, Fred Posner wrote:
Without a version of rtpproxy using the -A flag, you'll need to either (1) update to a different version of rtpproxy or (2) skip rtpproxy and have your asterisk handle all the rtp.
I tried rtpproxy v2, with the -A flag in bridge mode ( -A privateip/publicip ). This doesn't reflect anything in the SIP headers.
The problem is a bit more complex I think, because all INVITEs to gateways contain the same internal IPs from Asterisk and Kamaialio in their From and To header. SDP information is correctly being displayed. But it seems that some UAs disregard what's in the SDP descriptors and just look at the SIP headers (To/From/Contact).
Can anyone share their config snippets about how they've delt with the Asterisk behind NAT situation? It would really be appreciated!
Cheers, Dirk
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
If you have kamailio bound to both private and public interfaces, then you need to run rtpproxy in bridge mode (vanilla rtpproxy). Another option is to get rid of the rtpproxy altogether and let asterisk handle the media, but you will need to make sure that: - kamailio is rewriting IPs in SDP provided by asterisk; - you perform port forwarding for the NATed RTP ports to asterisk.
Also, you need to be more specific about the client trying to connect to the private address of asterisk. Are you referring to media? In this case it seems that you didn't engage rtpproxy. Is it about signalling? Then you might deal with a bogus SIP client.
Take a look at other clients that are working and find out why this particular one doesn't work.
Regards, Ovidiu Sas
On Wed, Sep 30, 2015 at 4:22 AM, Dirk Teurlings - SIGNET B.V. dteurlings@signet.nl wrote:
Hi,
I found some existing topics on this but failed to get a solutions out of them.
We're running into some issues with client devices connecting to our private addresses. The way it is setup now:
CLIENTS <-> (NAT) <-> INTERNET <-> KAMAILIO(4.2.5) with RTPPROXY(v1)<-> PRIVATE LAN <-> ASTERISK (v1.8)
Our Kamaialio and Asterisk are in a private address range, but Kamailio also has a public interface. Most of the clients (about 95%) work well with this setup, but a couple don't. We have one case now where the CLIENT tries to connect to the private address of ASTERISK. And of course, that doesn't work.
I'm kind of stuck as to where I need to fix this. I tried using the externaddr option in Asterisk to solve it on that end. But that didn't help anything. The NAT options in Kamailio are not really suited for this, as they tend to fix client NAT problems.
Any pointer or help would be greatly appriciated.
Cheers, Dirk
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Bruno Salzano -
Daniel Tryba -
Dirk Teurlings - SIGNET B.V. -
Fred Posner -
Olle E. Johansson -
Ovidiu Sas -
Ovidiu Sas -
Vik Killa