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

Reply via email to