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