sysmocom
/
asterisk
11
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Make some notes about a problem I found with the OPTIONs handler while working with 

the bug tracker. Since we don't authenticate devices (peers/users) on OPTIONS we don't
have the proper context set for the user/peer. 

However, we might not want to process an authentication for every OPTIONS, so we could
have a config option for this, "optionsforceok" to always answer 200 OK on the request
and not check device or destination, nor add a SDP. If Asterisk sends the OPTIONs request,
it doesn't care about the reply. Some devices use OPTIONs to discover capabilities,
since we should answer like an INVITE from the device and we need to support that properly
too, which we don't today.

So much to do :-)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Olle Johansson 2007-11-19 08:34:26 +00:00
parent f71cd9acc8
commit 1dc6524449
1 changed files with 21 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
channels/chan_sip.c
View File

@ -9518,8 +9518,10 @@ static int get_rdnis(struct sip_pvt *p, struct sip_request *oreq)
return 0;
}
/*! \brief Find out who the call is for
We use the INVITE uri to find out
/*! \brief Find out who the call is for.
We use the request uri as a destination.
This code assumes authentication has been done, so that the
device (peer/user) context is already set.
\return 0 on success (found a matching extension),
1 for pickup extension or overlap dialling support (if we support it),
-1 on error.
@ -9527,7 +9529,7 @@ static int get_rdnis(struct sip_pvt *p, struct sip_request *oreq)
static int get_destination(struct sip_pvt *p, struct sip_request *oreq)
{
char tmp[256] = "", *uri, *a;
char tmpf[256] = "", *from;
char tmpf[256] = "", *from = NULL;
struct sip_request *req;
char *colon;
@ -9551,14 +9553,15 @@ static int get_destination(struct sip_pvt *p, struct sip_request *oreq)
uri += 4;
/* Now find the From: caller ID and name */
/* XXX Why is this done in get_destination? Isn't it already done?
Needs to be checked
*/
ast_copy_string(tmpf, get_header(req, "From"), sizeof(tmpf));
if (!ast_strlen_zero(tmpf)) {
if (pedanticsipchecking)
ast_uri_decode(tmpf);
from = get_in_brackets(tmpf);
} else {
from = NULL;
}
}
if (!ast_strlen_zero(from)) {
if (strncasecmp(from, "sip:", 4)) {
@ -14565,16 +14568,25 @@ static int handle_request_notify(struct sip_pvt *p, struct sip_request *req, str
return res;
}
/*! \brief Handle incoming OPTIONS request */
/*! \brief Handle incoming OPTIONS request
An OPTIONS request should be answered like an INVITE from the same UA, including SDP
*/
static int handle_request_options(struct sip_pvt *p, struct sip_request *req)
{
int res;
/*! XXX get_destination assumes we're already authenticated. This means that a request from
a known device (peer/user) will end up in the wrong context if this is out-of-dialog.
However, we want to handle OPTIONS as light as possible, so we might want to have
a configuration option whether we care or not. Some devices use this for testing
capabilities, which means that we need to match device to answer with proper
capabilities (including SDP).
\todo Fix handle_request_options device handling with optional authentication
(this needs to be fixed in 1.4 as well)
*/
res = get_destination(p, req);
build_contact(p);
/* XXX Should we authenticate OPTIONS? XXX */
if (ast_strlen_zero(p->context))
ast_string_field_set(p, context, default_context);