Hi Kevin,
Actually, I had just copied the draft authors on that thread and Brian was not
on it. Below is Paul's response for everyone's clarification.
Thanks,
David
On 12/6/12 12:17 PM, David Hanes wrote:
> Hi Paul,
>
> I am hoping you can lend us a hand in answering a comment from Brian
> Carpenter (attached), who is the Gen-ART reviewer for our draft. Being
> an author of 3840 and instrumental in helping us revise our draft, you
> seem to be the best person to comment here.
>
> In the thread below, Kevin proposes the question, " is a registrar even
> allowed to return a Contact header that differs from the one the UA
> supplied in its REGISTER request?". I think that the answer to this
> question determines how we progress forward in addressing Brian's
> comment. We would appreciate your thoughts and guidance on this when you
> have a moment.
I'll try.
RFC 3261 doesn't say anything about the registrar saving or returning contact
parameters, other than the expiration time and q-value.
RFC 3840 does that. *If* the registrar supports the "pref" option, then it is
required to save the feature parameters (aka feature tags or capabilities), and
to return them in queries. Returning them all is MUST strength, so it doesn't
have the option of selectively removing some. Things are written so that the
registrar need not be aware of *particular* feature tags to support them. Newly
defined ones (such as being defined here) are recognized syntactically (via the
leading "+").
If the registrar doesn't support "pref" it may or may not save and return
Contact header field parameters. (It is neither required to do so nor forbidden
from doing so.) In this case, I suppose it also *could* selectively prune (or
add) parameters.
Also, the registrar has considerable latitude in its operation. As specified in
3261, it stores the registration bindings in an abstract location service. It
is permissible for there to be other (unspecified) ways for the location
service to be populated and manipulated. (A common case would be for the
location service to be pre-populated with some default contacts.) Because of
this, one could justify removing parameters from a binding by saying it might
have been done by some external agent operating on the location service.
In general, callee capabilities (feature tags) and caller preference support by
the proxy associated with the registrar are optional features, and you
shouldn't be too surprised if they aren't supported.
In the case of the fax capability, I think you will probably want to include it
in the registration *without* Require:pref. If it doesn't show up in the
response to the REGISTER then you know it wasn't saved. If it did show up, you
still don't know if callerprefs pertaining to it will be supported or not. What
should you do? Nothing. You may get some non-fax calls and those will then
fail. Maybe they will then be forked to another contact that succeeds, or not.
That is not the concern of the fax device.
Thanks,
Paul
> Thanks,
> David
On Dec 7, 2012, at 6:22 AM, Kevin Fleming wrote:
> Paul already answered this question to Brian's satisfaction yesterday.
>
>
> On Fri, Dec 7, 2012 at 4:01 AM, Gonzalo Camarillo
> <[email protected]> wrote:
> Hi Paul,
>
> [I am adding Paul to this thread since he was a coauthor of RFC 3840]
>
> please, see below the exchange between Brian and Kevin regarding
> draft-hanes-dispatch-fax-capability-06.txt.
>
> This was Brian's original comment:
>
> > Minor issue:
> > ------------
> >
> > ... A UA
> > preferring the reception of fax calls MUST include the "sip.fax"
> > media feature tag in the Contact header field of REGISTER messages.
> > To confirm the registration of this preference, a SIP [RFC3261]
> > Registrar MUST then include this tag in the Contact header field of
> > its 200 OK response.
> >
> > If the Registrar does not do this (e.g. because it hasn't been updated
> > to support the new tag), what does the UA do when it receives the
> > 200 OK response that doesn't include the tag?
>
> Paul, can you share your views on this issue?
>
> Thanks,
>
> Gonzalo
>
>
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
