Hi Schneur,
It is not 100% correct, as a sip message may come from a another SIP
server and in this case the Contact (belong to the end point) should not
be re-written with the IP OPenSIPS sees as source (which is the other
SIP server).
Shortly said, you can force the re-write as time as you k
You're right, I noticed that the port was wrong at the first invite,
but I didn't realize that it was fixed, I thought it left it
untouched, I just checked again and you're correct it did fix it.
Is there any downside (besides for obvious performance reasons) to
call fix_nated_contact() on each p
Hi Schneur,
I see at initial INVITE you have the same issue - the contact advertises
the 34063 port, but the source IP is 1090; and you do
fix_nated_contact(). So, based on the initial contact, you learned that
the caller device is behind a NAT (or with a bogus ALG). The idea is to
remember t
Bogdan its only happening when the clients SIP ALG fixes the contact,
when the contact is broken I'm already using fix_nated_contact, do you
think I should use fix_nated_contact even when the contact was already
fixed by the SIP ALG?
The clients router does not support disabling SIP ALG, I can try
Hi Schneur,
The ACK is routed back via the Route set (the Record Route headers from
the initial Invite) and the Contact received in the final reply (in the
200 OK in your case). This is called in-dialog routing and is
exclusively based on Route set (RR headers + Contact).
The rport as part o
Hi Schneur,
do you have force_rport() in your opensips.cfg ? hard to make any other
comments without looking at your config.
On Monday, 12 February 2018, 20:36, Schneur Rosenberg
wrote:
I have this interesting scenario, caller sends call to our OpenSIPS
who actsd as a loadbalancer whi
