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:[EMAIL PROTECTED], where domain is a domain OpenSER proxy under
test is responsible for.
2) add a permanent usrloc contact sip:[EMAIL PROTECTED] for the same AoR
using same q value as in above. this creates a two-way fork when
sip:[EMAIL PROTECTED] is called.
3) register another twinkle SIP UA using AoR sip:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
