5 Jan
2007
5 Jan
'07
6:57 p.m.
Hi Juha,
Thanks for the description, thanks to which I was able to reproduce and
fix the bug. The fix is on the CVS, both devel and 1.1.0 version.
Please reports if any side-effects popup.
Thanks and regards,
Bogdan
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
the parallel fork looks ok (as design) - on a
first look, the problem
seams to be related to some ACK-matching which leads to the 487
retransmission - could you please send me (privately) the pcap or ngrep
of the whole calls? it will be easier for me to debug.
this may be the same ACK matching problem that i noticed a week ago. i
just made some more tests and the problem can be repeated using openser
and any SIP UA (i used twinkle in my tests) as follows:
1) register a twinkle SIP UA using, for example, AoR
sip:twinkle1@domain, where domain is a domain OpenSER proxy under
test is responsible for.
2) add a permanent usrloc contact sip:twinkle2@domain for the same AoR
using same q value as in above. this creates a two-way fork when
sip:twinkle1@domain is called.
3) register another twinkle SIP UA using AoR sip:twinkle2@domain and on
that one, press "do not disturb" icon (the one with x), which causes
twinkle to respond to INVITE with 480.
4) from a third SIP UA, place call to sip:twinkle1@domain and wireshark
will show you that the second instance of OpenSER (the one that
t_relayed INVITE to twinkle2) does not match the ACK to 480 from the
first OpenSER instance (the one that forked the INVITE to twinkle1
and the second instance).
-- juha