I think what Shiv is trying to depict is : 1. UAC has sent out on INVITE 2. UAC doesn't get a response in it's time 3. Timer B (as per INVITE transaction) expires and it goes onto the Terminated state. 4. Now you get the responses (provisional/ final) from the other side.
IMHO, you should drop such packets. Once the INVITE reaches the Terminated state, it would have no knowledge of the call-id, etc recvd in the response.. So just drop it. The UAS would anyway wait for the ACK and timeout itself.. Something similar to rogue packet arrivals. cheers - Ben. --- On Tue, 10/14/08, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote: > From: Iñaki Baz Castillo <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] re-transmission timer for UAC transaction > (INVITE) failed. > To: > Cc: [email protected] > Date: Tuesday, October 14, 2008, 9:01 AM > 2008/10/14 SHIV SINGH <[EMAIL PROTECTED]>: > > Hi All, > > Here I need some clarification on the following issue. > > > > I have generated an INVITE from UAC side and sent it > to UAS but the re-transmission timer for this INVITE at UAC > got failed. > > > > Now in this case what should be my UAC's behavior > for further responses like 1xx, 2xx etc. > > Should I need to generate ACK for 2xx or I need to > discard 2xx as invalid message? > > > I don't understand properly, do you mean the following? > > - UAC sends INVITE to UAS. > - Timer expires in UAC so it should send a retransmission. > - But the fact is that the timer fails?? what does it mean? > - UAS send the 200 OK, later but it sends it. > - UAC receives it. > > Is it the case? > > -- > 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
