### Description
I'm using dispatcher module like:
``` loadmodule "dispatcher.so" modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_interval", 60) ``` With records like: ``` 1 sip:sip.host.com;transport=tls 0 1 socket=tls:111.222.233.10:5061;ping_from=sip:my-domain-01.com 2 sip:sip.host.com;transport=tls 0 1 socket=tls:111.222.233.20:5061;ping_from=sip:my-domain-02.com ```
In event_route[tm:local-request] I'm modifying 'Contact' and would like to specify what client TLS profile to use via server name or server id. ``` event_route[tm:local-request] { if(is_method("OPTIONS")) { append_hf("Contact: sip:some-host.com;transport=tls\r\n"); $xavp(tls=>server_name)=$fd; $xavp(tls[0]=>server_id)=$fd; } } ``` Setting 'tls' xavp doesn't make any difference and default client TLS profile is being used.
It happens because in src/modules/tm/uac.c there is a code: ``` t_run_local_req() ... tm_xdata_swap(new_cell, &backup_xd, 0); ... /* restore original environment */ tm_xdata_swap(new_cell, &backup_xd, 1); ``` which resets any xavp changes done in event_route[tm:local-request].
Expected behaviour: ability to use xavp in tm:local-request route. That would allow to choose TLS client profile for dispatcher initiated requests.
### Possible Solutions
As a hack, in tm_xdata_swap() for mode=1, don't restore xavp list if it was NULL. ``` if (x->xavps_list != NULL && *x->xavps_list==NULL) { // .... don't restore empty list... } else { xavp_set_list(x->xavps_list); } ``` This change allows to select required TLS profile for dispatcher requests.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.3.5 (x86_64/linux) ff2f8c-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, 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, TLS_PTHREAD_MUTEX_SHARED 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: ff2f8c -dirty compiled on 10:19:05 Jul 28 2020 with gcc 7.5.0 ```
* **Operating System**:
``` Linux xx 4.15.0-111-generic #112-Ubuntu SMP Thu Jul 9 20:32:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ```
With the current design, the event_route[tm:local-request] can happen while processing other requests, so restoring the previous environment attributes is relevant, otherwise the other requests can be routed using the same xavps. Moreover, there might be situations when these xavps keep accumulating, because nothing cleans them up.
Because the event_route[tm:local-request] is finished before actually the local request is sent out, it will require some redesing to get what you are looking for.
It can be as an enhancement for the future, right now an option would be to loop the keepalives back to kamailio via the outbound proxy param and then have the options routed via request_route.
If someone wants to work on such enhancement, announce yourself here.
Thank you for explanation and suggestion to use outbound proxy param. I may give it a try.
I added the function `tls_set_connect_server_id(srvid)` in tls module trying to cover this kind of need to specify the server id for next tls connect. Testing and feedback would be appreciated. I am closing this issue, in case of a problems, open a new one reporting what happens.
Closed #2413.