Re: [SR-Users] RR balance kamailio
Sorry, diagram e-mail also slipped. The truth is as follows.
Voip-ISP --- (ip_trunk-udp) --- Kamailio ---(balance-rr)--- sip1/2
On Sun, Jan 16, 2022 at 9:46 AM Gokan Atmaca wrote:
>
> Hello
>
> Thanks for the answer. Kamailio and I have two sip servers. Kamailio
> regularly health checks both servers.
> I entered a rule as follows for incoming invitation messages. When I
> receive a call, I get a 404 error.
> What could be the problem? What should the Kamailio topology be like?
>
> I understand as below. Is this true?
>
> Asterisks-udp-1
>
> /
> Voip-ISP --- (ip_trunk-udp) --- Kamailio ---(balance-rr)---
>
> \
>
> Asterisk-udp-2
>
> -% Log:
> 09:35:22.454828 IP 78.X.X.X.5060 > 157.X.X.X.5060: SIP: INVITE
> sip:902X.X.X.@157.X.X.X.X:5060 SIP/2.0
> 09:35:22.456939 IP 157.X.X.X..5060 > 78.X.X.X.5060: SIP: SIP/2.0 404 Not Found
> 09:35:22.515906 IP 78.X.X.X.X.5060 > 157.X.X.X.X.5060: SIP: ACK
> sip:902X.X.X.X@157.X.X.X:5060 SIP/2.0
>
> -% Kamailio_rule:
>
> route[DISPATCH] {
> if(method=="INVITE")
>xlog("ben bir komandoyum");
> ds_select_dst("1","4");
> sl_send_reply("100","Trying");
> forward();
> exit();
> }
>
> On Thu, Jan 13, 2022 at 9:37 AM Henning Westerholt wrote:
> >
> > Hello,
> >
> > the log you've quoted below is not an error log. The first part "INFO"
> > indicates that is is an informational message. If it would be an error, it
> > would indicate "ERROR". So you can ignore it if you do not need the
> > outbound module (probably not).
> >
> > Err_log:
> > Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]: INFO: rr
> > [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe
> > module is not loaded Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]:
> > INFO: rr
> > [rr_mod.c:188]: mod_init(): outbound module not available
> >
> > Cheers,
> >
> > Henning
> >
> > --
> > Henning Westerholt – https://skalatan.de/blog/
> > Kamailio services – https://gilawa.com
> >
> > -Original Message-
> > From: sr-users On Behalf Of Gokan
> > Atmaca
> > Sent: Wednesday, January 12, 2022 9:52 PM
> > To: sr-users@lists.kamailio.org
> > Subject: [SR-Users] RR balance kamailio
> >
> > Hello
> >
> > I installed kamailio on Ubuntu. The version information is as follows.
> > (0) I added two dispatcher sip servers. (1) When I enter the parameter as
> > below in the configuration file , I get an error as follows. (2) I am
> > getting RR module not available error. Packages installed are
> > "kamailio-berkeley-modules, kamailio-tls-modules, kamailio-presence-modules"
> >
> > How can I solve the problem?
> >
> > (0) version:
> > version: kamailio 5.5.3 (x86_64/linux)
> > flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
> > USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
> > TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> > USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
> > HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024,
> > MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT
> > PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt,
> > select.
> > id: unknown
> > compiled with gcc 9.3.0
> >
> > (1) Dispatcher list:
> >
> > {
> > NRSETS: 1
> > RECORDS: {
> > SET: {
> > ID: 1
> > TARGETS: {
> > DEST: {
> > URI: sip:X.X.X.X
> > FLAGS: AP
> > PRIORITY: 0
> > LATENCY: {
> > AVG: 0.00
> > STD: 0.00
> > EST: 0.00
> > MAX: 0
> > TIMEOUT: 0
> > }
> > }
> > DEST: {
> > URI: sip:Y.Y.Y.Y
> > FLAGS: AP
> > PRIORITY: 0
> > LATENCY: {
> > AVG: 0.00
> > STD: 0.00
> > EST: 0.00
> > MAX: 0
> > TIMEOUT: 0
> > }
> > }
> > }
> > }
> > }
> > }
> >
> >
> > (2)
> >
> > if ( method=="INVITE" ) {
> > ds_select_dst("1","4");
> > sl_send_reply("100","Trying");
> > forward();
> > exit();
> > }
> >
> > Err_log:
> > Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]: INFO: rr
> > [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe
> > module is not loaded Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]:
> > INFO: rr
> > [rr_mod.c:188]: mod_init(): outbound module not available
> >
> > --
> > ⢀⣴⠾⠻⢶⣦⠀
> > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀
> > https://www.debian.org ⠈⠳⣄
> >
> > __
> > Kamailio -
Re: [SR-Users] RR balance kamailio
Hello
Thanks for the answer. Kamailio and I have two sip servers. Kamailio
regularly health checks both servers.
I entered a rule as follows for incoming invitation messages. When I
receive a call, I get a 404 error.
What could be the problem? What should the Kamailio topology be like?
I understand as below. Is this true?
Asterisks-udp-1
/
Voip-ISP --- (ip_trunk-udp) --- Kamailio ---(balance-rr)---
\
Asterisk-udp-2
-% Log:
09:35:22.454828 IP 78.X.X.X.5060 > 157.X.X.X.5060: SIP: INVITE
sip:902X.X.X.@157.X.X.X.X:5060 SIP/2.0
09:35:22.456939 IP 157.X.X.X..5060 > 78.X.X.X.5060: SIP: SIP/2.0 404 Not Found
09:35:22.515906 IP 78.X.X.X.X.5060 > 157.X.X.X.X.5060: SIP: ACK
sip:902X.X.X.X@157.X.X.X:5060 SIP/2.0
-% Kamailio_rule:
route[DISPATCH] {
if(method=="INVITE")
xlog("ben bir komandoyum");
ds_select_dst("1","4");
sl_send_reply("100","Trying");
forward();
exit();
}
On Thu, Jan 13, 2022 at 9:37 AM Henning Westerholt wrote:
>
> Hello,
>
> the log you've quoted below is not an error log. The first part "INFO"
> indicates that is is an informational message. If it would be an error, it
> would indicate "ERROR". So you can ignore it if you do not need the outbound
> module (probably not).
>
> Err_log:
> Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]: INFO: rr
> [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe
> module is not loaded Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]:
> INFO: rr
> [rr_mod.c:188]: mod_init(): outbound module not available
>
> Cheers,
>
> Henning
>
> --
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com
>
> -Original Message-
> From: sr-users On Behalf Of Gokan Atmaca
> Sent: Wednesday, January 12, 2022 9:52 PM
> To: sr-users@lists.kamailio.org
> Subject: [SR-Users] RR balance kamailio
>
> Hello
>
> I installed kamailio on Ubuntu. The version information is as follows.
> (0) I added two dispatcher sip servers. (1) When I enter the parameter as
> below in the configuration file , I get an error as follows. (2) I am getting
> RR module not available error. Packages installed are
> "kamailio-berkeley-modules, kamailio-tls-modules, kamailio-presence-modules"
>
> How can I solve the problem?
>
> (0) version:
> version: kamailio 5.5.3 (x86_64/linux)
> flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
> USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
> TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
> HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024,
> MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT
> PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
> id: unknown
> compiled with gcc 9.3.0
>
> (1) Dispatcher list:
>
> {
> NRSETS: 1
> RECORDS: {
> SET: {
> ID: 1
> TARGETS: {
> DEST: {
> URI: sip:X.X.X.X
> FLAGS: AP
> PRIORITY: 0
> LATENCY: {
> AVG: 0.00
> STD: 0.00
> EST: 0.00
> MAX: 0
> TIMEOUT: 0
> }
> }
> DEST: {
> URI: sip:Y.Y.Y.Y
> FLAGS: AP
> PRIORITY: 0
> LATENCY: {
> AVG: 0.00
> STD: 0.00
> EST: 0.00
> MAX: 0
> TIMEOUT: 0
> }
> }
> }
> }
> }
> }
>
>
> (2)
>
> if ( method=="INVITE" ) {
> ds_select_dst("1","4");
> sl_send_reply("100","Trying");
> forward();
> exit();
> }
>
> Err_log:
> Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]: INFO: rr
> [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe
> module is not loaded Jan 12 12:15:11 kamailio /usr/sbin/kamailio[21241]:
> INFO: rr
> [rr_mod.c:188]: mod_init(): outbound module not available
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀
> https://www.debian.org ⠈⠳⣄
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do
Re: [SR-Users] Help with rewriting headers for NAT manually
Ok so in short I was not doing anything wrong (although I had some miss-configurations), but the carrier is (i.e. they are a bad actor). When they said I was doing it wrong, they did not mean in the RFC sense they meant in the "to work with us" sense. Now in order for me to get it to work with their SBC I have to mangle the contact on the way out an unmangle it on the return in Kamailio somehow, as I originally purposed. However I have no idea how to do that :) Shouldn't we (the Kamailio community) assume there are lots of bad actors out there and possibly many Kamailio users with this exact same issue (I personally know of at least 2 bad actor carriers right now) and create some kind of template or snippet that we can publicly publish on the Kamailio docs or wiki for all of the Kamailio community to use for this use case? I have been fighting with carriers about this for years and they always said I was doing it wrong and I don't know the SIP RFC well enough to fight back. So why not build a solution for everyone out there that has to deal with a bad actor? -- ^C On 1/15/22 11:40 AM, Ovidiu Sas wrote: As expected, your carrier is bogus and "thinks" it knows better. Your carrier is treating your setup as a dumb endpoint and is re-writing the Contact header: You provide this contact header in 200 OK: Contact: The carrier should set the RURI in ACK like this: ACK sip:928###@10.###.###.104:5060 SIP/2.0 Instead, your ACK is sent to you like this: ACK sip:928###@209.###.###.###:5060 SIP/2.0 The RURI in ACK should point to the private IP of the asterisk server, not to the public IP of the kamailio server. You need to ask the carrier to follow the SIP RFC and not treat your endpoints like dumb SIP endpoints. There's a high chance that they won't do it :) Your best chance is to manually mangle the URI in Contact in the 200 OK in a way that when you receive the ACK with the mangled RURI, you can restore the original URI and let kamailio do the proper routing to the private IP of the asterisk serverr. You should be able to achieve this by using one of the following functions: https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode Regards, Ovidiu Sas On Sat, Jan 15, 2022 at 1:28 PM Chad wrote: I changed the listen per your advice and here is the 200 and ACK. I get no audio and the the call disconnects and I see this is the Asterisk log: [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout reached on transmission 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 6401ms with no response [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 - no reply to our critical packet (see https://wiki.asterisk.org/wik FYI 10.###.###.254 is the private virtual IP on the Kamailio server and 10.###.###.104 is the asterisk box. SIP/2.0 200 OK Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0 Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1 Record-Route: Record-Route: Record-Route: From: "Anonymous" ;tag=as04035ef0 To: ;tag=as7047ed05 Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 CSeq: 102 INVITE Server: Asterisk PBX 16.18.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: Content-Type: application/sdp Content-Length: 274 v=0 o=root 1911037741 1911037741 IN IP4 209.###.###.### s=Asterisk PBX 16.18.0 c=IN IP4 209.###.###.### t=0 0 m=audio 11384 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv a=nortpproxy:yes ACK sip:928###@209.###.###.###:5060 SIP/2.0 Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2 Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1 Max-Forwards: 67 From: "Anonymous" ;tag=as04035ef0 To: ;tag=as7047ed05 Contact: Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 CSeq: 102 ACK User-Agent: packetrino Content-Length: 0 Route: Route: -- ^C On 1/15/22 10:21 AM, Ovidiu Sas wrote: This is false. The IP in the Contact header must be routable by the SIP hop from the top Record-Route header in the reply. The carrier (and it seems that they have a PROXY also) must be able to route to their adjacent SIP hop, which is your public IP (the IP in the second Record-Route header). It seems that the carrier is not taking into account that they might interface with other proxies. Most likely, your carrier expects to interface with a simple SIP
Re: [SR-Users] Issues running mongodb command from kamailio
All,
Issue resolved. It must have been my notepad application added some
invisible characters to my command. I did a regular copy and paste from the
tutorial and changed the parameters as needed and all is well now.
Thanks
On Fri, Jan 14, 2022 at 11:25 AM Edo wrote:
>
> The lines are
>
> #Start of change
>
> Line 878if (mongodb_find_one("mongodbsrv1", “telephone", “cXXX", " {
> \'did\': \'2X\' } ", "mgr1")) {
>
> Line 879 xlog("response from mongodb is
> [[$mongodb(mgr1=>value)]]\n");
>
>}
>
> #End of change
>
>
>
> On Thu, Jan 13, 2022 at 12:42 AM Henning Westerholt wrote:
>
>> Hello,
>>
>>
>>
>> which lines are the line 878 and 879, reported in the error message in
>> your cfg?
>>
>>
>>
>> Try to simplify this line, e.g., by removing or substitute some
>> parameters or function calls to find out the cause.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Henning
>>
>>
>>
>> --
>>
>> Henning Westerholt – https://skalatan.de/blog/
>>
>> Kamailio services – https://gilawa.com
>>
>>
>>
>> *From:* sr-users *On Behalf Of *Edo
>> *Sent:* Thursday, January 13, 2022 6:27 AM
>> *To:* Kamailio (SER) - Users Mailing List
>> *Subject:* [SR-Users] Issues running mongodb command from kamailio
>>
>>
>>
>> Hi All,
>>
>>
>>
>> Please help!
>>
>> I am getting an error when trying to start kamailio after making some
>> changes to the configuration file.
>>
>>
>>
>> Error is :
>>
>>
>>
>> *rse error in config file /etc/kamailio/kamailio.cfg, line 878, column
>> 47-57: '('')' expected (function call)*
>>
>>
>>
>> *rse error in config file /etc/kamailio/kamailio.cfg, line 878, column
>> 102: bad expression*
>>
>>
>>
>> *rse error in config file /etc/kamailio/kamailio.cfg, line 878, column
>> 102: bad command*
>>
>>
>>
>> *atus=255/EXCEPTION*
>>
>>
>>
>> *rse error in config file /etc/kamailio/kamailio.cfg, line 878, column
>> 103: bad command*
>>
>>
>>
>> *rse error in config file /etc/kamailio/kamailio.cfg, line 878, column
>> 105: bad command*
>>
>> * used inside params of another function: xlog*
>>
>>
>>
>> *rse error in config file /etc/kamailio/kamailio.cfg, line 879, column
>> 28: use of function execution inside params not allowed*
>>
>>
>>
>> *Server.*
>>
>> Changes made is :
>>
>>
>>
>> # Routing to foreign domains
>>
>>
>>
>> route[SIPOUT] {
>>
>>
>>
>> if (uri==myself) return;
>>
>>
>>
>> #Start of change
>>
>>
>>
>> if (mongodb_find_one("mongodbsrv1", “telephone", “cXXX", " {
>> \'did\': \'2X\' } ", "mgr1")) {
>>
>>
>>
>>xlog("response from mongodb is
>> [[$mongodb(mgr1=>value)]]\n");
>>
>>
>>
>>}
>>
>> #End of change
>>
>>
>>
>> append_hf("P-hint: outbound\r\n");
>>
>>
>>
>> route(RELAY);
>>
>>
>>
>> exit;
>>
>>
>>
>> }
>>
>> Please can someone tell me what I am doing wrong. Error says syntax but I
>> have tried many permutations of the suggested syntax with no luck.
>>
>>
>>
>> Please help
>>
>>
>>
>> Thanks
>>
>> --
>>
>> -
>>
>> Ekunwe
>> EDO Network Services, Inc.
>> Tel: 601.497.3932
>>
>
>
> --
> -
> Ekunwe
> EDO Network Services, Inc.
> Tel: 601.497.3932
> Fax: 601.979.5931
>
--
-
Ekunwe
EDO Network Services, Inc.
Tel: 601.497.3932
Fax: 601.979.5931
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Help with rewriting headers for NAT manually
As expected, your carrier is bogus and "thinks" it knows better. Your carrier is treating your setup as a dumb endpoint and is re-writing the Contact header: You provide this contact header in 200 OK: Contact: The carrier should set the RURI in ACK like this: ACK sip:928###@10.###.###.104:5060 SIP/2.0 Instead, your ACK is sent to you like this: ACK sip:928###@209.###.###.###:5060 SIP/2.0 The RURI in ACK should point to the private IP of the asterisk server, not to the public IP of the kamailio server. You need to ask the carrier to follow the SIP RFC and not treat your endpoints like dumb SIP endpoints. There's a high chance that they won't do it :) Your best chance is to manually mangle the URI in Contact in the 200 OK in a way that when you receive the ACK with the mangled RURI, you can restore the original URI and let kamailio do the proper routing to the private IP of the asterisk serverr. You should be able to achieve this by using one of the following functions: https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode Regards, Ovidiu Sas On Sat, Jan 15, 2022 at 1:28 PM Chad wrote: > > I changed the listen per your advice and here is the 200 and ACK. > I get no audio and the the call disconnects and I see this is the Asterisk > log: > [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout reached > on transmission > 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 for seqno 102 (Critical > Response) -- See > https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > Packet timed out after 6401ms with no response > [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call > 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 - no > reply to our critical packet (see https://wiki.asterisk.org/wik > > FYI 10.###.###.254 is the private virtual IP on the Kamailio server and > 10.###.###.104 is the asterisk box. > > SIP/2.0 200 OK > Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0 > Via: SIP/2.0/UDP > 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1 > Record-Route: > Record-Route: > Record-Route: > From: "Anonymous" ;tag=as04035ef0 > To: ;tag=as7047ed05 > Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 > CSeq: 102 INVITE > Server: Asterisk PBX 16.18.0 > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE > Supported: replaces, timer > Contact: > Content-Type: application/sdp > Content-Length: 274 > > v=0 > o=root 1911037741 1911037741 IN IP4 209.###.###.### > s=Asterisk PBX 16.18.0 > c=IN IP4 209.###.###.### > t=0 0 > m=audio 11384 RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=ptime:20 > a=maxptime:150 > a=sendrecv > a=nortpproxy:yes > > ACK sip:928###@209.###.###.###:5060 SIP/2.0 > Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2 > Via: SIP/2.0/UDP > 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1 > Max-Forwards: 67 > From: "Anonymous" ;tag=as04035ef0 > To: ;tag=as7047ed05 > Contact: > Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 > CSeq: 102 ACK > User-Agent: packetrino > Content-Length: 0 > Route: > Route: > > > -- > ^C > > > On 1/15/22 10:21 AM, Ovidiu Sas wrote: > > This is false. The IP in the Contact header must be routable by the > > SIP hop from the top Record-Route header in the reply. > > The carrier (and it seems that they have a PROXY also) must be able to > > route to their adjacent SIP hop, which is your public IP (the IP in > > the second Record-Route header). > > It seems that the carrier is not taking into account that they might > > interface with other proxies. > > Most likely, your carrier expects to interface with a simple SIP UA, > > not with another proxy. This is a pretty common setup for most of the > > carriers, although many new carrier implementations are taking care of > > the proxy to proxy calls. > > > > It would be helpful to see the ACK that is sent by the carrier in > > response to your 200ok (after you fix your config and you have your > > private IP listed in the Record-Route header). > > > > -ovidiu > > > > On Sat, Jan 15, 2022 at 12:33 PM Chad wrote: > >> > >> Hmm, I don't think you are right that the Contact header can be a private > >> IP even if the RR is correct. > >> I did some research on it and I found several places saying it must be a > >> routable IP which is what the carrier also said. > >> > >> "The Contact header contains the SIP URI where the client wants to be > >> contacted for subsequent requests. That means that > >> the host part of the URI must be globally reachable by anyone. > >> If your contact contains a private IP (behind a NAT?) then
Re: [SR-Users] Help with rewriting headers for NAT manually
I changed the listen per your advice and here is the 200 and ACK. I get no audio and the the call disconnects and I see this is the Asterisk log: [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout reached on transmission 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 for seqno 102 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 6401ms with no response [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 - no reply to our critical packet (see https://wiki.asterisk.org/wik FYI 10.###.###.254 is the private virtual IP on the Kamailio server and 10.###.###.104 is the asterisk box. SIP/2.0 200 OK Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0 Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1 Record-Route: Record-Route: Record-Route: From: "Anonymous" ;tag=as04035ef0 To: ;tag=as7047ed05 Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 CSeq: 102 INVITE Server: Asterisk PBX 16.18.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: Content-Type: application/sdp Content-Length: 274 v=0 o=root 1911037741 1911037741 IN IP4 209.###.###.### s=Asterisk PBX 16.18.0 c=IN IP4 209.###.###.### t=0 0 m=audio 11384 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv a=nortpproxy:yes ACK sip:928###@209.###.###.###:5060 SIP/2.0 Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2 Via: SIP/2.0/UDP 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1 Max-Forwards: 67 From: "Anonymous" ;tag=as04035ef0 To: ;tag=as7047ed05 Contact: Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060 CSeq: 102 ACK User-Agent: packetrino Content-Length: 0 Route: Route: -- ^C On 1/15/22 10:21 AM, Ovidiu Sas wrote: This is false. The IP in the Contact header must be routable by the SIP hop from the top Record-Route header in the reply. The carrier (and it seems that they have a PROXY also) must be able to route to their adjacent SIP hop, which is your public IP (the IP in the second Record-Route header). It seems that the carrier is not taking into account that they might interface with other proxies. Most likely, your carrier expects to interface with a simple SIP UA, not with another proxy. This is a pretty common setup for most of the carriers, although many new carrier implementations are taking care of the proxy to proxy calls. It would be helpful to see the ACK that is sent by the carrier in response to your 200ok (after you fix your config and you have your private IP listed in the Record-Route header). -ovidiu On Sat, Jan 15, 2022 at 12:33 PM Chad wrote: Hmm, I don't think you are right that the Contact header can be a private IP even if the RR is correct. I did some research on it and I found several places saying it must be a routable IP which is what the carrier also said. "The Contact header contains the SIP URI where the client wants to be contacted for subsequent requests. That means that the host part of the URI must be globally reachable by anyone. If your contact contains a private IP (behind a NAT?) then it is wrong, because other peers cannot reach you with that." -- ^C On 1/15/22 9:05 AM, Ovidiu Sas wrote: You have a different problem then. Having private IPs in Contact is fine. You need to lose route the calls (kamailio will add two Record-Route headers) and the origination server will set the RURI to the private IP from Contact, but it will send the in-dialog requests to the public IP of kamailio. This has nothing to do with virtual IPs. Maybe you have a buggy client that doesn't do proper loose routing. -ovidiu On Sat, Jan 15, 2022 at 11:50 AM Chad wrote: Ovidiu, Thank you again for your response. One is public (an internet IP) and one is private (a 10.x ip). Apparently this is a known problem with virtual IPs, it does not work. When the asterisk server responds to the invite it sends a contact header with the private IP and Kamailio does not rewrite it to the advertised public IP. So the originating server sees the private IP in the Contact header and tries to send the traffic to the 10.x IP (which is non-routable) and the call dies. I have been trying things for a long time to fix this (years) what you are saying will not fix it because of the virtual IPs. If it was a normal IP it would work fine. It has something to do with the routing table and how mhomed detects networks. -- ^C On 1/15/22 8:36 AM, Ovidiu Sas wrote: Hello Chad, The floating IPs that you have, are they both private IPs or one private IP and the other one a public IP? If you have to two floating private IPs, then you need a config like this:
Re: [SR-Users] Help with rewriting headers for NAT manually
This is false. The IP in the Contact header must be routable by the
SIP hop from the top Record-Route header in the reply.
The carrier (and it seems that they have a PROXY also) must be able to
route to their adjacent SIP hop, which is your public IP (the IP in
the second Record-Route header).
It seems that the carrier is not taking into account that they might
interface with other proxies.
Most likely, your carrier expects to interface with a simple SIP UA,
not with another proxy. This is a pretty common setup for most of the
carriers, although many new carrier implementations are taking care of
the proxy to proxy calls.
It would be helpful to see the ACK that is sent by the carrier in
response to your 200ok (after you fix your config and you have your
private IP listed in the Record-Route header).
-ovidiu
On Sat, Jan 15, 2022 at 12:33 PM Chad wrote:
>
> Hmm, I don't think you are right that the Contact header can be a private IP
> even if the RR is correct.
> I did some research on it and I found several places saying it must be a
> routable IP which is what the carrier also said.
>
> "The Contact header contains the SIP URI where the client wants to be
> contacted for subsequent requests. That means that
> the host part of the URI must be globally reachable by anyone.
> If your contact contains a private IP (behind a NAT?) then it is wrong,
> because other peers cannot reach you with that."
>
>
> --
> ^C
>
>
> On 1/15/22 9:05 AM, Ovidiu Sas wrote:
> > You have a different problem then.
> > Having private IPs in Contact is fine. You need to lose route the
> > calls (kamailio will add two Record-Route headers) and the origination
> > server will set the RURI to the private IP from Contact, but it will
> > send the in-dialog requests to the public IP of kamailio. This has
> > nothing to do with virtual IPs.
> > Maybe you have a buggy client that doesn't do proper loose routing.
> >
> > -ovidiu
> >
> > On Sat, Jan 15, 2022 at 11:50 AM Chad wrote:
> >>
> >> Ovidiu,
> >> Thank you again for your response.
> >> One is public (an internet IP) and one is private (a 10.x ip).
> >> Apparently this is a known problem with virtual IPs, it does not work.
> >> When the asterisk server responds to the invite it sends a contact header
> >> with the private IP and Kamailio does not
> >> rewrite it to the advertised public IP. So the originating server sees the
> >> private IP in the Contact header and tries to
> >> send the traffic to the 10.x IP (which is non-routable) and the call dies.
> >> I have been trying things for a long time to fix this (years) what you are
> >> saying will not fix it because of the virtual
> >> IPs.
> >> If it was a normal IP it would work fine. It has something to do with the
> >> routing table and how mhomed detects networks.
> >>
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> >>> Hello Chad,
> >>>
> >>> The floating IPs that you have, are they both private IPs or one
> >>> private IP and the other one a public IP?
> >>>
> >>> If you have to two floating private IPs, then you need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> >>> listen=FLOATING_UDP_PRIVATE2
> >>>
> >>> In the config, before relaying the initial INVITE you need to detect
> >>> the direction of the call and set $fs accordingly:
> >>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {
> >>> $fs = udp:FLOATING_UDP_PRIVATE1
> >>> }
> >>> else {
> >>> $fs = udp:FLOATING_UDP_PRIVATE2
> >>> }
> >>>
> >>> If you have a floating private IPs and a floating public IP, then you
> >>> need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE
> >>> listen=FLOATING_UDP_PUBLIC
> >>>
> >>> There should be no need to force the socket, but if you do, there's no
> >>> harm (actually it's better and faster).
> >>>
> >>> Hope this clarifies things and helps,
> >>> -ovidiu
> >>>
> >>> On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
>
> Ovidiu,
> Thank you for your response.
>
> I have done that, in addition to the linux ip_nonlocal_bind I have also
> set the Kamailio ip_free_bind=1 and it does not
> work.
> Here are my relevant config lines:
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> listen=LISTEN_UDP_PUBLIC
>
> mhomed=1
> ip_free_bind=1
>
>
> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I
> have been using it for a long time and have
> rebooted as well):
> net.ipv4.ip_nonlocal_bind=1
> --
> ^C
>
>
> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
> > Hello Chad,
> >
> > You can add a listen directive to your config for the virtual IPs
> > (both public and private) and then you don't need to manually modify
> > any headers or use force_send_socket().
> > You need to enable non local IP binding so kamailio can start on the
> > server that doesn't have the virtual IP:
> > echo 1 >
Re: [SR-Users] Help with rewriting headers for NAT manually
Oops ... copy/paste mistake:
You need to replace:
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
with
listen=LISTEN_UDP_PRIVATE
-ovidiu
On Sat, Jan 15, 2022 at 1:07 PM Ovidiu Sas wrote:
>
> It doesn't look good because you have the public IP twice in the
> Record-Route header.
> You need to replace the
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> with
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> and all should be good.
>
> If your carrier is telling you that the IP address in Contact should
> be public, then you need to find an RFC compliant carrier (or mangle
> the Contact to make them happy).
> Most of the time I fight with them until they have this fixed.
> Sometimes it's a lost battle and you just need to hack your config to
> make it work.
>
> I have deployed kamailio using this setup and if you deal with RFC
> compliant end-point (carriers, softphones, hardphones) then all is
> good.
>
> -ovidiu
>
> On Sat, Jan 15, 2022 at 12:14 PM Chad wrote:
> >
> > It would be great if you are right and I am simply doing something else
> > wrong in the config file!
> >
> > Here is the 200 OK (note I have enable_double_rr enabled):
> > SIP/2.0 200 OK
> > Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0
> > Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0
> > Record-Route:
> > Record-Route:
> > Record-Route:
> > From: ;tag=gK0e16642e
> > To: ;tag=as488a6fb4
> > Call-ID: 202251204_54250714@206.###.###.###
> > CSeq: 710596 INVITE
> > Server: Asterisk PBX 16.18.0
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> > PUBLISH, MESSAGE
> > Supported: replaces, timer
> > Session-Expires: 1800;refresher=uas
> > Contact:
> > Content-Type: application/sdp
> > Require: timer
> > Content-Length: 272
> >
> > v=0
> > o=root 153822920 153822920 IN IP4 209.###.###.###
> > s=Asterisk PBX 16.18.0
> > c=IN IP4 209.###.###.###
> > t=0 0
> > m=audio 17198 RTP/AVP 0 101
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-16
> > a=ptime:20
> > a=maxptime:150
> > a=sendrecv
> > a=nortpproxy:yes
> >
> >
> > --
> > ^C
> >
> >
> > On 1/15/22 9:05 AM, Ovidiu Sas wrote:
> > > You have a different problem then.
> > > Having private IPs in Contact is fine. You need to lose route the
> > > calls (kamailio will add two Record-Route headers) and the origination
> > > server will set the RURI to the private IP from Contact, but it will
> > > send the in-dialog requests to the public IP of kamailio. This has
> > > nothing to do with virtual IPs.
> > > Maybe you have a buggy client that doesn't do proper loose routing.
> > >
> > > -ovidiu
> > >
> > > On Sat, Jan 15, 2022 at 11:50 AM Chad wrote:
> > >>
> > >> Ovidiu,
> > >> Thank you again for your response.
> > >> One is public (an internet IP) and one is private (a 10.x ip).
> > >> Apparently this is a known problem with virtual IPs, it does not work.
> > >> When the asterisk server responds to the invite it sends a contact
> > >> header with the private IP and Kamailio does not
> > >> rewrite it to the advertised public IP. So the originating server sees
> > >> the private IP in the Contact header and tries to
> > >> send the traffic to the 10.x IP (which is non-routable) and the call
> > >> dies.
> > >> I have been trying things for a long time to fix this (years) what you
> > >> are saying will not fix it because of the virtual
> > >> IPs.
> > >> If it was a normal IP it would work fine. It has something to do with
> > >> the routing table and how mhomed detects networks.
> > >>
> > >> --
> > >> ^C
> > >>
> > >>
> > >> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> > >>> Hello Chad,
> > >>>
> > >>> The floating IPs that you have, are they both private IPs or one
> > >>> private IP and the other one a public IP?
> > >>>
> > >>> If you have to two floating private IPs, then you need a config like
> > >>> this:
> > >>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> > >>> listen=FLOATING_UDP_PRIVATE2
> > >>>
> > >>> In the config, before relaying the initial INVITE you need to detect
> > >>> the direction of the call and set $fs accordingly:
> > >>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {
> > >>> $fs = udp:FLOATING_UDP_PRIVATE1
> > >>> }
> > >>> else {
> > >>> $fs = udp:FLOATING_UDP_PRIVATE2
> > >>> }
> > >>>
> > >>> If you have a floating private IPs and a floating public IP, then you
> > >>> need a config like this:
> > >>> listen=FLOATING_UDP_PRIVATE
> > >>> listen=FLOATING_UDP_PUBLIC
> > >>>
> > >>> There should be no need to force the socket, but if you do, there's no
> > >>> harm (actually it's better and faster).
> > >>>
> > >>> Hope this clarifies things and helps,
> > >>> -ovidiu
> > >>>
> > >>> On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
> >
> > Ovidiu,
> > Thank you for your response.
> >
> > I have done that, in addition to the linux ip_nonlocal_bind I have
> > also set the Kamailio ip_free_bind=1 and it does not
Re: [SR-Users] Help with rewriting headers for NAT manually
It doesn't look good because you have the public IP twice in the
Record-Route header.
You need to replace the
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
with
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
and all should be good.
If your carrier is telling you that the IP address in Contact should
be public, then you need to find an RFC compliant carrier (or mangle
the Contact to make them happy).
Most of the time I fight with them until they have this fixed.
Sometimes it's a lost battle and you just need to hack your config to
make it work.
I have deployed kamailio using this setup and if you deal with RFC
compliant end-point (carriers, softphones, hardphones) then all is
good.
-ovidiu
On Sat, Jan 15, 2022 at 12:14 PM Chad wrote:
>
> It would be great if you are right and I am simply doing something else wrong
> in the config file!
>
> Here is the 200 OK (note I have enable_double_rr enabled):
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0
> Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0
> Record-Route:
> Record-Route:
> Record-Route:
> From: ;tag=gK0e16642e
> To: ;tag=as488a6fb4
> Call-ID: 202251204_54250714@206.###.###.###
> CSeq: 710596 INVITE
> Server: Asterisk PBX 16.18.0
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact:
> Content-Type: application/sdp
> Require: timer
> Content-Length: 272
>
> v=0
> o=root 153822920 153822920 IN IP4 209.###.###.###
> s=Asterisk PBX 16.18.0
> c=IN IP4 209.###.###.###
> t=0 0
> m=audio 17198 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> a=nortpproxy:yes
>
>
> --
> ^C
>
>
> On 1/15/22 9:05 AM, Ovidiu Sas wrote:
> > You have a different problem then.
> > Having private IPs in Contact is fine. You need to lose route the
> > calls (kamailio will add two Record-Route headers) and the origination
> > server will set the RURI to the private IP from Contact, but it will
> > send the in-dialog requests to the public IP of kamailio. This has
> > nothing to do with virtual IPs.
> > Maybe you have a buggy client that doesn't do proper loose routing.
> >
> > -ovidiu
> >
> > On Sat, Jan 15, 2022 at 11:50 AM Chad wrote:
> >>
> >> Ovidiu,
> >> Thank you again for your response.
> >> One is public (an internet IP) and one is private (a 10.x ip).
> >> Apparently this is a known problem with virtual IPs, it does not work.
> >> When the asterisk server responds to the invite it sends a contact header
> >> with the private IP and Kamailio does not
> >> rewrite it to the advertised public IP. So the originating server sees the
> >> private IP in the Contact header and tries to
> >> send the traffic to the 10.x IP (which is non-routable) and the call dies.
> >> I have been trying things for a long time to fix this (years) what you are
> >> saying will not fix it because of the virtual
> >> IPs.
> >> If it was a normal IP it would work fine. It has something to do with the
> >> routing table and how mhomed detects networks.
> >>
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> >>> Hello Chad,
> >>>
> >>> The floating IPs that you have, are they both private IPs or one
> >>> private IP and the other one a public IP?
> >>>
> >>> If you have to two floating private IPs, then you need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> >>> listen=FLOATING_UDP_PRIVATE2
> >>>
> >>> In the config, before relaying the initial INVITE you need to detect
> >>> the direction of the call and set $fs accordingly:
> >>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {
> >>> $fs = udp:FLOATING_UDP_PRIVATE1
> >>> }
> >>> else {
> >>> $fs = udp:FLOATING_UDP_PRIVATE2
> >>> }
> >>>
> >>> If you have a floating private IPs and a floating public IP, then you
> >>> need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE
> >>> listen=FLOATING_UDP_PUBLIC
> >>>
> >>> There should be no need to force the socket, but if you do, there's no
> >>> harm (actually it's better and faster).
> >>>
> >>> Hope this clarifies things and helps,
> >>> -ovidiu
> >>>
> >>> On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
>
> Ovidiu,
> Thank you for your response.
>
> I have done that, in addition to the linux ip_nonlocal_bind I have also
> set the Kamailio ip_free_bind=1 and it does not
> work.
> Here are my relevant config lines:
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> listen=LISTEN_UDP_PUBLIC
>
> mhomed=1
> ip_free_bind=1
>
>
> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I
> have been using it for a long time and have
> rebooted as well):
> net.ipv4.ip_nonlocal_bind=1
> --
> ^C
>
>
> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
>
Re: [SR-Users] Help with rewriting headers for NAT manually
Hmm, I don't think you are right that the Contact header can be a private IP
even if the RR is correct.
I did some research on it and I found several places saying it must be a
routable IP which is what the carrier also said.
"The Contact header contains the SIP URI where the client wants to be contacted for subsequent requests. That means that
the host part of the URI must be globally reachable by anyone.
If your contact contains a private IP (behind a NAT?) then it is wrong, because
other peers cannot reach you with that."
--
^C
On 1/15/22 9:05 AM, Ovidiu Sas wrote:
You have a different problem then.
Having private IPs in Contact is fine. You need to lose route the
calls (kamailio will add two Record-Route headers) and the origination
server will set the RURI to the private IP from Contact, but it will
send the in-dialog requests to the public IP of kamailio. This has
nothing to do with virtual IPs.
Maybe you have a buggy client that doesn't do proper loose routing.
-ovidiu
On Sat, Jan 15, 2022 at 11:50 AM Chad wrote:
Ovidiu,
Thank you again for your response.
One is public (an internet IP) and one is private (a 10.x ip).
Apparently this is a known problem with virtual IPs, it does not work.
When the asterisk server responds to the invite it sends a contact header with
the private IP and Kamailio does not
rewrite it to the advertised public IP. So the originating server sees the
private IP in the Contact header and tries to
send the traffic to the 10.x IP (which is non-routable) and the call dies.
I have been trying things for a long time to fix this (years) what you are
saying will not fix it because of the virtual
IPs.
If it was a normal IP it would work fine. It has something to do with the
routing table and how mhomed detects networks.
--
^C
On 1/15/22 8:36 AM, Ovidiu Sas wrote:
Hello Chad,
The floating IPs that you have, are they both private IPs or one
private IP and the other one a public IP?
If you have to two floating private IPs, then you need a config like this:
listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
listen=FLOATING_UDP_PRIVATE2
In the config, before relaying the initial INVITE you need to detect
the direction of the call and set $fs accordingly:
if (CAL_FROM_PRIVATE_TO_PUBLIC) {
$fs = udp:FLOATING_UDP_PRIVATE1
}
else {
$fs = udp:FLOATING_UDP_PRIVATE2
}
If you have a floating private IPs and a floating public IP, then you
need a config like this:
listen=FLOATING_UDP_PRIVATE
listen=FLOATING_UDP_PUBLIC
There should be no need to force the socket, but if you do, there's no
harm (actually it's better and faster).
Hope this clarifies things and helps,
-ovidiu
On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
Ovidiu,
Thank you for your response.
I have done that, in addition to the linux ip_nonlocal_bind I have also set the
Kamailio ip_free_bind=1 and it does not
work.
Here are my relevant config lines:
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
listen=LISTEN_UDP_PUBLIC
mhomed=1
ip_free_bind=1
In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have been
using it for a long time and have
rebooted as well):
net.ipv4.ip_nonlocal_bind=1
--
^C
On 1/15/22 4:55 AM, Ovidiu Sas wrote:
Hello Chad,
You can add a listen directive to your config for the virtual IPs
(both public and private) and then you don't need to manually modify
any headers or use force_send_socket().
You need to enable non local IP binding so kamailio can start on the
server that doesn't have the virtual IP:
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
To make the change permanent, edit your sysctl.conf file and enable it there:
net/ipv4/ip_nonlocal_bind = 1
Regards
Ovidiu Sas
On Sat, Jan 15, 2022 at 4:16 AM Chad wrote:
We are looking for some help (possibly a paid consultant) to help us with our
Kamailio setup.
To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our
external IP and our private IP asterisk
servers (via dispatcher).
However both the external IP and the internal IP that the Kamailio server uses
are virtual IPs created by keepalived.
Because of that neither mhomed nor fix_nated_contact work, and we use
force_send_socket to direct the traffic.
We run linux Debian 10 for the OS.
Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP
in it, like:
Contact:
There are 2 possible solutions to this:
1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize
the virtual IPs so that mhomed and
fix_nated_contact work as usual.
2. Create a manual header rewrite system.
If solution #2:
What we need to do is create a way to rewrite the contact header to the
external IP on the way out, and on the way back
rewrite it back to the internal server that the call is already connected to.
Not sure if we will need to store those paths on the server or if we can do
some kind of cheat with
Re: [SR-Users] Help with rewriting headers for NAT manually
It would be great if you are right and I am simply doing something else wrong
in the config file!
Here is the 200 OK (note I have enable_double_rr enabled):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0
Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0
Record-Route:
Record-Route:
Record-Route:
From: ;tag=gK0e16642e
To: ;tag=as488a6fb4
Call-ID: 202251204_54250714@206.###.###.###
CSeq: 710596 INVITE
Server: Asterisk PBX 16.18.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact:
Content-Type: application/sdp
Require: timer
Content-Length: 272
v=0
o=root 153822920 153822920 IN IP4 209.###.###.###
s=Asterisk PBX 16.18.0
c=IN IP4 209.###.###.###
t=0 0
m=audio 17198 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=nortpproxy:yes
--
^C
On 1/15/22 9:05 AM, Ovidiu Sas wrote:
You have a different problem then.
Having private IPs in Contact is fine. You need to lose route the
calls (kamailio will add two Record-Route headers) and the origination
server will set the RURI to the private IP from Contact, but it will
send the in-dialog requests to the public IP of kamailio. This has
nothing to do with virtual IPs.
Maybe you have a buggy client that doesn't do proper loose routing.
-ovidiu
On Sat, Jan 15, 2022 at 11:50 AM Chad wrote:
Ovidiu,
Thank you again for your response.
One is public (an internet IP) and one is private (a 10.x ip).
Apparently this is a known problem with virtual IPs, it does not work.
When the asterisk server responds to the invite it sends a contact header with
the private IP and Kamailio does not
rewrite it to the advertised public IP. So the originating server sees the
private IP in the Contact header and tries to
send the traffic to the 10.x IP (which is non-routable) and the call dies.
I have been trying things for a long time to fix this (years) what you are
saying will not fix it because of the virtual
IPs.
If it was a normal IP it would work fine. It has something to do with the
routing table and how mhomed detects networks.
--
^C
On 1/15/22 8:36 AM, Ovidiu Sas wrote:
Hello Chad,
The floating IPs that you have, are they both private IPs or one
private IP and the other one a public IP?
If you have to two floating private IPs, then you need a config like this:
listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
listen=FLOATING_UDP_PRIVATE2
In the config, before relaying the initial INVITE you need to detect
the direction of the call and set $fs accordingly:
if (CAL_FROM_PRIVATE_TO_PUBLIC) {
$fs = udp:FLOATING_UDP_PRIVATE1
}
else {
$fs = udp:FLOATING_UDP_PRIVATE2
}
If you have a floating private IPs and a floating public IP, then you
need a config like this:
listen=FLOATING_UDP_PRIVATE
listen=FLOATING_UDP_PUBLIC
There should be no need to force the socket, but if you do, there's no
harm (actually it's better and faster).
Hope this clarifies things and helps,
-ovidiu
On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
Ovidiu,
Thank you for your response.
I have done that, in addition to the linux ip_nonlocal_bind I have also set the
Kamailio ip_free_bind=1 and it does not
work.
Here are my relevant config lines:
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
listen=LISTEN_UDP_PUBLIC
mhomed=1
ip_free_bind=1
In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have been
using it for a long time and have
rebooted as well):
net.ipv4.ip_nonlocal_bind=1
--
^C
On 1/15/22 4:55 AM, Ovidiu Sas wrote:
Hello Chad,
You can add a listen directive to your config for the virtual IPs
(both public and private) and then you don't need to manually modify
any headers or use force_send_socket().
You need to enable non local IP binding so kamailio can start on the
server that doesn't have the virtual IP:
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
To make the change permanent, edit your sysctl.conf file and enable it there:
net/ipv4/ip_nonlocal_bind = 1
Regards
Ovidiu Sas
On Sat, Jan 15, 2022 at 4:16 AM Chad wrote:
We are looking for some help (possibly a paid consultant) to help us with our
Kamailio setup.
To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our
external IP and our private IP asterisk
servers (via dispatcher).
However both the external IP and the internal IP that the Kamailio server uses
are virtual IPs created by keepalived.
Because of that neither mhomed nor fix_nated_contact work, and we use
force_send_socket to direct the traffic.
We run linux Debian 10 for the OS.
Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP
in it, like:
Contact:
There are 2 possible solutions to this:
1. Make changes to linux, keepalived and/or Kamailio so that Kamailio
Re: [SR-Users] Help with rewriting headers for NAT manually
You have a different problem then.
Having private IPs in Contact is fine. You need to lose route the
calls (kamailio will add two Record-Route headers) and the origination
server will set the RURI to the private IP from Contact, but it will
send the in-dialog requests to the public IP of kamailio. This has
nothing to do with virtual IPs.
Maybe you have a buggy client that doesn't do proper loose routing.
-ovidiu
On Sat, Jan 15, 2022 at 11:50 AM Chad wrote:
>
> Ovidiu,
> Thank you again for your response.
> One is public (an internet IP) and one is private (a 10.x ip).
> Apparently this is a known problem with virtual IPs, it does not work.
> When the asterisk server responds to the invite it sends a contact header
> with the private IP and Kamailio does not
> rewrite it to the advertised public IP. So the originating server sees the
> private IP in the Contact header and tries to
> send the traffic to the 10.x IP (which is non-routable) and the call dies.
> I have been trying things for a long time to fix this (years) what you are
> saying will not fix it because of the virtual
> IPs.
> If it was a normal IP it would work fine. It has something to do with the
> routing table and how mhomed detects networks.
>
> --
> ^C
>
>
> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> > Hello Chad,
> >
> > The floating IPs that you have, are they both private IPs or one
> > private IP and the other one a public IP?
> >
> > If you have to two floating private IPs, then you need a config like this:
> > listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> > listen=FLOATING_UDP_PRIVATE2
> >
> > In the config, before relaying the initial INVITE you need to detect
> > the direction of the call and set $fs accordingly:
> > if (CAL_FROM_PRIVATE_TO_PUBLIC) {
> > $fs = udp:FLOATING_UDP_PRIVATE1
> > }
> > else {
> > $fs = udp:FLOATING_UDP_PRIVATE2
> > }
> >
> > If you have a floating private IPs and a floating public IP, then you
> > need a config like this:
> > listen=FLOATING_UDP_PRIVATE
> > listen=FLOATING_UDP_PUBLIC
> >
> > There should be no need to force the socket, but if you do, there's no
> > harm (actually it's better and faster).
> >
> > Hope this clarifies things and helps,
> > -ovidiu
> >
> > On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
> >>
> >> Ovidiu,
> >> Thank you for your response.
> >>
> >> I have done that, in addition to the linux ip_nonlocal_bind I have also
> >> set the Kamailio ip_free_bind=1 and it does not
> >> work.
> >> Here are my relevant config lines:
> >> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> >> listen=LISTEN_UDP_PUBLIC
> >>
> >> mhomed=1
> >> ip_free_bind=1
> >>
> >>
> >> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have
> >> been using it for a long time and have
> >> rebooted as well):
> >> net.ipv4.ip_nonlocal_bind=1
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
> >>> Hello Chad,
> >>>
> >>> You can add a listen directive to your config for the virtual IPs
> >>> (both public and private) and then you don't need to manually modify
> >>> any headers or use force_send_socket().
> >>> You need to enable non local IP binding so kamailio can start on the
> >>> server that doesn't have the virtual IP:
> >>> echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
> >>> To make the change permanent, edit your sysctl.conf file and enable it
> >>> there:
> >>> net/ipv4/ip_nonlocal_bind = 1
> >>>
> >>> Regards
> >>> Ovidiu Sas
> >>>
> >>>
> >>> On Sat, Jan 15, 2022 at 4:16 AM Chad wrote:
>
> We are looking for some help (possibly a paid consultant) to help us
> with our Kamailio setup.
> To keep this as short as possible: we use Kamailio as a NAT proxy to
> bridge our external IP and our private IP asterisk
> servers (via dispatcher).
> However both the external IP and the internal IP that the Kamailio
> server uses are virtual IPs created by keepalived.
> Because of that neither mhomed nor fix_nated_contact work, and we use
> force_send_socket to direct the traffic.
> We run linux Debian 10 for the OS.
> Also we do not use a DB at all, everything is done with local config
> files.
>
> The problem is that when traffic goes out the Contact header has a
> private IP in it, like:
> Contact:
>
> There are 2 possible solutions to this:
> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio
> recognize the virtual IPs so that mhomed and
> fix_nated_contact work as usual.
>
> 2. Create a manual header rewrite system.
>
> If solution #2:
> What we need to do is create a way to rewrite the contact header to the
> external IP on the way out, and on the way back
> rewrite it back to the internal server that the call is already
> connected to.
>
> Not sure if we will need to store those paths on the server or if we can
> do some kind of cheat with another
Re: [SR-Users] Help with rewriting headers for NAT manually
Ovidiu,
Thank you again for your response.
One is public (an internet IP) and one is private (a 10.x ip).
Apparently this is a known problem with virtual IPs, it does not work.
When the asterisk server responds to the invite it sends a contact header with the private IP and Kamailio does not
rewrite it to the advertised public IP. So the originating server sees the private IP in the Contact header and tries to
send the traffic to the 10.x IP (which is non-routable) and the call dies.
I have been trying things for a long time to fix this (years) what you are saying will not fix it because of the virtual
IPs.
If it was a normal IP it would work fine. It has something to do with the
routing table and how mhomed detects networks.
--
^C
On 1/15/22 8:36 AM, Ovidiu Sas wrote:
Hello Chad,
The floating IPs that you have, are they both private IPs or one
private IP and the other one a public IP?
If you have to two floating private IPs, then you need a config like this:
listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
listen=FLOATING_UDP_PRIVATE2
In the config, before relaying the initial INVITE you need to detect
the direction of the call and set $fs accordingly:
if (CAL_FROM_PRIVATE_TO_PUBLIC) {
$fs = udp:FLOATING_UDP_PRIVATE1
}
else {
$fs = udp:FLOATING_UDP_PRIVATE2
}
If you have a floating private IPs and a floating public IP, then you
need a config like this:
listen=FLOATING_UDP_PRIVATE
listen=FLOATING_UDP_PUBLIC
There should be no need to force the socket, but if you do, there's no
harm (actually it's better and faster).
Hope this clarifies things and helps,
-ovidiu
On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
Ovidiu,
Thank you for your response.
I have done that, in addition to the linux ip_nonlocal_bind I have also set the
Kamailio ip_free_bind=1 and it does not
work.
Here are my relevant config lines:
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
listen=LISTEN_UDP_PUBLIC
mhomed=1
ip_free_bind=1
In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have been
using it for a long time and have
rebooted as well):
net.ipv4.ip_nonlocal_bind=1
--
^C
On 1/15/22 4:55 AM, Ovidiu Sas wrote:
Hello Chad,
You can add a listen directive to your config for the virtual IPs
(both public and private) and then you don't need to manually modify
any headers or use force_send_socket().
You need to enable non local IP binding so kamailio can start on the
server that doesn't have the virtual IP:
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
To make the change permanent, edit your sysctl.conf file and enable it there:
net/ipv4/ip_nonlocal_bind = 1
Regards
Ovidiu Sas
On Sat, Jan 15, 2022 at 4:16 AM Chad wrote:
We are looking for some help (possibly a paid consultant) to help us with our
Kamailio setup.
To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our
external IP and our private IP asterisk
servers (via dispatcher).
However both the external IP and the internal IP that the Kamailio server uses
are virtual IPs created by keepalived.
Because of that neither mhomed nor fix_nated_contact work, and we use
force_send_socket to direct the traffic.
We run linux Debian 10 for the OS.
Also we do not use a DB at all, everything is done with local config files.
The problem is that when traffic goes out the Contact header has a private IP
in it, like:
Contact:
There are 2 possible solutions to this:
1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize
the virtual IPs so that mhomed and
fix_nated_contact work as usual.
2. Create a manual header rewrite system.
If solution #2:
What we need to do is create a way to rewrite the contact header to the
external IP on the way out, and on the way back
rewrite it back to the internal server that the call is already connected to.
Not sure if we will need to store those paths on the server or if we can do
some kind of cheat with another persistant
header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the
internal IP in the name field or something).
If anyone out there know of a way to do this or wants to give it a try please
reach out to me.
Thank you all for your time.
--
^C
Chad
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Help with rewriting headers for NAT manually
Hello Chad,
The floating IPs that you have, are they both private IPs or one
private IP and the other one a public IP?
If you have to two floating private IPs, then you need a config like this:
listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
listen=FLOATING_UDP_PRIVATE2
In the config, before relaying the initial INVITE you need to detect
the direction of the call and set $fs accordingly:
if (CAL_FROM_PRIVATE_TO_PUBLIC) {
$fs = udp:FLOATING_UDP_PRIVATE1
}
else {
$fs = udp:FLOATING_UDP_PRIVATE2
}
If you have a floating private IPs and a floating public IP, then you
need a config like this:
listen=FLOATING_UDP_PRIVATE
listen=FLOATING_UDP_PUBLIC
There should be no need to force the socket, but if you do, there's no
harm (actually it's better and faster).
Hope this clarifies things and helps,
-ovidiu
On Sat, Jan 15, 2022 at 9:48 AM Chad wrote:
>
> Ovidiu,
> Thank you for your response.
>
> I have done that, in addition to the linux ip_nonlocal_bind I have also set
> the Kamailio ip_free_bind=1 and it does not
> work.
> Here are my relevant config lines:
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> listen=LISTEN_UDP_PUBLIC
>
> mhomed=1
> ip_free_bind=1
>
>
> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have
> been using it for a long time and have
> rebooted as well):
> net.ipv4.ip_nonlocal_bind=1
> --
> ^C
>
>
> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
> > Hello Chad,
> >
> > You can add a listen directive to your config for the virtual IPs
> > (both public and private) and then you don't need to manually modify
> > any headers or use force_send_socket().
> > You need to enable non local IP binding so kamailio can start on the
> > server that doesn't have the virtual IP:
> > echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
> > To make the change permanent, edit your sysctl.conf file and enable it
> > there:
> > net/ipv4/ip_nonlocal_bind = 1
> >
> > Regards
> > Ovidiu Sas
> >
> >
> > On Sat, Jan 15, 2022 at 4:16 AM Chad wrote:
> >>
> >> We are looking for some help (possibly a paid consultant) to help us with
> >> our Kamailio setup.
> >> To keep this as short as possible: we use Kamailio as a NAT proxy to
> >> bridge our external IP and our private IP asterisk
> >> servers (via dispatcher).
> >> However both the external IP and the internal IP that the Kamailio server
> >> uses are virtual IPs created by keepalived.
> >> Because of that neither mhomed nor fix_nated_contact work, and we use
> >> force_send_socket to direct the traffic.
> >> We run linux Debian 10 for the OS.
> >> Also we do not use a DB at all, everything is done with local config files.
> >>
> >> The problem is that when traffic goes out the Contact header has a private
> >> IP in it, like:
> >> Contact:
> >>
> >> There are 2 possible solutions to this:
> >> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio
> >> recognize the virtual IPs so that mhomed and
> >> fix_nated_contact work as usual.
> >>
> >> 2. Create a manual header rewrite system.
> >>
> >> If solution #2:
> >> What we need to do is create a way to rewrite the contact header to the
> >> external IP on the way out, and on the way back
> >> rewrite it back to the internal server that the call is already connected
> >> to.
> >>
> >> Not sure if we will need to store those paths on the server or if we can
> >> do some kind of cheat with another persistant
> >> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the
> >> internal IP in the name field or something).
> >>
> >> If anyone out there know of a way to do this or wants to give it a try
> >> please reach out to me.
> >>
> >> Thank you all for your time.
> >>
> >> --
> >> ^C
> >> Chad
> >>
> >> __
> >> Kamailio - Users Mailing List - Non Commercial Discussions
> >>* sr-users@lists.kamailio.org
> >> Important: keep the mailing list in the recipients, do not reply only to
> >> the sender!
> >> Edit mailing list options or unsubscribe:
> >>* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
> >
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> >* sr-users@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> > the sender!
> > Edit mailing list options or unsubscribe:
> >* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Help with rewriting headers for NAT manually
Ovidiu, Thank you for your response. I have done that, in addition to the linux ip_nonlocal_bind I have also set the Kamailio ip_free_bind=1 and it does not work. Here are my relevant config lines: listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060 listen=LISTEN_UDP_PUBLIC mhomed=1 ip_free_bind=1 In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have been using it for a long time and have rebooted as well): net.ipv4.ip_nonlocal_bind=1 -- ^C On 1/15/22 4:55 AM, Ovidiu Sas wrote: Hello Chad, You can add a listen directive to your config for the virtual IPs (both public and private) and then you don't need to manually modify any headers or use force_send_socket(). You need to enable non local IP binding so kamailio can start on the server that doesn't have the virtual IP: echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind To make the change permanent, edit your sysctl.conf file and enable it there: net/ipv4/ip_nonlocal_bind = 1 Regards Ovidiu Sas On Sat, Jan 15, 2022 at 4:16 AM Chad wrote: We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files. The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: There are 2 possible solutions to this: 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and fix_nated_contact work as usual. 2. Create a manual header rewrite system. If solution #2: What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back rewrite it back to the internal server that the call is already connected to. Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). If anyone out there know of a way to do this or wants to give it a try please reach out to me. Thank you all for your time. -- ^C Chad __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- VoIP Embedded, Inc. http://www.voipembedded.com __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Help with rewriting headers for NAT manually
Hello Chad, You can add a listen directive to your config for the virtual IPs (both public and private) and then you don't need to manually modify any headers or use force_send_socket(). You need to enable non local IP binding so kamailio can start on the server that doesn't have the virtual IP: echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind To make the change permanent, edit your sysctl.conf file and enable it there: net/ipv4/ip_nonlocal_bind = 1 Regards Ovidiu Sas On Sat, Jan 15, 2022 at 4:16 AM Chad wrote: > > We are looking for some help (possibly a paid consultant) to help us with our > Kamailio setup. > To keep this as short as possible: we use Kamailio as a NAT proxy to bridge > our external IP and our private IP asterisk > servers (via dispatcher). > However both the external IP and the internal IP that the Kamailio server > uses are virtual IPs created by keepalived. > Because of that neither mhomed nor fix_nated_contact work, and we use > force_send_socket to direct the traffic. > We run linux Debian 10 for the OS. > Also we do not use a DB at all, everything is done with local config files. > > The problem is that when traffic goes out the Contact header has a private IP > in it, like: > Contact: > > There are 2 possible solutions to this: > 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio > recognize the virtual IPs so that mhomed and > fix_nated_contact work as usual. > > 2. Create a manual header rewrite system. > > If solution #2: > What we need to do is create a way to rewrite the contact header to the > external IP on the way out, and on the way back > rewrite it back to the internal server that the call is already connected to. > > Not sure if we will need to store those paths on the server or if we can do > some kind of cheat with another persistant > header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the > internal IP in the name field or something). > > If anyone out there know of a way to do this or wants to give it a try please > reach out to me. > > Thank you all for your time. > > -- > ^C > Chad > > __ > Kamailio - Users Mailing List - Non Commercial Discussions > * sr-users@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- VoIP Embedded, Inc. http://www.voipembedded.com __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Help with rewriting headers for NAT manually
We are looking for some help (possibly a paid consultant) to help us with our Kamailio setup. To keep this as short as possible: we use Kamailio as a NAT proxy to bridge our external IP and our private IP asterisk servers (via dispatcher). However both the external IP and the internal IP that the Kamailio server uses are virtual IPs created by keepalived. Because of that neither mhomed nor fix_nated_contact work, and we use force_send_socket to direct the traffic. We run linux Debian 10 for the OS. Also we do not use a DB at all, everything is done with local config files. The problem is that when traffic goes out the Contact header has a private IP in it, like: Contact: There are 2 possible solutions to this: 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio recognize the virtual IPs so that mhomed and fix_nated_contact work as usual. 2. Create a manual header rewrite system. If solution #2: What we need to do is create a way to rewrite the contact header to the external IP on the way out, and on the way back rewrite it back to the internal server that the call is already connected to. Not sure if we will need to store those paths on the server or if we can do some kind of cheat with another persistant header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the internal IP in the name field or something). If anyone out there know of a way to do this or wants to give it a try please reach out to me. Thank you all for your time. -- ^C Chad __ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
