Hi all, To supplement the concern that forwarding of non-matched *requests* by the stateful proxy is wrong, here is the excerpt from rfc3261 regarding the processing of *responses *after the changes introduced in rfc6026 are applied:
16.7 Response Processing When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If a transaction is found, the response is handed to the client transaction. * If none is found, the element MUST NOT forward the response.* The attention is to the last sentence. But there was no clarification introduced to clarify the behavior with CANCEL. Regards, Brez On Tue, Apr 19, 2011 at 3:48 PM, Worley, Dale R (Dale) <[email protected]>wrote: > ________________________________________ > From: [email protected] [ > [email protected]] On Behalf Of Iñaki Baz > Castillo [[email protected]] > > It doesn't check the server transaction state. I expect that a > stateful proxy must only reply 200 for a CANCEL in case its associated > INVITE server transaction is in Proceeding state (no final response > has been sent yet). > > So, if a proxy receives a CANCEL for an INVITE transaction whose > server transaction is in state Completed, Confirmed, Accepted or > Terminated, should the proxy reply 200? or 481? or nothing? > _______________________________________________ > > I don't remember the chapter-and-verse justification, but the practice > is that a CANCEL for an INVITE whose dialog is confirmed receives a > 200 response, even though it does not modify the dialog. > The UAC determines whether the CANCEL terminated > the INVITE attempt based on the response to the INVITE (200 vs. 487). > > Dale > > _______________________________________________ > 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
