[asterisk-dev] [svn-commits] mjordan: branch 12 r424624 - /branches/12/res/res_pjsip/pjsip_options.c

[Matthew Jordan]

On Mon, Oct 6, 2014 at 1:25 AM, Olle E. Johansson <oej at edvina.net> wrote:
>
> On 06 Oct 2014, at 02:59, SVN commits to the Digium repositories <svn-commits at lists.digium.com> wrote:
>
>>
>> An OPTIONS request that is sent to Asterisk but not to a specific endpoint is
>> currently sent a 404 in response. This is because, not surprisingly, an empty
>> extension is never going to be found in the dialplan.
>>
>> This patch makes it so that we only attempt to look up the endpoint in the
>> dialplan if it is specified in the OPTIONS request URI.
>
> An empty extension in Asteirsk is the "s" extension, right?
> In chan_sip we answer with 200 OK if an "s" extension can be found, otherwise an error is generated.
>
> If that's a good or bad solution is a differernt thing - but we do handle empty extensions,
> especially in the dahdi channel.
>

Yup - chan_sip, prior to calling ast_exists_extension, will often
insert an "s" if the request URI does not contain a user portion as
well. We aren't currently doing that in the part of chan_pjsip that
handles OPTIONS requests. My commit message probably could have been a
bit clearer - the ast_exists_extension does not handle 'blank'
extensions by itself, but other places prevent a blank extension from
being passed to that function by providing the "s" extension if
nothing else was specified.

For OPTIONS requests in particular, I'm not sure that really is super
useful. Clearly, an inbound call is a different matter. But for
OPTIONS requests, having to provide the "s" extension to prevent a 404
when the request URI did not specify a username feels odd.

We could do that if people liked, however :-)

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org