Each Contact should have an Expires that reflects the *remaining* time
until it expires. So polling it should see decreasing times until it is
refreshed.
Paul
Jeff Wright wrote:
> Hello,
>
>
>
> I have a question with interpreting the wording of RFC3261 with respect
> to how a SIP registrar should respond to REGISTER requests that do not
> have a Contact: field in the message (this is the method specified for
> performing a "binding fetch" from a registrar). According to 3261,
> Section 10.3, Step 8:
>
>
>
> 8. The registrar returns a 200 (OK) response. The response MUST
>
> contain Contact header field values enumerating all current
>
> bindings. Each Contact value MUST feature an "expires"
>
> parameter indicating its expiration interval chosen by the
>
> registrar. The response SHOULD include a Date header field.
>
>
>
> The way I originally read this is that a registrar should respond w/ the
> expiration value chosen at the moment of registration (e.g. 3600). This
> value would not change during the time in which that registration is
> valid (not expired). However, what I am actually seeing from a real
> registrar is that 200OK responses are given with the count-down to the
> expiration (e.g. 3455, then 3300, then 2988) as subsequent REGISTER
> requests w/ no Contact: headers are sent - this instead of what I
> expected, the static (originally set) expiration value.
>
>
>
> Anyone care to weigh in on the interpretation of the RFC's wording?
> "Each Contact value MUST feature an "expires" parameter indicating its
> expiration interval chosen by the registrar."
>
>
>
> Thanks in advance,
>
>
>
> Jeffrey D. Wright
>
> System Test Engineering Manager
>
> Aztek Networks, Inc.
>
>
>
> _______________________________________________
> 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
