Re: [Gen-art] Gen-ART LC review of draft-hanes-dispatch-fax-capability-06.txt

[David Hanes <[e-mail]>]

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 <[e-mail]> 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
> 
> 
> 
>