Hi Ashish, I am not sure. I think Timer B should not be active in proceeding state.
Here are some points which suggest that Timer B should not be active at proceeding state: 1. The specification does not explicitly say that timer B should be running in proceeding state. 2. The specification does not say what one needs to do if timer B fires in proceeding state. 3. If timer B was running in proceeding state, proxies won't have required timer-C. 4. If timer B indeed does fire at proceeding state, we need to send CANCEL to the INVITE (this is not mentioned in specification). Anyone? Regards, Sachin -----Original Message----- From: Ashish Kumar [mailto:[EMAIL PROTECTED] Sent: Friday, May 05, 2006 2:28 PM To: Sachin; [email protected] Subject: RE: [Sip-implementors] Query on Re-Invite Hey Sachin, Thanks for the detailed explanation. I think I made a mistake earlier, stopping of Timer B on 1xx response is not correct, it should be stopped only on Final response. An error condition can be generated on Timer B expiry then. Also, in case 487 from B take some time in reaching A, then it would also be acknowledged by an ACK, this way. Thanks anyways. Ashish -----Original Message----- From: Sachin [mailto:[EMAIL PROTECTED] Sent: Friday, May 05, 2006 2:17 PM To: Ashish Kumar; [email protected] Subject: RE: [Sip-implementors] Query on Re-Invite Hi Ashish, You have chartered one of the many border conditions in SIP. Obviously it is not possible for the specification to handle each of these cases and clearly specify a course of action. In such cases we needs to look at the practical aspect and make a choice that is not in any serious violation of specification and one that would be fail safe against most scenario (for interoperability). Looking at the practical side: 1) This scenario is very rare. 2) This scenario cannot be easily forced on to a UA (means a malicious program at the other end cannot force this scenario). Because of above points, this does not require a perfect handling. If you are an implementer I would suggest doing what ever is simplest without any gross violation of specification and without giving the users (of the phone/stack) any surprises. Regards, Sachin P.S. Note, since UAS has sent bye it means that user there has hung up and is not sending/receiving any media, and since UAC has send 200OK for BYE it is also not sending/receiving any media. So retransmit or don't retransmit users are not going to be bothered in any way. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ashish Kumar Sent: Thursday, May 04, 2006 3:00 PM To: [email protected] Subject: [Sip-implementors] Query on Re-Invite Hi, I have question on following scenario. A ---(Invite)--> B A <--(183)---- B A <--(200)---- B A ---(ACK)--> B A <--(Re-Invite)------- B A --- (Bye) -----------> B A <-- (200 for Bye) B What should be the behavior after this. Should B stop retransmitting Re-Invite and then wait for Timer B to fire. Or should B clear call, dialog and transaction immediately on receiving 200 for Bye. TIA Ashish Kumar Continuous Computing Web : http://www.ccpu.com _______________________________________________ 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
