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 > > > On 05/12/2012 6:02 PM, Brian E Carpenter wrote: > > On 05/12/2012 14:12, Kevin Fleming wrote: > >> I suppose it could choose to unregister and re-register in some other > way > >> in order to achieve its goals of receiving FAX calls, if it was > configured > >> with enough network information to do so. > >> > >> Now that I think about it some more, is a registrar even allowed to > return > >> a Contact header that differs from the one the UA supplied in its > REGISTER > >> request? I suspect this is *not* allowed, and so if the registrar > supports > >> Caller-Pref but the specific tag(s) in question fail some sort of > >> validation process, its only recourse would be to fail the REGISTER > request > >> with a suitable error response. > > > > If that's the standard behaviour, it would of course answer my question. > > > > Brian > > > >> > >> > >> On Wed, Dec 5, 2012 at 6:35 AM, Brian E Carpenter < > >> [email protected]> wrote: > >> > >>> On 05/12/2012 11:01, Kevin Fleming wrote: > >>>> The language in RFC 3840 doesn't appear to contemplate the situation > >>> you've > >>>> proposed. In its world, registrars can either support prefs (and will > >>>> accept "Require: pref") or they don't, and they don't have knowledge > of > >>>> which feature tags are registered with IANA and which are not. Of > course, > >>>> they *coud* attempt to validate the tags expressed by the UA, but I > don't > >>>> see an explicit way for the registrar to indicate that the UA included > >>>> disallowed tags in its request. > >>> Understood, but in that case I don't see what good the confirmation > >>> of the tag from the registrar to the UA achieves - the UA is not going > >>> to be able to do anything with it (except maybe log whether it was > >>> received). > >>> > >>> Brian > >>> > >> > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
