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

Alex Hermann alex at speakup.nl
Thu Mar 13 17:58:22 CET 2008


On Thursday 13 March 2008, Dan Pascu wrote:
> On Thursday 13 March 2008, Anatoly Pidruchny wrote:
> > Sending CANCEL to UAS after receiving 200 OK from the UAS will not
> > accomplish anything because it is a no-op according to the RFC. The UAS
> > will just ignore the CANCEL request. After UAS starts sending 200 OK
> > your only choice is to send ACK and BYE, or not to send anything and
> > let the INVITE transaction timeout in the UAS.
>
> I was expressing more of an idea for an alternate approach, out of the RFC
> specs, because as it is the RFC seems to not be able to cover this case.
> What I meant, is that if the CANCEL is sent after a 200 OK, but before the
> ACK, it should mean that the call is no longer desired (it was canceled
> already).
The INVITE can't be cancelled anymore because the transaction is deleted in 
the UAS after sending the 200 OK (and it is not allowed to send more than 1 
final response), so there is no way to indicate that the INVITE is cancelled.

If you looking for way to extend/change the SIP rfc's, why not allow a BYE 
instead of the ACK, or introduce a NACK request to get the wanted behaviour?


> Of course as it is now, any device that is RFC conformant will ignore that
> CANCEL, but if this callflow would be a valid one, devices could cope
> with scenarios like the ones discussed in this thread.
What happens (in practice) if you send a BYE instead of the ACK?

-- 
Greetings,

Alex Hermann



More information about the Devel mailing list