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

Dan Pascu dan at ag-projects.com
Thu Mar 13 18:57:16 CET 2008


On Thursday 13 March 2008, Alex Hermann wrote:
> > 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.

With the current RFC specs, yes. But if the CANCEL would be allowed to be 
sent until the dialog is confirmed by the ACK, then the UAS would be 
required to keep the transaction around until ACK-ed and could process 
this case.

>
> 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?

I'm sure there is more than one way to do this. The NACK sounds the 
simplest and least disruptive of all the ideas mentioned so far.

>
> > 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?

I don't know, but a BYE sounds too much like the sessions is already 
established and needs to be closed.

-- 
Dan



More information about the Devel mailing list