I see no point in the registrar doing this type of thing when it receives a REGISTER request (expires - (current time - date header time)).
But you might be right in the case of fetching: registrar tells the UA it has 30 seconds left in its registration and the there is a 20 second delay in the response. In this case, you could try using the Date header, if present. Regards, Hisham > -----Original Message----- > From: ext Ken Jordan [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 3:57 PM > To: 'Jonathan Rosenberg' > Cc: 'Sipimp (E-mail)' > Subject: RE: [Sip-implementors] DATE field and REGISTER EXPIRES field > > > Thank you for the response. More comments inline > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 06, 2002 2:19 AM > > To: [EMAIL PROTECTED] > > Cc: Sipimp (E-mail) > > Subject: Re: [Sip-implementors] DATE field and REGISTER > EXPIRES field > > > > > > inline. > > > > Ken Jordan wrote: > > > Since the DATE field provided in the register response is > > useful to set > > > the > > > UAC's time (per 10.2.5)... > > > > > > If a DATE header field is included in the clients REGISTER > > request, does > > > the > > > registrar take into > > > account the transmission time between the UAC sending the > > registration > > > and > > > the registrar receiving > > > it (expires - (current time - date header time))? > > > > You could try, but generally no. I see no value in that. > > > > > That is, if the > > > transmission time is 30 seconds and > > > the expires field was 300 seconds, > > > > Thats a pretty screwed up system. In any reasonably well designed > > nework, the registration interval should far exceed the transmission > > latency by several orders of magnitude. > > > > Registration times could be fairly short (on the order of a > few minutes). > The protocol leaves it up to the registrar to impose a > minimum value for the > expires field. For some applications, a smaller expires time may be > acceptable. For example, an agent returns to their desk at 4:57pm and > registers their presence as being the next 3 minutes. > > Agreed that it is an undesirable network. Unfortunately > customers do not > always have optimum networks. I'm trying to understand the > timeout values > allowed in the protocol when compared to shorter registration > intervals. I > understand that it should work if the network were working > properly. I'm > considering the other side when customers do not always have perfect > networks. Consider what happens as transmission times > approach the timeout > values (yet the message still makes it through). > > What are suggested/typical registration timeout values? > > As transmission times approach the timeout values, can the > intended expires > value (from the clients perspective) be off by as much as that timeout > value? > > I'm not looking to change the protocol for worse case > scenarios. However I > do want to understand the intended behavior of registrars given these > conditions. I would like to know that while this situation > is undesirable > the protocol is still able to handle it. > > I appreciate your help. > > > > > A couple of questions related to > > > the > > > UACs handling of the REGISTER > > > response. > > > > > > 1. Is the expires value in the response the seconds > > remaining from the > > > original registration til now? > > > Or is it simply the original expires value? E.g. REGISTER at > > > 10:00:00 > > > with expires=3600. > > > Fetching the bindings 2400 seconds later would yield > > 1200 or 3600 > > > for > > > the expires value? > > > > 1200. > > > > > > > > 2. Should the UAC use the DATE field (the registrars time) when > > > evaluating > > > the actual time left in the > > > expires field (similar to what was asked for the > > registrar above)? > > > > No. > > > > -Jonathan R. > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > [EMAIL PROTECTED] FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
