8 Sep
2016
8 Sep
'16
12:07 p.m.
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.
-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?