[sr-dev] [kamailio/kamailio] topos/topos_redis is using wrong dialog end timeout (#1608)

[Andrew Pogrebennyk]

### Description

The R-URI is not un-masked/update by Kamailio topos module if the BYE message is received later than in 3 minutes after dialog begin.

We are using 5.1.4 plus the patch for 302 message on top, but tried also with topos/topos_redis from master, same result.

### Troubleshooting

for keys like [d:z:atpsh-5b619dee-5ca4-441] topos is using branch timeout value, default being 3 minutes, so if a BYE message arrives later than branch timeout expiry the records are deleted and the R-URI is not updated. The new header being Route and P-SR-XUID are still added as I can see from the debug log, but BYE relayed by kamailio contains improper R-URI user atpsh-5b619dee-5ca4-441.

I've tested this using automated shorter calls because we don't need to wait 3 minutes to notice that TTL is being set improperly.  When checking the debug I noticed that tps_redis_end_dialog() is called here, despite the BYE was not received yet:

Aug  1 14:59:03 sp1 lb[23716]: DEBUG: topos [tps_msg.c:182]: tps_add_headers(): adding to headers(1) - [Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK4c5e.5b0c6948caefcd8ffb1d106989768f80.0#015#012]
Aug  1 14:59:03 sp1 lb[23716]: DEBUG: topos [tps_msg.c:182]: tps_add_headers(): adding to headers(0) - [Contact: <sip:btpsh-5b619dee-5ca4-441 at 127.0.0.1>#015#012]
Aug  1 14:59:03 sp1 lb[23716]: DEBUG: topos_redis [topos_redis_storage.c:1381]: tps_redis_end_dialog(): updated on end the dialog record for [d:z:atpsh-5b619dee-5ca4-441] with argc 6
Aug  1 14:59:03 sp1 lb[23716]: DEBUG: topos_redis [topos_redis_storage.c:1412]: tps_redis_end_dialog(): expire set on branch record for [d:z:atpsh-5b619dee-5ca4-441] with argc 3

This matches the EXPIRES command time in the output of redis-cli monitor:

1533128343.178930 [24 127.0.0.1:48634] "HGETALL" "d:z:atpsh-5b619dee-5ca4-441"
1533128343.180122 [24 127.0.0.1:48634] "HMSET" "d:z:atpsh-5b619dee-5ca4-441" "rectime" "1533128343" "iflags" "0"
1533128343.180565 [24 127.0.0.1:48634] "EXPIRE" "d:z:atpsh-5b619dee-5ca4-441" "180"

Is it expected that tps_redis_end_dialog is called at all, changing the expiry and iflag?

#### Reproduction

Make a call with topos, ndb_redis and topos_redis modules loaded.
In our case, the call traverses the kamailio-lb instance twice, because there is a sems in between.

#### Debugging Data, log messages, traces

will be provided as an attachment
[dumps.tar.gz](https://github.com/kamailio/kamailio/files/2249809/dumps.tar.gz)

### Additional Information

version: kamailio 5.1.4 (x86_64/linux) 
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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_LISTEN 16, 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

* **Operating System**:

Linux sp1 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux

-- 
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/1608
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180801/35953987/attachment.html>