Subject: [Sip] Fwd: Re: [Sip-implementors] Response retransmission

From: Sachin Shenoy <[email-masked]>
Date: Fri, 27 Dec 2002 03:37:15 +0530

Hi,
Following an earlier thread from sip-implementors here is another
scenario that leads to similar problem.

Suppose UAC sends an INVITE out and receives 2 provisional
response with different to-tags. These 2 provisional response would
be handled by the same client transaction as both of the would have
the same top-most branch-id (even though they have different to-tags)
They will create 2 early dialogs. Now suppose, one of the early dialog
matures with a 2xx response. This would immediately delete the client
transaction. Now, let the other dialog be terminated with a 4xx.

1. Should we send ACK for this 4xx?
2. If yes, Who  should send the ACK for this 4xx. TU? or TL?
3. Also, how should it be sent. Should we create a new client transaction
     for this purpose?

RFC 3261 Section 17.1.1.2 Formal Description, says,

"The client transaction
    MUST pass the received response up to the TU, and the client
    transaction MUST generate an ACK request, even if the transport is
    reliable (guidelines for constructing the ACK from the response are
    given in Section 17.1.1.3) and then pass the ACK to the transport
    layer for transmission.  The ACK MUST be sent to the same address,
    port, and transport to which the original request was sent."

Now, in our case as we don't have client transaction we have lost
all the context regarding the original transaction. Should we create
a new client transaction and send the ACK using it. If this is done,
then we would have another problem. Re transmissions of the 2xx
for the matured dialog would hit on this client transaction (since
they would have the same branch-id's). Due to this the 2xx won't
be indicated to the TU at all. As I said earlier (see below mail) I still
think that this should be explicitly stated in the RFC. Making this
explicit would ensure that implementors don't accidentally over look
this point.

Thanks
Sachin

>Sorry, I think correction might be required not in Response matching but in
>FSM Figure 5: INVITE client transaction.
>
>We need to add one more event in "Completed" state,  event 2xx.
>In "Completed" state if we recieve a 2xx we would indicate it to TU.
>
>Hope I got it right.
>
>Thanks
>Sachin
>
>
>At 07:24 PM 7/24/02 +0530, you wrote:
>>Hi Bob,
>>
>>According to RFC 3261 17.1.3 "Matching Responses to Client Transactions",
>>It is said that client transaction for response is matched using
>>topmost via-branch & Cseq method.
>>
>>I guess this will have to be changed if we have to forward the 2xx also.
>>
>>Since the response context for 4xx would be still active, when a
>>2xx comes, according to RFC, we will match it with the 4xx's response
>>context. We will end up retransmitting ACK (not knowing that it is 2xx
>>but thinking that it is a 4xx).
>>
>>Hope I didn't miss anything over here.
>>
>>Thanks
>>Sachin
>>
>>
>>At 09:40 AM 7/24/02 -0400, you wrote:
>>
>>>----- Original Message -----
>>>From: "Sachin Shenoy" <[email-masked]>
>>>
>>> > Hi,
>>> >
>>> > If a proxy sends out an INVITE statefully, and gets a non-2xx response
>>>(say
>>> > 4xx),
>>> > it will send out an ACK locally. Now if it gets 2xx on the same branch,
>>> > it would consider this 2xx as retransmission of 4xx and retransmit ACK.
>>> > (Since 4xx & 2xx would have the same top-most via branch)
>>> >
>>> > (It may end up getting 2xx after forwarding 4xx due to a mis-behaving
>>>proxy
>>> > down the line, which forked the INVITE?).
>>> >
>>> > Is this behaviour Ok?
>>> >
>>>
>>>No.
>>>
>>>If this proxy did receive a 2xx after receiving a 4xx, it would mean a
>>>downstream (not necessarily mis-behaving) proxy had given up on waiting for
>>>a response on a given branch. The 2xx and 4xx would not have come from the
>>>same UAS.
>>>
>>>The proxy should not send an ACK for the 2xx, but should forward the
>>>response back toward the UAC. ACK for non-2xx is hop-by-hop, but ACK for 2xx
>>>is end-to-end and it is a request within the dialog established/identified
>>>by the 2xx.
>>>
>>>If the UAC had already given up on the call, it would send a BYE after
>>>sending the ACK.