On Thursday 13 March 2008, Juha Heinanen wrote: > Dan Pascu writes: > > Do you have any suggestion how can this be at least addressed, if > > not solved, using the current RFC framework? > > i haven't followed the proposed solutions in detail, but the solution > does not need to be RFC complaint as long as it does not assume any > changes in rfc complaint UAs.
I thought this through, and to be honest, I do not think this can be solved without cooperation from the UAs. Even more it can't be solved without adding something new to the current framework the RFC provides. Consider the case where the caller sends the CANCEL and the callee at the same time sends the 200 OK. They will intersect in the proxy, but when the callee receives the CANCEL it'll ignore it under the current RFC assumptions about the call setup, because once it has sent the 200 OK, it considers the session as started. Even if the caller ignores the 200 OK or use an ACK+BYE to end the session, the session is still established. Unless something is changed in the equation there is no way for the caller/proxy to indicate to the callee that it should stop because a CANCEL was already received. This new thing, can be something that changes the way processing is supposed to happen with the existing RFC specifications. For example: 1. A CANCEL could be accepted by the callee even after a 200 OK, but before the ACK and its meaning in this context would be that the call was just CANCELED before having a chance to be fully set up and it should be dropped. 2. Some new method like the proposed NACK, which could have the same meaning. Personally I would go with choice 1, as it diverges less from the current specs and only extends the meaning of the CANCEL a bit, otherwise it has the same effect as the 2nd which would require the addition of a new method that is harder to get done. But as you can see both need the cooperation of the UA. Otherwise we could apply 1 right now in the proxy, but it would most likely be completely ignored by all UAs out there. -- Dan _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
