David,
Thank you for the suggestion.
Do you have any sample config files you can point me at?
--
^C
On 1/17/22 12:41 AM, David Villasmil wrote:
Take a look at freeSWITCH
On Mon, 17 Jan 2022 at 00:58, Chad mailto:ccolu...@hotmail.com>> wrote:
Hmm, it did not fix it (calls still work with
Michael,
Thank you for the feedback.
--
^C
On 1/16/22 4:02 PM, Michael Young wrote:
Chad,
In my experience, if you carrier partner is one of the bigger carriers, and\or you use multiple carriers, Kamailio is
the best solution available. With some of the smaller carriers\resellers it just
Take a look at freeSWITCH
On Mon, 17 Jan 2022 at 00:58, Chad wrote:
> Hmm, it did not fix it (calls still work with my other carriers).
> It looks to me like it should work, it does use the external IP for
> everything.
>
> It generates an error in the log about making your existing address:
>
Chad,
In my experience, if you carrier partner is one of the bigger carriers,
and\or you use multiple carriers, Kamailio is the best solution
available. With some of the smaller carriers\resellers it just makes
more sense to use Asterisk rather than argue with them about how they
are
Hmm, it did not fix it (calls still work with my other carriers).
It looks to me like it should work, it does use the external IP for everything.
It generates an error in the log about making your existing address:
topoh [topoh_mod.c:179]: mod_init(): mask address matches myself
If I use my external IP do I turn off enable_double_rr?
--
^C
On 1/16/22 3:16 PM, Ovidiu Sas wrote:
Use your 209.x external IP.
On Sun, Jan 16, 2022 at 18:07 Chad mailto:ccolu...@hotmail.com>> wrote:
Yes I am using a 172.16.x.x IP and it works, it rewrites the headers, but
again
I have been reading a lot more about the problem and it seems my
mangle/unmangle solution is basically B2BUA.
So I need a B2BUA solution and it seems like Kamailio does not really do B2BUA.
Instead of installing something else I don't know (SEMS or Sippy), it makes more sense to find something
Use your 209.x external IP.
On Sun, Jan 16, 2022 at 18:07 Chad wrote:
> Yes I am using a 172.16.x.x IP and it works, it rewrites the headers, but
> again because 172.16.x.x is also a private IP
> it is the same as using my real 10.x.x.x IP. The carrier's ACK throws away
> the local IP and sends
Yes I am using a 172.16.x.x IP and it works, it rewrites the headers, but again because 172.16.x.x is also a private IP
it is the same as using my real 10.x.x.x IP. The carrier's ACK throws away the local IP and sends the response to my
209.x external IP.
--
^C
On 1/16/22 1:38 PM, Ovidiu
I found a sample config file using topoh, which I copied (with some changes)
and added the topoh module to my config.
It works fine, but it does not solve the problem.
In fact it has the exact same problem, because all the topoh module does is replace one private IP with another in the
2nd (top
Most of the time, if you get the right person on the carrier's side
and you explain the situation, they will come up with a solution.
If not, you need to break the RFC in a way that will counterpart their breakage.
The carrier is also using a SIP proxy (maybe kamailio, who knows).
In the old
on behalf of Chad
*Sent:* Sunday, January 16, 2022 10:14 AM
*To:* Ovidiu Sas
*Cc:* Kamailio (SER) - Users Mailing List
*Subject:* 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
egards,
Shah Hussain
From: sr-users on behalf of Chad
Sent: Sunday, January 16, 2022 10:14 AM
To: Ovidiu Sas
Cc: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Help with rewriting headers for NAT manually
Ok so in short I was not doing anything wrong (although I had some
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
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
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
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
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
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
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
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
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.
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
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,
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
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:
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
27 matches
Mail list logo
