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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1884#issuecomment-475151941
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to