I just thought about it a bit more and Dale is right. I believe the *Require *header should be enough. The REGISTER can be sent to the Registrar server from UAC with the Require header containing the feature name. If the Registrar server supports this, it will respond with a 401. Otherwise the UAS/Registrar server will respond with the 420 or 400 response, as Dale mentioned earlier. So we do not need the Require header to be a part of the 401 as well.
On Thu, 16 Aug 2018 at 20:18, Olle E. Johansson <o...@edvina.net> wrote: > > > > On 16 Aug 2018, at 16:44, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > > > > On 8/16/18 1:21 AM, Sreekanth wrote: > >> On Thu, 16 Aug 2018 at 08:31, Dale R. Worley <wor...@ariadne.com> > wrote: > >>> Sreekanth <sknt...@gmail.com> writes: > >>>> I am going through the SIP RFC (3261) and couldn't find anything > >>> specified > >>>> regarding the 401 Unauthorized challenge response from the UAS side > >>> during > >>>> a registration. > >>>> > >>>> I wanted to confirm whether it is okay to add a *Require *header into > >>> this > >>>> 401 Unauthorized message response. > >>> > >>> What would be the point? The concept of a Require header is "the UAS > is > >>> required to reject the request (420) if it doesn't understand the > >>> option-tag". If a *response* had a Require header, either the UAC > >>> understands the option-tag and processes the response as normal, or it > >>> doesn't understand the option-tag ... and then what does it do? It > >>> can't send a 420 response *to a response*. > >>> > >>> Dale > >>> > >> Dale, I'm trying to add a new feature in the existing REGISTER framework > >> and the CPE will determine whether or not this new feature should get > >> activated based on the 401 response from the Registrar server. If the > >> Registrar server includes the Require header in the 401 response, then > the > >> CPE knows that this feature is supported by the Registrar. > > > > It would helpful for you to lay out the scenario you have in mind for > this new feature. > > > > Aren’t you looking for the Supported header? > > https://tools.ietf.org/html/rfc3261#section-8.1.1.9 < > https://tools.ietf.org/html/rfc3261#section-8.1.1.9> > > /O > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
