On Tue, Sep 06, 2016 at 12:53:35PM +0200, Daniel-Constantin Mierla wrote:
-Route to the callee has trailing nulls (starting from the first ACK to the callee (packet 7 in pcap)) [...]
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?
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.