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