Hi Daniel,

Thanks for the quick fix you proposed, really appreciate it.
I have to admit I didn't even think to try with port 0 for the advertise option!

But it does not seem to behave as I expect: Via headers are still filled with a port in my case.

I did some deep checks and maybe I am not thinking correctly: what I was trying to do was to get all the headers free of ports.
With no ports I expect DNS records (NAPTR then SRV) to be used every time to dispatch the message (with DNS cache enabled to keep correct performance results).
A pool of Kamailios would advertise the same name so that other nodes would use the DNS failover/loadbalancing features to dispatch the messages in between.

My DNS records for this Kamailio pool look like this in my sandbox:

kamailio                   60 IN NAPTR  20 100 "S" "SIPS+D2T" "" _sips._tcp.kamailio.
_sips._tcp.core        60 IN SRV    1 2 5061 kamailio1.
                       60 IN SRV    2 2 5061 kamailio2.
kamailio1                   60 IN A      XX.XX.XX.1
kamailio2                   60 IN A      XX.XX.XX.2

I was able to force what is inserted in the R-R headers using the record_route_advertised_address function and it looks OK.
But I am stuck with the Via headers.

What I get:
Via: SIP/2.0/TLS kamailio.mydomain.com:5061;received=XX.XX.XX.1;

What I was expecting:
Via: SIP/2.0/TLS kamailio.mydomain.com;

So I see two blocking points here:

port is automatically added even with 'advertise kamailio.mydomain.com:0'
a "received" field is added (because it may think that the host in the header is not the same as the source address?). This field is then used to send the reply, bypassing DNS request.

So if this node is down at this time, there is no way for the reply to be transmitted.

I don't really want to play with textops or this kind of tools and now I am not so sure there are other ways to achieve my goal.
My idea was maybe not as well as it looked initially! I tkink I'll give up. A correct R-R header is already a good thing.

Thanks for your time Daniel.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.