"Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > I had a question come up about how to handle registrations when this > response is received. It is clear that if there is a desire to complete > the requested registration the expiration value must be increased to at > least the value returned in the 423. > > The question is: what should be done when it is time to refresh that > registration? Is it acceptable for the UA to again try its own preferred > value rather than the value from the 423? Or should it continue using > the value from the first 423 in subsequent refreshes? > > Presumably the registrar gave the 423 because it wanted to reduce the > number of register requests it has to process. If the UA continues to > use its preferred (smaller) value on every refresh attempt it will > double the number of register requests the registrar, with half of them > receiving 423 responses. So the UA using its preferred value for > refreshes seems counter productive. > > So my conclusion is that if a UA receives a 423 response to a register > request, and it chooses to reattempt the register request, it SHOULD use > a value consistent with the 423 in the subsequent register request AND > in any subsequent refreshes to that registration. > > Does this seem right?
Yes, it does. It's probably better for a registration to last slightly longer than necessary in the interests of decreasing network traffic and the overhead in creating sockets, etc. than for a registrar to have to cope with loads of UAs hitting it with REGISTERS that it'll just 423 anyway. I don't think it'd be necessary to maintain the registrar's preferred value in the UA across reboots, mind you. Or the UA could, from time to time, re-register with its (smaller) preferred value, just to see if the registrar will now accept the smaller value. (Perhaps the registrar's under much less load now, and adjusted its desired minimum value accordingly.) frank _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
