> Why not the following?: > > 200 with default registrar Expires value (probably 3600)?
If you mean local default, that is the implied interpretation of "2) Return 200 with Contact as though expires parameter not received". If you are referring to the following SHOULD, that is obviously OK. :) RFC 3261 section 10.2: "expires: The "expires" parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. If this parameter is not provided, the value of the Expires header field is used instead. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Malformed values SHOULD be treated as equivalent to 3600." > -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Iñaki Baz > Castillo > Sent: Friday, February 27, 2009 8:55 AM > Cc: [email protected] > Subject: Re: [Sip-implementors] "expires" field value in REGISTER request > > 2009/2/27 Brett Tate <[email protected]>: > > The request is malformed. The receiver can basically handle it however > it desires. > > > > Returning "400 Fix Contact Expires Parameter" would be ideal. > Unfortunately returning failure responses to REGISTER often causes > frequent REGISTERs with the same issue until finally resolved (by > reconfiguration or new software). > > > > In the wild, the following few likely possibilities: > > 1) Return "400 Fix Contact Expires Parameter". > > 2) Return 200 with Contact as though expires parameter not received. > > 3) Return 200 as though Contact not received. > > 4) Return "403 Forbidden until Contact expires parameter valid". > > Why not the following?: > > 200 with default registrar Expires value (probably 3600)? > > But I would prefer: > > 400 Drop your dirty device > > -- > Iñaki Baz Castillo > <[email protected]> > > _______________________________________________ > 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
