[kamailio/kamailio] Hostname only (no ports) in the advertise parameter should be allowed (#1884)
### Description
The `advertise` option in a `listen` parameter seems to only allow the following syntax: `advertise ip_or_host:port` The `advertise ip_or_host` syntax is not allowed and gives the following error:
CRITICAL: <core> [core/cfg.y:3507]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 49, column 1-6: ip address, interface name or hostname expected
This can be blocking when using DNS SRV features in order to retrieve both host and port to send the SIP messages: when a port is present in the record-route/via headers no DNS SRV are done. So it prevents from doing some DNS-based load-balancing / failover things.
### Troubleshooting
We get the same behaviour with using the deprecated `advertised_address` parameter: default port is set by Kamailio (because it is not possible to force a _null_ value for `advertised_port`) in the _Via_ header (but does not seem to affect the _R-R_ header). The advertised address can only be forced for the _Record-Route_ header using the `record_route_advertised_address` function in the script.
### Additional Information
Tested with last Kamailio release on Debian 9.8
``` version: kamailio 5.2.1 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_BLACKLIST, HAVE_RESOLV_RES 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 6.3.0 ```
It proved not to be complex, just a matter of the current config grammar. Even with the old versions you can set the port to `0` and then it should not appear in the headers.
Anyhow, I pushed also a commit that allows advertise with host only, being an alias to `... advertise host:0`. When listing the sockets via rpc, the port 0 will appear, but in headers should be no port.
I did basic testing, if it does not work, reopen this issue.
Closed #1884.
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.
-
Daniel-Constantin Mierla -
jklingenmeyer