### Description
I have an instance of Kamailio running with topos module enabled as described bellow:
(Core network) <---> (**Kamailio** running on 192.168.70.106:5061) <--> (Provider network)
Here is the scenario: 1. An INVITE comming from Core network through Kamailio to the Provider network and the call is established correctly (with 200 OK and ACK correctly routed). 2. The call is put on hold by the callee. A RE-INVITE comming from Provider network through Kamailio to the Core network. This REINVITE is routed correctly. 3. The Core network sent 200 OK reply to the RE-INVITE. The 200 OK message reached the Kamailio and was dropped there. (It SHOULD go back to the Provider network).
#### Log Messages
<!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
When Kamailio received this 200 OK, I see this log message: ``` ERROR: topos [tps_storage.c:1299]: tps_db_update_dialog(): no valid dlg uuid (0: - 0:) ```
#### SIP Traffic
<!-- If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
**Here is the REINVITE message arriving from our provider:**
``` INVITE sip:btpsh-5acddf40-d74-5@192.168.70.106:5061 SIP/2.0 Call-ID: 79acbb714c21354c Contact: sip:80.10.231.10:5060;transport=udp Content-Type: application/sdp CSeq: 1 INVITE From: sip:xxxx@xxxx;user=phone;tag=SDt2dkc98-04020267673121 Max-Forwards: 63 Record-Route: sip:192.168.70.126:5060;user=i0o0S000000ad;lr;Cpkt=XWJOA;C=xxxx,sip:192.168.70.126:5070;user=00000214;lr;Cpkt=YJJEE;C=xxx To: sip:+yyyy@xxxx;user=phone;tag=1713351228 Via: SIP/2.0/UDP 192.168.70.126:5060;branch=z9hG4bK-XWJO-000227ab-7eda6242,SIP/2.0/UDP 192.168.70.126:5070;received=192.168.70.126;rport=5070;branch=z9hG4bK-YJJE-000a057c-0bf8ef7c,SIP/2.0/UDP 193.200.4.20:5060;emission,SIP/2.0/UDP 80.10.231.10:5060;received=80.10.231.10;rport=5060;branch=z9hG4bK5g8vgn00cobc0atd6hf0sb0000g00.1 Accept: application/sdp Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,PRACK Content-Length: 236 ```
**Here is the REINVITE comming out of Kamailio into our core side:**
``` INVITE sip:192.168.40.106:5090;did=d03.e3be0354 SIP/2.0 Via: SIP/2.0/UDP 192.168.70.106:5061;branch=z9hG4bK443f.2ec12863719a69f1e3851178d9cb21d0.0 Call-ID: 79acbb714c21354c Content-Type: application/sdp CSeq: 1 INVITE From: sip:+xxx@xxxx;tag=SDt2dkc98-04020267673121 Max-Forwards: 62 To: sip:xxx@xxxx;tag=1713351228 Accept: application/sdp Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,PRACK Content-Length: 236 Route: xxx Contact: sip:atpsh-5acddf40-d75-5@192.168.70.106:5061 ```
**Here is the 200 OK for this REINVITE message comming from the Core network** (This message arrived to Kamailio but is never sent to our provider).
``` SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.70.106:5061;branch=z9hG4bK443f.2ec12863719a69f1e3851178d9cb21d0.0 From: sip:+xxx@xxxx;tag=SDt2dkc98-04020267673121 To: sip:xxx@xxxx;tag=1713351228 Call-ID: 79acbb714c21354c CSeq: 1 INVITE Contact: sip:192.168.40.106:5090;did=d03.e3be0354 Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO Content-Type: application/sdp Content-Length: 197 ```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
kamailio 5.1.2
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) -->
Centos Linux 3.10.0-514.26.1.el7.x86_64
* **Database**:
PostgreSQL 9.4
Can you reproduce the issue and paste here the corresponding records from database tables topos_d and topos_t? Add again also the new SIP requests and replies in order to match with what is in the database.
Table topos_d and topos_t before the REINVITE:
**topos_d:** (id;rectime;s_method;s_cseq;a_callid;a_uuid;b_uuid;a_contact;b_contact;as_contact;bs_contact;a_tag;b_tag;a_rr;b_rr;s_rr;iflags;a_uri;b_uri;r_uri;a_srcaddr;b_srcaddr;a_socket;b_socket)
470690;2018-04-11 18:09:23;INVITE;55;4569feb56b789d59;atpsh-5ace25f2-4b35-b3;btpsh-5ace25f2-4b35-b3;sip:192.168.40.106:5090;did=a32.3f8a5df4;sip:82.15.231.95:5060;transport=udp;sip:atpsh-5ace25f2-4b35-b3@192.168.5.105:5061;sip:btpsh-5ace25f2-4b35-b3@192.168.5.105:5061;867365243;SDv1r6a98-13050752699891;sip:192.168.5.105;lr;ftag=867365243;did=a32.cba2,sip:192.168.5.97;lr,sip:192.168.5.97:5071;r2=on;lr,sip:192.168.1.2;r2=on;lr,sip:192.168.1.3;r2=on;lr,sip:192.168.40.106;r2=on;lr;sip:Cpkt=VOLHL;C=mysbc@192.168.5.126:5070;transport=udp;user=00000146;lr,sip:Cpkt=DROHZ;C=mysbc@192.168.5.126:5060;transport=udp;user=i0o0S0000004b;lr;sip:192.168.5.105:5061;lr;ftag=867365243;did=a32.2682;vsf=AAAAABsKBA0ABw4KAQt4A3lBR0EYVVdVVV1NSEhaHlpfbTt1c2VyPXBob25l;vst=AAAAAAAAAAAAAAAAAAAAAABCUEIAXE9aS0dEXkNfGFlaXQJFc2VyPXBob25l;2;'';'';'';'';'';'';''
**topos_t:** ( id;rectime;s_method;s_cseq;a_callid;a_uuid;b_uuid;direction;x_via;x_vbranch;x_rr;y_rr;s_rr;x_uri;a_contact;b_contact;as_contact;bs_contact;x_tag;a_tag;b_tag;a_srcaddr;b_srcaddr;a_socket;b_socket )
530238;2018-04-11 18:09:23;INVITE;55;4569feb56b789d59;atpsh-5ace25f2-4b35-b3;btpsh-5ace25f2-4b35-b3;0;SIP/2.0/UDP 192.168.5.105;branch=z9hG4bK5d5a.102f35359bcb49266de28eaa36d67a7f.1,SIP/2.0/UDP 192.168.5.97:5060;branch=z9hG4bK5d5a.86ff4ed4.0,SIP/2.0/UDP 192.168.5.97:5071;branch=z9hG4bK5d5a.56b89f24.0,SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK5d5a.aa4557a1.0,SIP/2.0/UDP 192.168.40.106:5090;branch=z9hG4bK5d5a.8019cd1.0;z9hG4bK5d5a.ac330e4ffbd47b932890a9f893523d01.0;sip:192.168.5.105;lr;ftag=867365243;did=a32.cba2,sip:192.168.5.97;lr,sip:192.168.5.97:5071;r2=on;lr,sip:192.168.1.2;r2=on;lr,sip:192.168.1.3;r2=on;lr,sip:192.168.40.106;r2=on;lr;sip:Cpkt=VOLHL;C=mysbc@192.168.5.126:5070;transport=udp;user=00000146;lr,sip:Cpkt=DROHZ;C=mysbc@192.168.5.126:5060;transport=udp;user=i0o0S0000004b;lr;sip:192.168.5.105:5061;lr;ftag=867365243;did=a32.2682;vsf=AAAAABsKBA0ABw4KAQt4A3lBR0EYVVdVVV1NSEhaHlpfbTt1c2VyPXBob25l;vst=AAAAAAAAAAAAAAAAAAAAAABCUEIAXE9aS0dEXkNfGFlaXQJFc2VyPXBob25l;'';sip:192.168.40.106:5090;did=a32.3f8a5df4;sip:82.15.231.95:5060;transport=udp;sip:atpsh-5ace25f2-4b35-b3@192.168.5.105:5061;sip:btpsh-5ace25f2-4b35-b3@192.168.5.105:5061;867365243;867365243;SDv1r6a98-13050752699891;'';'';'';'' 530239;2018-04-11 18:09:36;ACK;55;4569feb56b789d59;atpsh-5ace25f2-4b36-03;btpsh-5ace25f2-4b36-03;0;SIP/2.0/UDP 192.168.5.105;branch=z9hG4bK5d5a.a88919e1cb8bf2f1d42935a9cec58422.0,SIP/2.0/UDP 192.168.5.97:5060;branch=z9hG4bK5d5a.86ff4ed4.2,SIP/2.0/UDP 192.168.5.97:5071;branch=z9hG4bK5d5a.56b89f24.2,SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK5d5a.aa4557a1.2,SIP/2.0/UDP 192.168.40.106:5090;branch=z9hG4bK5d5a.8019cd1.2;z9hG4bK5d5a.cb3299a7fc426f4083392a1ce0aa96de.0;'';'';sip:192.168.5.105:5061;lr;ftag=867365243;vsf=AAAAABsKBA0ABw4KAQt4A3lBR0EYVVdVVV1NSEhaHlpfbTt1c2VyPXBob25l;vst=AAAAAAAAAAAAAAAAAAAAAABCUEIAXE9aS0dEXkNfGFlaXQJFc2VyPXBob25l;'';sip:192.168.40.106:5090;did=a32.3f8a5df4;'';sip:atpsh-5ace25f2-4b36-03@192.168.5.105:5061;sip:btpsh-5ace25f2-4b36-03@192.168.5.105:5061;867365243;867365243;SDv1r6a98-13050752699891;'';'';'';''
**Talbe topos_d and topos_t after the REINVITE:**
530278;2018-04-11 18:12:37;INVITE;1;4569feb56b789d59;atpsh-5ace25f2-4b35-14;btpsh-5ace25f2-4b35-14;0;SIP/2.0/UDP 192.168.5.126:5060;branch=z9hG4bK-SFZG-000230d8-7c09d8ed,SIP/2.0/UDP 192.168.5.126:5070;received=192.168.5.126;rport=5070;branch=z9hG4bK-KPYA-000a1294-7c1a40f5,SIP/2.0/UDP 193.200.4.20:5060;emission,SIP/2.0/UDP 82.15.231.95:5060;received=82.15.231.95;rport=5060;branch=z9hG4bKplevej008galt19on9o0sb0000g00.1;z9hG4bK1727.96ac238572c53104ff44ce2bb733e79d.0;sip:192.168.5.126:5060;user=i0o0S0000004b;lr;Cpkt=SFZGM;C=mysbc,sip:192.168.5.126:5070;user=00000146;lr;Cpkt=KPYAH;C=mysbc;'';sip:192.168.5.105:5061;lr;ftag=867365243;did=a32.2682;vsf=AAAAABsKBA0ABw4KAQt4A3lBR0EYVVdVVV1NSEhaHlpfbTt1c2VyPXBob25l;vst=AAAAAAAAAAAAAAAAAAAAAABCUEIAXE9aS0dEXkNfGFlaXQJFc2VyPXBob25l;'';sip:82.15.231.95:5060;transport=udp;'';sip:atpsh-5ace25f2-4b35-14@192.168.5.105:5061;sip:btpsh-5ace25f2-4b35-14@192.168.5.105:5061;SDv1r6a98-13050752699891;SDv1r6a98-13050752699891;867365243;'';'';'';''
530281;2018-04-11 18:12:41;BYE;2;4569feb56b789d59;atpsh-5ace25f2-4b36-53;btpsh-5ace25f2-4b36-53;0;SIP/2.0/UDP 192.168.5.126:5060;branch=z9hG4bK-WJXP-000230dc-09bd59e8,SIP/2.0/UDP 192.168.5.126:5070;received=192.168.5.126;rport=5070;branch=z9hG4bK-RERI-000a1298-3421dde5,SIP/2.0/UDP 193.200.4.20:5060;emission,SIP/2.0/UDP 82.15.231.95:5060;received=82.15.231.95;rport=5060;branch=z9hG4bKplevej008galt19on9o0sd0000010.1;z9hG4bKe627.904c4af7f4452623da33c28a4a59b67d.0;sip:192.168.5.126:5060;user=i0o0S0000004b;lr;Cpkt=WJXPB;C=mysbc,sip:192.168.5.126:5070;user=00000146;lr;Cpkt=RERIE;C=mysbc;'';sip:192.168.5.105:5061;lr;ftag=867365243;vsf=AAAAABsKBA0ABw4KAQt4A3lBR0EYVVdVVV1NSEhaHlpfbTt1c2VyPXBob25l;vst=AAAAAAAAAAAAAAAAAAAAAABCUEIAXE9aS0dEXkNfGFlaXQJFc2VyPXBob25l;'';'';'';sip:atpsh-5ace25f2-4b36-53@192.168.5.105:5061;sip:btpsh-5ace25f2-4b36-53@192.168.5.105:5061;SDv1r6a98-13050752699891;SDv1r6a98-13050752699891;867365243;'';'';'';''
**SIP messages:**
**RE-INVITE from provider network to Kamailio:** INVITE sip:btpsh-5ace25f2-4b35-b3@192.168.5.105:5061 SIP/2.0 Call-ID: 4569feb56b789d59 Contact: sip:82.15.231.95:5060;transport=udp Content-Type: application/sdp CSeq: 1 INVITE From: sip:+33600000000@sip.mybestpro.com;user=phone;tag=SDv1r6a98-13050752699891 Max-Forwards: 63 Record-Route: sip:192.168.5.126:5060;user=i0o0S0000004b;lr;Cpkt=SFZGM;C=on-cirpack,sip:192.168.5.126:5070;user=00000146;lr;Cpkt=KPYAH;C=on-cirpack To: sip:+33900000000@sip.mybestpro.com;user=phone;tag=867365243 Via: SIP/2.0/UDP 192.168.5.126:5060;branch=z9hG4bK-SFZG-000230d8-7c09d8ed,SIP/2.0/UDP 192.168.5.126:5070;received=192.168.5.126;rport=5070;branch=z9hG4bK-KPYA-000a1294-7c1a40f5,SIP/2.0/UDP 193.200.4.20:5060;emission,SIP/2.0/UDP 82.15.231.95:5060;received=82.15.231.95;rport=5060;branch=z9hG4bKplevej008galt19on9o0sb0000g00.1 Accept: application/sdp Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,PRACK Content-Length: 236
**RE-INVITE from Kamailio to Core network:** INVITE sip:192.168.40.106:5090;did=a32.3f8a5df4 SIP/2.0 Via: SIP/2.0/UDP 192.168.5.105;branch=z9hG4bK1727.761dc5b7a9039a54ae0b51ceb9b728ef.0 Via: SIP/2.0/UDP 192.168.5.105:5061;branch=z9hG4bK1727.96ac238572c53104ff44ce2bb733e79d.0 Call-ID: 4569feb56b789d59 Content-Type: application/sdp CSeq: 1 INVITE From: sip:+33600000000@192.168.40.106:5090;tag=SDv1r6a98-13050752699891 Max-Forwards: 61 To: sip:0900000000@192.168.5.98:5090;tag=867365243 Accept: application/sdp Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,PRACK Content-Length: 236 Route: sip:192.168.5.97;lr,sip:192.168.5.97:5071;r2=on;lr,sip:192.168.1.2;r2=on;lr,sip:192.168.1.3;r2=on;lr,sip:192.168.40.106;r2=on;lr P-Asserted-Identity: sip:+33600000000@sip.mybestpro.com Contact: sip:atpsh-5ace25f2-4b35-14@192.168.5.105:5061
**200 OK going back to Kamailio from Core network:** SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.5.105;branch=z9hG4bK1727.761dc5b7a9039a54ae0b51ceb9b728ef.0 Via: SIP/2.0/UDP 192.168.5.105:5061;branch=z9hG4bK1727.96ac238572c53104ff44ce2bb733e79d.0 From: sip:+33600000000@192.168.40.106:5090;tag=SDv1r6a98-13050752699891 To: sip:0900000000@192.168.5.98:5090;tag=867365243 Call-ID: 4569feb56b789d59 CSeq: 1 INVITE Contact: sip:192.168.40.106:5090;did=a32.3f8a5df4 Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO, PING Content-Type: application/sdp Content-Length: 197
By searching in the code, I found that the error message I had *no valid dlg uuid (0: - 0:)* is found only in the function tps_storage_update_dialog.
From my log file, I can say that this error message was showing during the handling of the 200 OK (of the RE-INVITE). Hence I suppose that the error message was logged by the call to the function tps_storage_update_dialog inside the function tps_response_received (tps_msg.c:900).
Inside the function tps_response_received , the function *tps_storage_update_branch* is called before the function *tps_storage_update_dialog*. The fact that *tps_storage_update_dialog* got called meant that the call to *tps_storage_update_branch* had succeeded.
In order for the function *tps_storage_update_branch* to succeed, the dialog must have been found from database. I don't understand **why tps_storage_update_branch found the dialog but tps_storage_update_dialog didn't** (they use the same conditions to check for dialog validity).
Can you try with latest master branch? I pushed a patch to it, let's see if it fixed and then can be backported.
It works @miconda. Thank you very much!
Well, it only worked once... Now I am having the problem of infinite loop when routing the first INVITE of a new dialog. As if the dialog of an already hung up call is reused for new calls... I am investigating and will update this ticket with any new finding.
OK, thanks for testing and feedback. I am going to backport to stable branch.
Closed #1496.