RE: [Sip-implementors]Must Proxy forward or drop a 4xx, when 2xx is got from other leg?

[uprakash]

Hi,   But the RFC says to forward the response statelessly when there is no matching client transaction. Please see the comments inline.. -----Original Message----- From: Nataraju A.B. [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 3:17 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Must Proxy forward or drop a 4xx, when 2xx is got from other leg?   ----- Original Message ----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 1:44 PM Subject: RE: [Sip-implementors] Must Proxy forward or drop a 4xx, when 2xx is got from other leg? Hi, Please see my comments inline... -----Original Message----- From: Nataraju A.B. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 3:07 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Must Proxy forward or drop a 4xx, when 2xx is got from other leg? ----- Original Message ----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 1:29 PM Subject: [Sip-implementors] Must Proxy forward or drop a 4xx, when 2xx is got from other leg? Hi All, I have a query in Forking Proxy behaviour. (Incase this query has already been discussed, please give a pointer to that mail thread) The scenario is as below: The Proxy gets a 4xx from the other branch,after it has got a 2xx from the first branch. Now should the Proxy forward this 4xx (or) drop this? As per RFC Clause:16.7 Item9 ---------------------------------- If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport. =>This means that 4xx has to be FORWARDED statelessly as the Server Transaction(ST) would have been deleted,as soon as forwarding the 2xx. As per RFC Clause:16.7 Item5 ---------------------------------- 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 A stateful proxy MUST NOT ***immediately*** forward any other responses. => This means that 4xx has to be DROPPED(?). =>Here,***immediately*** refers to till some timer value or indefinitely? These 2 clauses creates an ambiguity as to what is the expected behaviour........... Can someone please clarify? [ABN]            here the 4xx must not be forwarded back UAC, it must be DROPPED ...... here ,***immediately*** means no need wait for response staus on other clients (If there are any)   [Prakash]=> Suppose I send a 4xx response,after say 10-15 minutes instead of immediately, then what the Proxy is supposed to do?Forward it statelessly? [ABN] If there is no matching transaction then there is no need forward an failure response, since the response forwarding is purely based on Via header. This could be the case when the a failure resposne received after it could have been timed out @ this proxy.....    [Prakash]=>   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 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.   Following this Clause, I guess that late responses must be forwarded statelessly. Please let me know if I am missing something here. Thanks, Prakash.   Thanks, Prakash. #   [UAC]       [PROXY]    [UAS_A]         [UAS_B] #     |     INV      |              |               | #     |----------> |              |               | #     |     100      |             |               | #     |<-----------|    INV    |               | #     |                |--------->|               | #     |                |            INV              | #     |                |----------------------->| now there are 2 CT and 1 ST. #     |                |     200    |               | #     |     200      |<---------|               | #     |<-----------|              |               | now there will be only 1 CT and NO STs. #     |              |             486              | #     |              |<------------------------| #     |  486(?)  |                |               | #     | forward?|                |               | #     |<---------|                |               | #     |              |            ACK(?)           | #     |              |            drop?             | #     |              |------------------------>| #     |              |                |               | #     |              |                |               | # Thanks, Prakash. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors