[OpenSER-Devel] [Serdev] Possible bug in the tm module in the presence of packet loss/branches

[Klaus Darilion]

Maxim Sobolev schrieb:
> Hi,
> 
> Disclamer: we discovered this issue with OpenSER 1.3, but it might be 
> something affecting SER as well, so that I am cross-posting it there.
> 
> Basically it looks like there is an issue with transactional CANCEL 
> processing, potentially related to the presence of packet loss and/or 
> branching.
> 
> In a nutshell the situation looks like the following: the call comes in 
> to the proxy, and gets forked into three locations using 
> lookup()/t_relay() functions. Apparently there is some kind of network 
> blackout, since proxy is not getting 100 Trying and does several INVITE 
> retransmits on all 3 egress legs. After about 5 seconds it gets CANCEL 
> from the originating party, it answers 200 to CANCEL and sends 487 for 
> the ingress leg.
> 
> Then it finally gets 180 Ringing from one leg, and 486 Busy Here from 
> another leg. At that time there has been no provisional response 
> received from the third leg. What it does next is ACK 486 and properly 
> relays CANCEL to the leg from which it has received 180 Ringing, BUT 
> (and that I think is the bug), it does absolutely nothing on third leg 
> from that point on. It doesn't relay CANCEL there, which is 
> RFC-compliant, since there has been no provisional response, however it 
> ceases INVITE retransmits to that leg as well, despite the fact that 
> only about 5 seconds has been passed since the first INVITE to that leg.
> 
>  From the user point of view, the phone that is a target of that 3rd leg 
> continues ringing non-stop (apparently it has received one of INVITEs 
> but provisional reply has been lost), until INVITE transaction expires 
> in the UAS, long after the initial call has been disconnected.
> 
> My guess is that receiving CANCEL somehow stops re-transmit timer on 
> appropriate INVITE, which is incorrect in the case when no provisional 
> response has been received on that transaction.
> 
> The correct behavior of the tm module in this case would be to continue 
> with INVITE re-transmits until we get provisional response and immediate 
> CANCEL once that response comes in.

Is this really the correct behavior? Is this behavior defined in RFC 3261?

regards
klaus