Comments inline. Thanks -Rockson
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz Castillo Sent: Wednesday, September 17, 2008 4:51 PM Cc: [email protected] Subject: Re: [Sip-implementors] What should do a proxy if receives aCANCELafter forwarding a 200 OK ? 2008/9/17, Rockson Li (zhengyli) <[EMAIL PROTECTED]>: > Hi, imagine A calls B via proxy P: > > - A sends the INVITE to P. > - P forwards to B. > - B replies a 200 OK that arrives to P (this would cause proxy core to > terminate the client transaction). > > > [RL] Does P forward the 200 back or not , when it receives CANCEL from A? P receives the 200 from B before the CANCEL from A. Also P forwards the 200 upstream, and later receives the CANCEL (sent by A before A received the 200 from P). Anyway I already understand it properly thank to Paul help. The conclusion is that client transaction in proxy is destroyed when receiving the 200 from B, but the server transaction in proxy remains existing [RL] if P forwards 200(INVITE) upstream before getting CANCEL, the INVITE server transaction is terminated as well. Therefore since both INVITE client/server transaction do not exist anymore. Respone context is not present any longer. So as per RFC3261 sec 16.10 If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously). The same sec also says only response context is found, proxy core would send back 200(CANCEL). While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10. so it receives the CANCEL properly and replies a correct 200 (even if proxy will not generate a CANCEL since there are not in-progress client transactions). Thanks a lot. -- Iñaki Baz Castillo <[EMAIL PROTECTED]> _______________________________________________ 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
