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

[Maxim Sobolev]

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,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com