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

Dan Pascu dan at ag-projects.com
Thu Mar 6 17:45:51 CET 2008


On Thursday 06 March 2008, Bogdan-Andrei Iancu wrote:
> 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 got the same impression that Maxim is trying to solve a problem not 
related to SIP (network packet loss) by hacking the SIP behavior and 
there is nothing in the RFC that would require the behavior he proposed. 
Even more what he proposed is not even a fullproof solution as it may 
work, but it may not, depending on how big the network packet loss is.
There's an assumption in his proposal that if you keep retransmitting, 
somehow it will get a provisional reply back at some point, but it may 
not, so your phone will keep ringing and the whole logic will not help at 
all. 

IMO network packet loss issues should  be solved at the network level 
(routers/switches) not at SIP protocol level by adding a complex 
transaction retaining mechanism. The way we should think of this issue, 
is in terms of what happens with the whole proposed logic if there is no 
packet loss (normal situation). In that case if you keep waiting on a leg 
that has not sent a provisional reply (because it simply is not there), 
and you keep retransmitting an INVITE even after the originator has 
canceled the call, it would be a waste of time and resources, not to 
mention silly, just for trying to solve a problem that has nothing to do 
with SIP signaling.

I believe that the current logic is correct. Once the originator has 
canceled the call, the proxy should cease retransmission on all legs and 
either cancel them if they have already replied or simply drop them if 
they have not.

>
> 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,
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/devel



-- 
Dan



More information about the Devel mailing list