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

[Sachin Shenoy <sachins@netlab.hcltech.com>]

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" <sachins@netlab.hcltech.com>
> > >
> > > > 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.