> a) Is the 200 response as above with > different expiration value in contact > and header field allowed/normal practice?
Not normal; however it is allowed. The expires contact parameter has precedence; see RFC3261 section 10.2.4. > Since there is only one binding, I expect > the same value. Do you agree? They do not need to be the same; however the Expires header is useless in this situation. > b) I do not find clauses in RFC3261 > indicating that the Registrar populates > the expires value with the *remaining* > expiration time : e.g. UA request > expires=900, this is accepted by the > registrar, but when the registrar sends out > the 200 OK message, a second elapsed > meanwhile, resulting in contact expires=899. > Is this acceptable protocol behavior ?? Yes. > If somebody knows : Please indicate in your > reply if the Registrar must populate 900 or > 899 in the contact expires. The expiration indicated within a 200 response can be below a prior Min-Expires value. If the current time to expiration is 899, the value should be 899. > c) The UA takes into account the contact > expires value (899). A lowered contact expiration within a 200 response should not impact the expiration value supplied in a subsequent register. > d) When this expiration time elapses, the > UA sends a new REGISTER , this time with > the new value 899. See above. > The Registrar then answers > with a 423 Interval too brief, indicating that > the Minimum expires value is 900. > What is the expected behavior from the UA : > populating the expires with 899, as received > from the Registrar, or using the local > configured 900 ? UA should time based upon 899. The remembered Min-Expires value (or UA's desired expiration time) should be the expiration value within the refreshing REGISTER. > e) Some further thinking on b) : If the > registrar replies with the *remaining* expiration > time , does this not causes problems? It is only a problem if a device uses the received expiration value as the expiration value within the subsequent register. > Imagine that the UA does the refreshing (i.e. > sending a new Register) too early, resulting > in the Registrar replying with 200 OK : > contact expires=1 second (or even 0 seconds). > Then the UA will send Register messages too > frequently ? I do not understand your example. Here is an example to help explain why some registrars allow the response's contact expiration to decrement. UA registers contact to expire in 3600 seconds. The registrar sends the response with contact expires = 30 seconds. The response keeps getting dropped. After the 9th retry, the UA finally receives the response. If the expiration still indicated 30 seconds (and UA does not adjust based upon when it sent the first request), the contact might be removed from the registrar prior to the UA trying to refresh the subscription. If the UA adjusts the response's contact expiration based upon a delta between register and received response, I agree that this can increase the frequency of registrations if the registrar and proxies also allow the response's contact expiration to decrement. Since some deployments are trying to use a 30 second registration expiration intervals to deal with NATs, maybe someone could submit a BCP document discussing how best to accommodate small expiration values traversing a slow flaky network with numerous proxies. > f) Is the UA obliged to take into account > the Min-Expires value received from the > registrar? I think it is logical, but > is the RFC stating this explicitly? The Min-Expires value is used to populate the subsequent register. The Min-Expires value is not used to calculate when to refresh the subscription. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
