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