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

[Bogdan-Andrei Iancu]

Hi Maxim,

You stated:

<quote>
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.
</quote>

Is this based on RFC indication or a personal opinion? If RFC based, 
could you please point me out the relevant section?

I'm asking mainly because, following my own logic, I would rather say 
that once the transaction is cancelled on UAS side, no further attempts 
(read retransmissions) should be done on UAC side.

Thanks and regards,
Bogdan


Maxim Sobolev wrote:
> 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.
>
> Following diagram illustrates the problem.
>
> UAC            OPENSER            UAS1     UAS2     UAS3
>     ----INVITE->
>     <-100/INVITE
>                        ----INVITE->
>                        -------------INVITE->
>                        ----------------------INVITE->
>                        ----INVITE->
>                        -------------INVITE->
>                        ----------------------INVITE->
>                        ----INVITE->
>                        -------------INVITE->
>                        ----------------------INVITE->
>                        ----INVITE->
>                        -------------INVITE->
>                        ----------------------INVITE->
>                        ----INVITE->
>                        -------------INVITE->
>                        ----------------------INVITE->
>     ----CANCEL->
>     <-200/CANCEL
>     <-487/INVITE
>     <-487/INVITE
>     <-487/INVITE
>     ----CANCEL->
>     <-200/CANCEL
>                        <-180/INVITE
>                        ----CANCEL->
>                        <-486/INVITE---------
>                        ----------------ACK->
>                        ----CANCEL->
>     <-487/INVITE
>                        ----CANCEL->
>     -------ACK->
>                        ----CANCEL->
>                        <-200/CANCEL
>                        <-487/INVITE
>                        -------ACK->
>                        <-487/INVITE
>                        -------ACK->
>
> Regards,
>