On Mon, Aug 22, 2016 at 09:19:52AM +0200, Daniel-Constantin Mierla wrote: Just tried it, makes no difference. The patch to the topos module is only a few lines (ignoring docu and include stuff). Taking a look at the database entries during the call for the same scenario, the record-routes from callee are never set. a_rr contains the RR for the proxy of the caller (109.235.32.57), s_rr contains the registrar 185.61.68.106. b_rr is always empty (109.235.32.5[56] are nowhere to be found). select * from topos_d \G *************************** 1. row *************************** id: 2 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad(a)10.0.3.169 a_uuid: atpsh-57bac150-95b9-2 b_uuid: btpsh-57bac150-95b9-1 a_contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.XX.YYY~5067~2 b_contact: as_contact: <sip:atpsh-57bac150-95b9-2@185.61.68.106> bs_contact: <sip:btpsh-57bac150-95b9-1@185.61.68.106> a_tag: a90e54420669b32b b_tag: a_rr: <sip:109.235.32.57;r2=on;lr>,<sip:109.235.32.57;transport=tcp;r2=on;lr> b_rr: s_rr: <sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--> iflags: 0 a_uri: b_uri: r_uri: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 2. row *************************** id: 6 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad(a)10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: btpsh-57bac150-95b3-3 a_contact: sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.XX.YYY~5067~2 b_contact: sip:%2b31880100XXX@109.235.32.48 as_contact: <sip:atpsh-57bac150-95b3-4@185.61.68.106> bs_contact: <sip:btpsh-57bac150-95b3-3@185.61.68.106> a_tag: a90e54420669b32b b_tag: as1057e8ba a_rr: <sip:109.235.32.57;r2=on;lr>,<sip:109.235.32.57;transport=tcp;r2=on;lr> b_rr: s_rr: <sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--;vst=AAAAABsLCQgJAAEHAQRxQCkDRxlaChtNAUJubA--> iflags: 1 a_uri: b_uri: r_uri: a_srcaddr: b_srcaddr: a_socket: b_socket: select * from topos_t\G *************************** 1. row *************************** id: 2 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad(a)10.0.3.169 a_uuid: atpsh-57bac150-95b9-2 b_uuid: btpsh-57bac150-95b9-1 direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.74e4ea1d55b7270623bfa1e09a1c087b.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK40d03cc06a039e02 x_vbranch: z9hG4bK1ed2.aaaca95f0dd4b05f301cf64ec2084687.0 x_rr: <sip:109.235.32.57;r2=on;lr>,<sip:109.235.32.57;transport=tcp;r2=on;lr> y_rr: s_rr: <sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--> x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 2. row *************************** id: 6 rectime: 2016-08-22 11:13:17 s_method: INVITE s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad(a)10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: btpsh-57bac150-95b3-3 direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.74e4ea1d55b7270623bfa1e09a1c087b.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK40d03cc06a039e02 x_vbranch: z9hG4bK1ed2.aaaca95f0dd4b05f301cf64ec2084687.1 x_rr: <sip:109.235.32.57;r2=on;lr>,<sip:109.235.32.57;transport=tcp;r2=on;lr> y_rr: s_rr: <sip:185.61.68.106;lr;ftag=a90e54420669b32b;did=a51.c112;vsf=AAAAAF9BSFZRd0JYQB1RQSMcRx5CaXRjby5ubA--;vst=AAAAABsLCQgJAAEHAQRxQCkDRxlaChtNAUJubA--> x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket: *************************** 5. row *************************** id: 18 rectime: 2016-08-22 11:13:23 s_method: ACK s_cseq: 37185 a_callid: 7ee02bf9e97ab0ad(a)10.0.3.169 a_uuid: atpsh-57bac150-95b3-4 b_uuid: direction: 0 x_via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK1ed2.2fa09a9197ea2b0b83dfb58916f805ad.0;i=4,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.XX.YYY;branch=z9hG4bK6abe56e55367de33 x_vbranch: z9hG4bK1ed2.5ed2954acf483e107d2b6edbdc4b5e3c.0 x_rr: y_rr: s_rr: x_uri: a_contact: b_contact: as_contact: bs_contact: x_tag: a90e54420669b32b a_tag: b_tag: a_srcaddr: b_srcaddr: a_socket: b_socket:

On 24/08/16 08:09, Daniel-Constantin Mierla wrote: Finally some time to look at the source code for it ... can you run with higher debug level for topos and grab the message printed by the module that is like "... compacted headers - a_rr: ... b_rr: ..."? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

I pushed a new commit, can you give it another try? Cheers, Daniel On 29/08/16 12:11, Daniel Tryba wrote: -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Well, I found a new bug. If the callee wants session-timers and sets the uac as refresher, the ACK on the 200 OK of the session-timer re-INVITE isn't handled correctly. The ACK will be send directly to the contact of the callee. If the callee designated the uas as refresher, all goes well. Attached a pcap showing this problem (the initial INVITE to the callee is missing for some reason (fragmented?)) and the topos related debugging from the timeperiod. BTW syslog is getting spammed with ERROR: topos [tps_storage.c:874]: tps_storage_load_dialog(): no dlg uuid provided these are related to locally generated OPTIONS by the dispatcher and nathelper modules.

On 31/08/16 15:57, Daniel Tryba wrote: I pushed a new commit, aiming to avoid overwriting record route set with session updates. Let me know if it makes the difference. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

On 02/09/16 12:33, Daniel Tryba wrote: What kind of memory is leaking? Private (pkg), shared or system memory? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

On 02/09/16 15:19, Daniel Tryba wrote: Interesting, grepping inside the topos module doesn't reveal any system malloc being used... maybe a side effect in other part, needs more debugging. Maybe you can test with valgrind. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

On 02/09/16 12:33, Daniel Tryba wrote: Couldn't spot the real reason to have those zeors in the route value, I added some trimming before inserting the header to see if it's from there. Can you give another try with latest master? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

On Tue, Sep 06, 2016 at 12:53:35PM +0200, Daniel-Constantin Mierla wrote: Zeros are fixed, also I'm not seeing any broken Via anymore (so far in 4 test calls > 30m). But I found a new problem instead. In attached pcap, the caller hangsup. It sends a BYE (packet 152) to sip:atpsh-57d1682c-5030-8@185.61.68.106 But that isn't routed to the correct destination. This only happens after some time (after session timers kick in), a short call (<45s) is disconnected properly. BYE sip:109.235.32.57;r2=on;lr SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK2b6e.361405330d3447114a61eeb9ea603166.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK2b6e.4b6ac03027a65b62fbc89dbba78d0f1a.0 Max-Forwards: 68 From: <sip:+31402938662@109.235.35.42>;tag=as2305c39a To: <sip:+31407110385@sipcluster2.pocos.nl>;tag=as2b8ad5c1 Call-ID: 5039a1370a53ec320a3b35e871e34441@109.235.35.42:5060 CSeq: 103 BYE Reason: Q.850;cause=16 Content-Length: 0 Contact: <sip:btpsh-57d1682c-5030-7@185.61.68.106> The RURI is broken, the Contact is not rewritten to the callees original Contact but topos variant, and the Vias are reconstructed.