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
