I think that the text does apply because it applies to ANY response on ANY client transaction and that would include the "completed" client transaction. If the request was forked by a downstream proxy, your proxy would see multiple responses on the same branch. The reason for this is the same as the reason given on page 107 in that it ensures that a "late" 2xx gets forwarded back to the UAC.
Imagine a downstream proxy has forked to two targets A and B. It gets a 480 from A and then times out on B a fraction of a second before B answers and sends a 200-OK. The downstream proxy would send the 480, and then when the 200 OK was received on the other branch it would forward it upstream. Your proxy would see a 480 and then a 200 on the same branch. The proxy cannot know the state of the UAs and in keeping with the end-to-end principle, it should forward the 2xx back to the UAC and let it decide what to do (such as ACK and BYE). If the proxy ignores the 2xx, it will likely receive 2xx retransmission from B. cheers, (-:bob -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Iñaki Baz Castillo Sent: Tuesday, May 10, 2011 9:10 AM To: Bob Penfield Cc: [email protected] Subject: Re: [Sip-implementors] Proxy receives 200 for INVITE while in "completed" state 2011/5/10 Bob Penfield <[email protected]>: > In RFC 3261, section 16.7 (Response Processing for proxies) on page 110, it > says: > > After a final response has been sent on the server transaction, > the following responses MUST be forwarded immediately: > > - Any 2xx response to an INVITE request > > Thus the proxy must forward the 2xx when the client transaction is in the > "completed" state. Hi Bob, I meant that the 2xx arrives with same Via branch as a 4xx received before. So in this case there is just a single client transaction in the proxy so text above is not longer valid. This is: 1) Proxy creates a client transaction and receives a 4XX => completed state. 2) Later a 2XX arrives with same branch (so it's matched by the same client transaction as there is no more client transactions). 3) IMHO it's clear that it should be ignored. Again: it's not a 2xx received within a different client transaction. Point 2 should never occur, but I'm in the case that a broken UAS or downstream proxy forwards such 2XX response. > If the client transaction has already been deleted, then this text (on page > 107) applies: > When a response is received by an element, it first tries to locate a > client transaction (Section 17.1.3) matching the response. If none > is found, the element MUST process the response (even if it is an > informational response) as a stateless proxy (described below). If a > match is found, the response is handed to the client transaction. > > Forwarding responses for which a client transaction (or more > generally any knowledge of having sent an associated request) is > not found improves robustness. In particular, it ensures that > "late" 2xx responses to INVITE requests are forwarded properly. > > Therefore, the proxy always forward all 2xx responses to INVITE. This is not true after RFC 6026 ;) -- 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
