I agree with Paul here, Actually the 200(CANCEL) just means the proxy got the CANCEL, It does not mean the request is cancelled or proxy would be ensure the req being cancelled. Normally, Proxy would send the CANCEL downstream, however, since there's no provisional resp, Proxy has no means to complete the task. UAC should be prepared to get the 200(INVITE) and reacts accordingly.
Thanks -Rockson -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Tuesday, December 23, 2008 9:24 AM To: Iñaki Baz Castillo Cc: [email protected] Subject: Re: [Sip-implementors] CANCEL - 200 IINVITE crossover. I don't understand why stateless forwarding has been mentioned in the context of this question. AFAIK it has no relevance. If we assume that the pcscf in the question is a transaction stateful proxy (and I'm pretty certain that any IMS implementation would be), then when the 200 INVITE is received, there *will* be a matching transaction for it. The original responder is correct - there is no problem here at all. The UAC must be prepared to receive a 200 even though it sent a CANCEL, and it then may do whatever it wants (after sending the ACK) - it can keep the call, send a BYE to the call, ... Thanks, Paul Iñaki Baz Castillo wrote: > 2008/12/22 Maxim Sobolev <[email protected]>: > >>> Alto consider the following draft: >>> http://tools.ietf.org/html/draft-sparks-sip-invfix-02 >>> >>> It states that a transaction statefull proxy mustn't forward a 200 >>> stateless, so in your case the 200 OK wouldn't arrive to the UAC (if >>> the proxy honors the above draft). >> No, I believe your reading is incorrect. If proxy somehow absorbs 200 >> OK so that it won't arrive to UAC in such situation then the dialog >> would remain in half-connected state - with UAS retransmitting 200 OK >> waiting for E2E ACK (proxy can't generate E2E ACK) and UAC still >> waiting for the final negative or positive response to its INVITE >> transaction. Eventually UAS would timeout and probably generate BYE >> in a desperate attempt to tear down the dialog, but since UAC has not >> received final response to INVITE it would reject BYE as out-of-order >> and continue waiting indefinitely (probably until transaction >> expiration timer hits). This would make things even more broken than they >> were in the example above. > > Ok, so a proxy implementing draft-sparks-sip-invfix-02 just can drop a > stateless 200 OK for an INVITE in case it knows nothing about that > transaction. In the case above the proxy does know about the INVITE > transaction since it still has no final reply for it (even if the > proxy has received a CANCEL from upstream). > > Thanks for pointing it. > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
