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

[Olle E. Johansson]

On 06 Oct 2014, at 16:21, Matthew Jordan <mjordan at digium.com> wrote:

> 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.
When a channel is created it uses s at default by default...

> 
> 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 :-)

I don't like that behaviour.

A bigger issue is if we should at any point try to implement "real" options answers. After
authentication we could add an SDP...

/O