### Description
When specifying a _record_route_advertised_address()_ before using the uac_replace function (for changing the FROM and TO Header field URIs), the rr param static buffer doesn't get emptied and a fallowing CALL (not a request in the same call) contains the rr params of the first call placed after restarting kamailio (to get the buffer resetted).
### Troubleshooting Restarting kamailio will reset the wrong buffer pointer and gets you another functioning call. Alternatively place the _record_route_advertised_address()_ after using uac_replace function.
#### Reproduction use record_route_advertised_address() before doing a uac_replace. This will get the vst and vsf parameters doubled in the rr of the second call after kamailio is restarted. When you place a call the first call proxied will carry only one set of vsf & vst parameters in the RR. The second call will carry the vst & vsf of the first call and a set of vst & vsf of the second call. If the uac_replace is replacing the same URIs the contents of the two sets of vsf and vst parameters in the RR Header will be identical.
uac.so config: loadmodule "uac.so" modparam("uac", "restore_mode","auto");
#### Analysis record_route() empties the RR param static buffer as follows, if it contains other message's params:
if (rr_param_buf.len && rr_param_msg!=_m->id) { /* rr_params were set for a different message -> reset buffer */ rr_param_buf.len = 0; }
But unfortunately, record_route_advertised_address() / record_route_preset() does not do this – it does NOT check/clean the buffer before adding RR.
So if the static buffer contains old entries (e.g. from an old call's subsequent request), wrong rr parameters are added.
This happens with uac module: restore_uri() is called for subsequent requests (via callback). restore_uri() calls (unnecessarily):
if ( uac_rrb.add_rr_param(msg, &add_to_rr)!=0 ) { LM_ERR("add rr param failed\n"); goto failed; }
So, if record_route has not yet been performed at this stage, add_rr_param() adds an entry to the static rr param buffer. (for subsequent request, record_route won't be performed)
If, for a following call, record_route_advertised_address() / record_route_preset() is called, the buffer is not checked/emptied, and old/wrong rr params are added.-->
```
#### SIP Traffic ``` Record-Route URI [truncated]: sip:my.node.com;transport=tls;r2=on;ftag=2ccb63ad;lr;vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU-;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ- Record-Route Host Part: my.node.com Record-Route URI parameter: transport=tls Record-Route URI parameter: r2=on Record-Route URI parameter: ftag=2ccb63ad Record-Route URI parameter: lr Record-Route URI parameter: vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU- Record-Route URI parameter: vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ-- Record-Route URI parameter: vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ-- Record-Route URI parameter: vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU- Record-Route URI parameter: did=4a8.56a2
URI, vsf & vst anonymised ```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.2.7 (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, 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: unknown compiled with gcc 8.3.0
```
* **Operating System**:
``` 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux ```
Can you try with the commit references above (use master branch or cherry pick commit in your branch)?
If it fixes, then it will be backported.
Closed #2486.
Okay, a little late, but I wanted to confirm, that the fix worked. I had to wait to move traffic from the installation to try to reproduce the problem with the newest debian repository kamailio update. The error didn't reoccur. Thank you!