Nataraju, Thanks for your comments. I should agree with your point of view. Although, I am not sure how these timer values could be negotiatied b/w the UAC and the UAS. Also, I guess the limits imposed on the values cannot be arbitrary, but based on calculations involving other parameters. If so, IMHO, they should bind to the UAC/UAS and could not be interchanged. I also presume that any such devaition could have undesirable implications on interoperability.
regards PV On 7/10/06, Nataraju A B <[EMAIL PROTECTED]> wrote: > > Comments inline... > > Thanks & Regards, > Nataraju A.B. > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:sip-implementors- > > [EMAIL PROTECTED] On Behalf Of P Vinod > > Sent: Sunday, July 09, 2006 6:07 PM > > To: sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] What is the logic? > > > > Hi, > > > > The following is a quote from section 14.1 of RFC 3261: > > > > <Begin quote> > > > > If a UAC receives a 491 response to a re-INVITE, it SHOULD start a > > timer with a value T chosen as follows: > > 1. If the UAC is the owner of the Call-ID of the dialog ID > > (meaning it generated the value), T has a randomly chosen value > > between 2.1 and 4 seconds in units of 10 ms. > > 2. If the UAC is not the owner of the Call-ID of the dialog ID, T > > has a randomly chosen value of between 0 and 2 seconds in units > > of 10 ms. > > > > <End Quote> > > > > Does anyone know the design logic behind the difference in the timer > values? > > > [ABN] AFAIK, the importance point here is with respect to having > different waiting timers on UAC and UAS. And 0-2 or 2.1-4 seconds > duration is been considered arbitrary. > > Note: if all the UAC/UAS agrees, we can very well interchange these > durations, I mean UAC to use timers in the range of 0-2 seconds, UAS to > use timers in the range of 2.1-4 seconds. Doing so does not add much > value compared to what is been said in 3261. > > If both UAC and UAS have same waiting timer values, then there might be > a chance that each of them retries at same time again and again, which > is what undesirable. > > > thanks for your time. > > > > PV > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
