2013-04-25 18:25:31 +00:00
|
|
|
/*
|
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2013, Digium, Inc.
|
|
|
|
*
|
|
|
|
* Joshua Colp <jcolp@digium.com>
|
|
|
|
*
|
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
* channels for your use.
|
|
|
|
*
|
|
|
|
* This program is free software, distributed under the terms of
|
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
* at the top of the source tree.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*** MODULEINFO
|
2013-04-26 21:52:06 +00:00
|
|
|
<depend>pjproject</depend>
|
2016-04-14 12:23:54 +00:00
|
|
|
<depend>res_pjproject</depend>
|
2013-07-30 18:14:50 +00:00
|
|
|
<depend>res_pjsip</depend>
|
2013-04-25 18:25:31 +00:00
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
#include <pjsip.h>
|
|
|
|
#include <pjsip_ua.h>
|
|
|
|
|
2013-07-30 18:14:50 +00:00
|
|
|
#include "asterisk/res_pjsip.h"
|
2013-04-25 18:25:31 +00:00
|
|
|
#include "asterisk/module.h"
|
2016-04-15 19:26:15 +00:00
|
|
|
#include "asterisk/paths.h"
|
2013-08-12 22:05:18 +00:00
|
|
|
#include "asterisk/test.h"
|
2013-09-26 18:51:54 +00:00
|
|
|
#include "asterisk/taskprocessor.h"
|
2013-11-23 17:26:57 +00:00
|
|
|
#include "asterisk/manager.h"
|
2016-04-01 18:30:56 +00:00
|
|
|
#include "asterisk/named_locks.h"
|
2016-04-14 12:23:54 +00:00
|
|
|
#include "asterisk/res_pjproject.h"
|
2013-11-23 17:26:57 +00:00
|
|
|
#include "res_pjsip/include/res_pjsip_private.h"
|
|
|
|
|
|
|
|
/*** DOCUMENTATION
|
|
|
|
<manager name="PJSIPShowRegistrationsInbound" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
Lists PJSIP inbound registrations.
|
|
|
|
</synopsis>
|
|
|
|
<syntax />
|
|
|
|
<description>
|
|
|
|
<para>
|
2016-12-06 20:54:25 +00:00
|
|
|
In response, <literal>InboundRegistrationDetail</literal> events showing configuration
|
|
|
|
and status information are raised for all contacts, static or dynamic. Once all events
|
|
|
|
are completed an <literal>InboundRegistrationDetailComplete</literal> is issued.
|
|
|
|
</para>
|
|
|
|
<warning><para>
|
|
|
|
This command just dumps all coonfigured AORs with contacts, even if the contact
|
|
|
|
is a permanent one. To really get just inbound registrations, use
|
|
|
|
<literal>PJSIPShowRegistrationInboundContactStatuses</literal>.
|
|
|
|
</para>
|
|
|
|
</warning>
|
|
|
|
</description>
|
|
|
|
<see-also>
|
|
|
|
<ref type="manager" module="res_pjsip_registrar">PJSIPShowRegistrationInboundContactStatuses</ref>
|
|
|
|
</see-also>
|
|
|
|
</manager>
|
|
|
|
<manager name="PJSIPShowRegistrationInboundContactStatuses" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
Lists ContactStatuses for PJSIP inbound registrations.
|
|
|
|
</synopsis>
|
|
|
|
<syntax />
|
|
|
|
<description>
|
|
|
|
<para>
|
|
|
|
In response, <literal>ContactStatusDetail</literal> events showing status information
|
|
|
|
are raised for each inbound registration (dynamic contact) object. Once all events
|
|
|
|
are completed a <literal>ContactStatusDetailComplete</literal> event is issued.
|
|
|
|
</para>
|
2013-11-23 17:26:57 +00:00
|
|
|
</description>
|
|
|
|
</manager>
|
|
|
|
***/
|
2013-04-25 18:25:31 +00:00
|
|
|
|
2016-04-14 12:23:54 +00:00
|
|
|
static int pj_max_hostname = PJ_MAX_HOSTNAME;
|
|
|
|
static int pjsip_max_url_size = PJSIP_MAX_URL_SIZE;
|
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
/*! \brief Internal function which returns the expiration time for a contact */
|
|
|
|
static int registrar_get_expiration(const struct ast_sip_aor *aor, const pjsip_contact_hdr *contact, const pjsip_rx_data *rdata)
|
|
|
|
{
|
|
|
|
pjsip_expires_hdr *expires;
|
|
|
|
int expiration = aor->default_expiration;
|
|
|
|
|
2015-02-21 19:28:09 +00:00
|
|
|
if (contact && contact->expires != -1) {
|
2013-04-25 18:25:31 +00:00
|
|
|
/* Expiration was provided with the contact itself */
|
|
|
|
expiration = contact->expires;
|
|
|
|
} else if ((expires = pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_EXPIRES, NULL))) {
|
|
|
|
/* Expiration was provided using the Expires header */
|
|
|
|
expiration = expires->ivalue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If the value has explicitly been set to 0, do not enforce */
|
|
|
|
if (!expiration) {
|
|
|
|
return expiration;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Enforce the range that we will allow for expiration */
|
|
|
|
if (expiration < aor->minimum_expiration) {
|
|
|
|
expiration = aor->minimum_expiration;
|
|
|
|
} else if (expiration > aor->maximum_expiration) {
|
|
|
|
expiration = aor->maximum_expiration;
|
|
|
|
}
|
|
|
|
|
|
|
|
return expiration;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Structure used for finding contact */
|
|
|
|
struct registrar_contact_details {
|
|
|
|
/*! \brief Pool used for parsing URI */
|
|
|
|
pj_pool_t *pool;
|
|
|
|
/*! \brief URI being looked for */
|
2016-04-14 12:23:54 +00:00
|
|
|
pjsip_sip_uri *uri;
|
2013-04-25 18:25:31 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*! \brief Callback function for finding a contact */
|
|
|
|
static int registrar_find_contact(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_sip_contact *contact = obj;
|
|
|
|
const struct registrar_contact_details *details = arg;
|
|
|
|
pjsip_uri *contact_uri = pjsip_parse_uri(details->pool, (char*)contact->uri, strlen(contact->uri), 0);
|
|
|
|
|
|
|
|
return (pjsip_uri_cmp(PJSIP_URI_IN_CONTACT_HDR, details->uri, contact_uri) == PJ_SUCCESS) ? CMP_MATCH | CMP_STOP : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Internal function which validates provided Contact headers to confirm that they are acceptable, and returns number of contacts */
|
|
|
|
static int registrar_validate_contacts(const pjsip_rx_data *rdata, struct ao2_container *contacts, struct ast_sip_aor *aor, int *added, int *updated, int *deleted)
|
|
|
|
{
|
|
|
|
pjsip_contact_hdr *previous = NULL, *contact = (pjsip_contact_hdr *)&rdata->msg_info.msg->hdr;
|
|
|
|
struct registrar_contact_details details = {
|
|
|
|
.pool = pjsip_endpt_create_pool(ast_sip_get_pjsip_endpoint(), "Contact Comparison", 256, 256),
|
|
|
|
};
|
|
|
|
|
|
|
|
if (!details.pool) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
while ((contact = (pjsip_contact_hdr *) pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_CONTACT, contact->next))) {
|
2013-06-22 14:03:22 +00:00
|
|
|
int expiration = registrar_get_expiration(aor, contact, rdata);
|
2013-04-25 18:25:31 +00:00
|
|
|
RAII_VAR(struct ast_sip_contact *, existing, NULL, ao2_cleanup);
|
2016-04-14 12:23:54 +00:00
|
|
|
char contact_uri[pjsip_max_url_size];
|
2013-04-25 18:25:31 +00:00
|
|
|
|
|
|
|
if (contact->star) {
|
|
|
|
/* The expiration MUST be 0 when a '*' contact is used and there must be no other contact */
|
2013-06-22 14:03:22 +00:00
|
|
|
if ((expiration != 0) || previous) {
|
2013-04-25 18:25:31 +00:00
|
|
|
pjsip_endpt_release_pool(ast_sip_get_pjsip_endpoint(), details.pool);
|
|
|
|
return -1;
|
|
|
|
}
|
2013-08-01 23:38:00 +00:00
|
|
|
continue;
|
2013-04-25 18:25:31 +00:00
|
|
|
} else if (previous && previous->star) {
|
|
|
|
/* If there is a previous contact and it is a '*' this is a deal breaker */
|
|
|
|
pjsip_endpt_release_pool(ast_sip_get_pjsip_endpoint(), details.pool);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
previous = contact;
|
|
|
|
|
|
|
|
if (!PJSIP_URI_SCHEME_IS_SIP(contact->uri) && !PJSIP_URI_SCHEME_IS_SIPS(contact->uri)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
details.uri = pjsip_uri_get_uri(contact->uri);
|
|
|
|
|
2016-04-14 12:23:54 +00:00
|
|
|
/* pjsip_uri_print returns -1 if there's not enough room in the buffer */
|
|
|
|
if (pjsip_uri_print(PJSIP_URI_IN_CONTACT_HDR, details.uri, contact_uri, sizeof(contact_uri)) < 0) {
|
|
|
|
/* If the total length of the uri is greater than pjproject can handle, go no further */
|
|
|
|
pjsip_endpt_release_pool(ast_sip_get_pjsip_endpoint(), details.pool);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (details.uri->host.slen >= pj_max_hostname) {
|
|
|
|
/* If the length of the hostname is greater than pjproject can handle, go no further */
|
|
|
|
pjsip_endpt_release_pool(ast_sip_get_pjsip_endpoint(), details.pool);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
/* Determine if this is an add, update, or delete for policy enforcement purposes */
|
|
|
|
if (!(existing = ao2_callback(contacts, 0, registrar_find_contact, &details))) {
|
|
|
|
if (expiration) {
|
|
|
|
(*added)++;
|
|
|
|
}
|
|
|
|
} else if (expiration) {
|
|
|
|
(*updated)++;
|
|
|
|
} else {
|
|
|
|
(*deleted)++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The provided contacts are acceptable, huzzah! */
|
|
|
|
pjsip_endpt_release_pool(ast_sip_get_pjsip_endpoint(), details.pool);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Callback function which prunes static contacts */
|
|
|
|
static int registrar_prune_static(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_sip_contact *contact = obj;
|
|
|
|
|
|
|
|
return ast_tvzero(contact->expiration_time) ? CMP_MATCH : 0;
|
|
|
|
}
|
|
|
|
|
2014-04-17 22:50:23 +00:00
|
|
|
/*! \brief Internal function used to delete a contact from an AOR */
|
2013-04-25 18:25:31 +00:00
|
|
|
static int registrar_delete_contact(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_sip_contact *contact = obj;
|
2013-08-12 22:05:18 +00:00
|
|
|
const char *aor_name = arg;
|
2013-04-25 18:25:31 +00:00
|
|
|
|
|
|
|
ast_sip_location_delete_contact(contact);
|
2013-08-12 22:05:18 +00:00
|
|
|
if (!ast_strlen_zero(aor_name)) {
|
|
|
|
ast_verb(3, "Removed contact '%s' from AOR '%s' due to request\n", contact->uri, aor_name);
|
|
|
|
ast_test_suite_event_notify("AOR_CONTACT_REMOVED",
|
|
|
|
"Contact: %s\r\n"
|
2014-02-17 15:36:45 +00:00
|
|
|
"AOR: %s\r\n"
|
|
|
|
"UserAgent: %s",
|
2013-08-12 22:05:18 +00:00
|
|
|
contact->uri,
|
2014-02-17 15:36:45 +00:00
|
|
|
aor_name,
|
|
|
|
contact->user_agent);
|
2013-08-12 22:05:18 +00:00
|
|
|
}
|
2013-04-25 18:25:31 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Internal function which adds a contact to a response */
|
|
|
|
static int registrar_add_contact(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_sip_contact *contact = obj;
|
|
|
|
pjsip_tx_data *tdata = arg;
|
|
|
|
pjsip_contact_hdr *hdr = pjsip_contact_hdr_create(tdata->pool);
|
|
|
|
pj_str_t uri;
|
|
|
|
|
|
|
|
pj_strdup2_with_null(tdata->pool, &uri, contact->uri);
|
|
|
|
hdr->uri = pjsip_parse_uri(tdata->pool, uri.ptr, uri.slen, PJSIP_PARSE_URI_AS_NAMEADDR);
|
|
|
|
hdr->expires = ast_tvdiff_ms(contact->expiration_time, ast_tvnow()) / 1000;
|
|
|
|
|
|
|
|
pjsip_msg_add_hdr(tdata->msg, (pjsip_hdr*)hdr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Helper function which adds a Date header to a response */
|
|
|
|
static void registrar_add_date_header(pjsip_tx_data *tdata)
|
|
|
|
{
|
|
|
|
char date[256];
|
|
|
|
struct tm tm;
|
|
|
|
time_t t = time(NULL);
|
|
|
|
|
|
|
|
gmtime_r(&t, &tm);
|
|
|
|
strftime(date, sizeof(date), "%a, %d %b %Y %T GMT", &tm);
|
|
|
|
|
|
|
|
ast_sip_add_header(tdata, "Date", date);
|
|
|
|
}
|
|
|
|
|
2014-01-15 13:16:10 +00:00
|
|
|
static const pj_str_t path_hdr_name = { "Path", 4 };
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
static int build_path_data(pjsip_rx_data *rdata, struct ast_str **path_str)
|
2014-01-15 13:16:10 +00:00
|
|
|
{
|
2016-06-04 03:44:46 +00:00
|
|
|
pjsip_generic_string_hdr *path_hdr = pjsip_msg_find_hdr_by_name(rdata->msg_info.msg, &path_hdr_name, NULL);
|
2014-01-15 13:16:10 +00:00
|
|
|
|
|
|
|
if (!path_hdr) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
*path_str = ast_str_create(64);
|
|
|
|
if (!path_str) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_str_set(path_str, 0, "%.*s", (int)path_hdr->hvalue.slen, path_hdr->hvalue.ptr);
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
while ((path_hdr = (pjsip_generic_string_hdr *) pjsip_msg_find_hdr_by_name(rdata->msg_info.msg, &path_hdr_name, path_hdr->next))) {
|
2014-01-15 13:16:10 +00:00
|
|
|
ast_str_append(path_str, 0, ",%.*s", (int)path_hdr->hvalue.slen, path_hdr->hvalue.ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
static int registrar_validate_path(pjsip_rx_data *rdata, struct ast_sip_aor *aor, struct ast_str **path_str)
|
2014-01-15 13:16:10 +00:00
|
|
|
{
|
|
|
|
const pj_str_t path_supported_name = { "path", 4 };
|
|
|
|
pjsip_supported_hdr *supported_hdr;
|
|
|
|
int i;
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if (!aor->support_path) {
|
2014-01-15 13:16:10 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if (build_path_data(rdata, path_str)) {
|
2014-01-15 13:16:10 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!*path_str) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
supported_hdr = pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_SUPPORTED, NULL);
|
2014-01-15 13:16:10 +00:00
|
|
|
if (!supported_hdr) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Find advertised path support */
|
|
|
|
for (i = 0; i < supported_hdr->count; i++) {
|
|
|
|
if (!pj_stricmp(&supported_hdr->values[i], &path_supported_name)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Path header present, but support not advertised */
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
static int register_aor_core(pjsip_rx_data *rdata,
|
|
|
|
struct ast_sip_endpoint *endpoint,
|
|
|
|
struct ast_sip_aor *aor,
|
|
|
|
const char *aor_name,
|
|
|
|
struct ao2_container *contacts)
|
2013-09-26 18:51:54 +00:00
|
|
|
{
|
2014-02-17 15:36:45 +00:00
|
|
|
static const pj_str_t USER_AGENT = { "User-Agent", 10 };
|
|
|
|
|
2013-09-26 18:51:54 +00:00
|
|
|
int added = 0, updated = 0, deleted = 0;
|
|
|
|
pjsip_contact_hdr *contact_hdr = NULL;
|
|
|
|
struct registrar_contact_details details = { 0, };
|
|
|
|
pjsip_tx_data *tdata;
|
2014-01-15 13:16:10 +00:00
|
|
|
RAII_VAR(struct ast_str *, path_str, NULL, ast_free);
|
|
|
|
struct ast_sip_contact *response_contact;
|
2014-02-17 15:36:45 +00:00
|
|
|
char *user_agent = NULL;
|
|
|
|
pjsip_user_agent_hdr *user_agent_hdr;
|
2015-02-21 19:28:09 +00:00
|
|
|
pjsip_expires_hdr *expires_hdr;
|
2016-05-19 19:56:26 +00:00
|
|
|
pjsip_via_hdr *via_hdr;
|
|
|
|
pjsip_via_hdr *via_hdr_last;
|
|
|
|
char *via_addr = NULL;
|
|
|
|
int via_port = 0;
|
|
|
|
pjsip_cid_hdr *call_id_hdr;
|
|
|
|
char *call_id = NULL;
|
|
|
|
size_t alloc_size;
|
2013-09-26 18:51:54 +00:00
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
/* So we don't count static contacts against max_contacts we prune them out from the container */
|
|
|
|
ao2_callback(contacts, OBJ_NODATA | OBJ_UNLINK | OBJ_MULTIPLE, registrar_prune_static, NULL);
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if (registrar_validate_contacts(rdata, contacts, aor, &added, &updated, &deleted)) {
|
2013-04-25 18:25:31 +00:00
|
|
|
/* The provided Contact headers do not conform to the specification */
|
2016-06-04 03:44:46 +00:00
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 400, NULL, NULL, NULL);
|
|
|
|
ast_sip_report_failed_acl(endpoint, rdata, "registrar_invalid_contacts_provided");
|
2013-08-20 15:27:48 +00:00
|
|
|
ast_log(LOG_WARNING, "Failed to validate contacts in REGISTER request from '%s'\n",
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_sorcery_object_get_id(endpoint));
|
2013-04-25 18:25:31 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if (registrar_validate_path(rdata, aor, &path_str)) {
|
2014-01-15 13:16:10 +00:00
|
|
|
/* Ensure that intervening proxies did not make invalid modifications to the request */
|
2016-06-04 03:44:46 +00:00
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 420, NULL, NULL, NULL);
|
2014-01-15 13:16:10 +00:00
|
|
|
ast_log(LOG_WARNING, "Invalid modifications made to REGISTER request from '%s' by intervening proxy\n",
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_sorcery_object_get_id(endpoint));
|
2014-01-15 13:16:10 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if ((MAX(added - deleted, 0) + (!aor->remove_existing ? ao2_container_count(contacts) : 0)) > aor->max_contacts) {
|
2013-04-25 18:25:31 +00:00
|
|
|
/* Enforce the maximum number of contacts */
|
2016-06-04 03:44:46 +00:00
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 403, NULL, NULL, NULL);
|
|
|
|
ast_sip_report_failed_acl(endpoint, rdata, "registrar_attempt_exceeds_maximum_configured_contacts");
|
2014-05-09 22:49:26 +00:00
|
|
|
ast_log(LOG_WARNING, "Registration attempt from endpoint '%s' to AOR '%s' will exceed max contacts of %u\n",
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_sorcery_object_get_id(endpoint), aor_name, aor->max_contacts);
|
2013-04-25 18:25:31 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(details.pool = pjsip_endpt_create_pool(ast_sip_get_pjsip_endpoint(), "Contact Comparison", 256, 256))) {
|
2016-06-04 03:44:46 +00:00
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 500, NULL, NULL, NULL);
|
2013-04-25 18:25:31 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
user_agent_hdr = pjsip_msg_find_hdr_by_name(rdata->msg_info.msg, &USER_AGENT, NULL);
|
2014-02-17 15:36:45 +00:00
|
|
|
if (user_agent_hdr) {
|
2016-05-19 19:56:26 +00:00
|
|
|
alloc_size = pj_strlen(&user_agent_hdr->hvalue) + 1;
|
2014-02-17 15:36:45 +00:00
|
|
|
user_agent = ast_alloca(alloc_size);
|
|
|
|
ast_copy_pj_str(user_agent, &user_agent_hdr->hvalue, alloc_size);
|
|
|
|
}
|
|
|
|
|
2016-05-19 19:56:26 +00:00
|
|
|
/* Find the first Via header */
|
2016-06-04 03:44:46 +00:00
|
|
|
via_hdr = via_hdr_last = (pjsip_via_hdr*) pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_VIA, NULL);
|
2016-05-19 19:56:26 +00:00
|
|
|
if (via_hdr) {
|
|
|
|
/* Find the last Via header */
|
2016-06-04 03:44:46 +00:00
|
|
|
while ( (via_hdr = (pjsip_via_hdr*) pjsip_msg_find_hdr(rdata->msg_info.msg,
|
2016-05-19 19:56:26 +00:00
|
|
|
PJSIP_H_VIA, via_hdr->next)) != NULL) {
|
|
|
|
via_hdr_last = via_hdr;
|
|
|
|
}
|
|
|
|
alloc_size = pj_strlen(&via_hdr_last->sent_by.host) + 1;
|
|
|
|
via_addr = ast_alloca(alloc_size);
|
|
|
|
ast_copy_pj_str(via_addr, &via_hdr_last->sent_by.host, alloc_size);
|
|
|
|
via_port=via_hdr_last->sent_by.port;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
call_id_hdr = (pjsip_cid_hdr*) pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_CALL_ID, NULL);
|
2016-05-19 19:56:26 +00:00
|
|
|
if (call_id_hdr) {
|
|
|
|
alloc_size = pj_strlen(&call_id_hdr->id) + 1;
|
|
|
|
call_id = ast_alloca(alloc_size);
|
|
|
|
ast_copy_pj_str(call_id, &call_id_hdr->id, alloc_size);
|
|
|
|
}
|
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
/* Iterate each provided Contact header and add, update, or delete */
|
2016-06-04 03:44:46 +00:00
|
|
|
while ((contact_hdr = pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_CONTACT, contact_hdr ? contact_hdr->next : NULL))) {
|
2013-04-25 18:25:31 +00:00
|
|
|
int expiration;
|
2016-04-14 12:23:54 +00:00
|
|
|
char contact_uri[pjsip_max_url_size];
|
2013-04-25 18:25:31 +00:00
|
|
|
RAII_VAR(struct ast_sip_contact *, contact, NULL, ao2_cleanup);
|
|
|
|
|
|
|
|
if (contact_hdr->star) {
|
|
|
|
/* A star means to unregister everything, so do so for the possible contacts */
|
2013-09-26 18:51:54 +00:00
|
|
|
ao2_callback(contacts, OBJ_NODATA | OBJ_MULTIPLE, registrar_delete_contact, (void *)aor_name);
|
2013-04-25 18:25:31 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!PJSIP_URI_SCHEME_IS_SIP(contact_hdr->uri) && !PJSIP_URI_SCHEME_IS_SIPS(contact_hdr->uri)) {
|
|
|
|
/* This registrar only currently supports sip: and sips: URI schemes */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
expiration = registrar_get_expiration(aor, contact_hdr, rdata);
|
2013-04-25 18:25:31 +00:00
|
|
|
details.uri = pjsip_uri_get_uri(contact_hdr->uri);
|
|
|
|
pjsip_uri_print(PJSIP_URI_IN_CONTACT_HDR, details.uri, contact_uri, sizeof(contact_uri));
|
|
|
|
|
|
|
|
if (!(contact = ao2_callback(contacts, OBJ_UNLINK, registrar_find_contact, &details))) {
|
|
|
|
/* If they are actually trying to delete a contact that does not exist... be forgiving */
|
|
|
|
if (!expiration) {
|
|
|
|
ast_verb(3, "Attempted to remove non-existent contact '%s' from AOR '%s' by request\n",
|
|
|
|
contact_uri, aor_name);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if (ast_sip_location_add_contact_nolock(aor, contact_uri, ast_tvadd(ast_tvnow(),
|
2014-02-17 15:36:45 +00:00
|
|
|
ast_samp2tv(expiration, 1)), path_str ? ast_str_buffer(path_str) : NULL,
|
2016-06-04 03:44:46 +00:00
|
|
|
user_agent, via_addr, via_port, call_id, endpoint)) {
|
2014-02-17 15:36:45 +00:00
|
|
|
ast_log(LOG_ERROR, "Unable to bind contact '%s' to AOR '%s'\n",
|
|
|
|
contact_uri, aor_name);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
ast_verb(3, "Added contact '%s' to AOR '%s' with expiration of %d seconds\n",
|
|
|
|
contact_uri, aor_name, expiration);
|
2013-08-12 22:05:18 +00:00
|
|
|
ast_test_suite_event_notify("AOR_CONTACT_ADDED",
|
|
|
|
"Contact: %s\r\n"
|
|
|
|
"AOR: %s\r\n"
|
2014-02-17 15:36:45 +00:00
|
|
|
"Expiration: %d\r\n"
|
|
|
|
"UserAgent: %s",
|
2013-08-12 22:05:18 +00:00
|
|
|
contact_uri,
|
|
|
|
aor_name,
|
2014-02-17 15:36:45 +00:00
|
|
|
expiration,
|
|
|
|
user_agent);
|
2013-04-25 18:25:31 +00:00
|
|
|
} else if (expiration) {
|
2014-03-21 16:04:09 +00:00
|
|
|
struct ast_sip_contact *contact_update;
|
|
|
|
|
|
|
|
contact_update = ast_sorcery_copy(ast_sip_get_sorcery(), contact);
|
|
|
|
if (!contact_update) {
|
|
|
|
ast_log(LOG_ERROR, "Failed to update contact '%s' expiration time to %d seconds.\n",
|
|
|
|
contact->uri, expiration);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
contact_update->expiration_time = ast_tvadd(ast_tvnow(), ast_samp2tv(expiration, 1));
|
2017-02-08 17:50:11 +00:00
|
|
|
contact_update->qualify_frequency = aor->qualify_frequency;
|
|
|
|
contact_update->authenticate_qualify = aor->authenticate_qualify;
|
2014-01-15 13:16:10 +00:00
|
|
|
if (path_str) {
|
2014-03-21 16:04:09 +00:00
|
|
|
ast_string_field_set(contact_update, path, ast_str_buffer(path_str));
|
2014-01-15 13:16:10 +00:00
|
|
|
}
|
2014-02-17 15:36:45 +00:00
|
|
|
if (user_agent) {
|
2014-03-21 16:04:09 +00:00
|
|
|
ast_string_field_set(contact_update, user_agent, user_agent);
|
2014-02-17 15:36:45 +00:00
|
|
|
}
|
2016-04-15 19:26:15 +00:00
|
|
|
if (!ast_strlen_zero(ast_config_AST_SYSTEM_NAME)) {
|
|
|
|
ast_string_field_set(contact_update, reg_server, ast_config_AST_SYSTEM_NAME);
|
|
|
|
}
|
2013-04-25 18:25:31 +00:00
|
|
|
|
2014-05-06 17:47:20 +00:00
|
|
|
if (ast_sip_location_update_contact(contact_update)) {
|
|
|
|
ast_log(LOG_ERROR, "Failed to update contact '%s' expiration time to %d seconds.\n",
|
|
|
|
contact->uri, expiration);
|
2016-04-01 18:30:56 +00:00
|
|
|
ast_sip_location_delete_contact(contact);
|
2014-05-06 17:47:20 +00:00
|
|
|
continue;
|
|
|
|
}
|
2013-04-25 18:25:31 +00:00
|
|
|
ast_debug(3, "Refreshed contact '%s' on AOR '%s' with new expiration of %d seconds\n",
|
|
|
|
contact_uri, aor_name, expiration);
|
2013-08-12 22:05:18 +00:00
|
|
|
ast_test_suite_event_notify("AOR_CONTACT_REFRESHED",
|
|
|
|
"Contact: %s\r\n"
|
|
|
|
"AOR: %s\r\n"
|
2014-02-17 15:36:45 +00:00
|
|
|
"Expiration: %d\r\n"
|
|
|
|
"UserAgent: %s",
|
2013-08-12 22:05:18 +00:00
|
|
|
contact_uri,
|
|
|
|
aor_name,
|
2014-02-17 15:36:45 +00:00
|
|
|
expiration,
|
2014-03-21 16:04:09 +00:00
|
|
|
contact_update->user_agent);
|
|
|
|
ao2_cleanup(contact_update);
|
2013-04-25 18:25:31 +00:00
|
|
|
} else {
|
2014-02-17 15:36:45 +00:00
|
|
|
/* We want to report the user agent that was actually in the removed contact */
|
2013-04-25 18:25:31 +00:00
|
|
|
ast_sip_location_delete_contact(contact);
|
|
|
|
ast_verb(3, "Removed contact '%s' from AOR '%s' due to request\n", contact_uri, aor_name);
|
2013-08-12 22:05:18 +00:00
|
|
|
ast_test_suite_event_notify("AOR_CONTACT_REMOVED",
|
|
|
|
"Contact: %s\r\n"
|
2014-02-17 15:36:45 +00:00
|
|
|
"AOR: %s\r\n"
|
|
|
|
"UserAgent: %s",
|
2013-08-12 22:05:18 +00:00
|
|
|
contact_uri,
|
2014-02-17 15:36:45 +00:00
|
|
|
aor_name,
|
2016-04-18 22:00:42 +00:00
|
|
|
contact->user_agent);
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pjsip_endpt_release_pool(ast_sip_get_pjsip_endpoint(), details.pool);
|
|
|
|
|
|
|
|
/* If the AOR is configured to remove any existing contacts that have not been updated/added as a result of this REGISTER
|
|
|
|
* do so
|
|
|
|
*/
|
2016-06-04 03:44:46 +00:00
|
|
|
if (aor->remove_existing) {
|
2013-04-25 18:25:31 +00:00
|
|
|
ao2_callback(contacts, OBJ_NODATA | OBJ_MULTIPLE, registrar_delete_contact, NULL);
|
|
|
|
}
|
|
|
|
|
2016-04-01 18:30:56 +00:00
|
|
|
/* Re-retrieve contacts. Caller will clean up the original container. */
|
2016-06-04 03:44:46 +00:00
|
|
|
contacts = ast_sip_location_retrieve_aor_contacts_nolock(aor);
|
2014-01-15 13:16:10 +00:00
|
|
|
response_contact = ao2_callback(contacts, 0, NULL, NULL);
|
2013-04-25 18:25:31 +00:00
|
|
|
|
|
|
|
/* Send a response containing all of the contacts (including static) that are present on this AOR */
|
2016-06-04 03:44:46 +00:00
|
|
|
if (ast_sip_create_response(rdata, 200, response_contact, &tdata) != PJ_SUCCESS) {
|
2014-01-15 13:16:10 +00:00
|
|
|
ao2_cleanup(response_contact);
|
2016-04-01 18:30:56 +00:00
|
|
|
ao2_cleanup(contacts);
|
2013-04-25 18:25:31 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
2014-01-15 13:16:10 +00:00
|
|
|
ao2_cleanup(response_contact);
|
2013-04-25 18:25:31 +00:00
|
|
|
|
|
|
|
/* Add the date header to the response, some UAs use this to set their date and time */
|
|
|
|
registrar_add_date_header(tdata);
|
|
|
|
|
|
|
|
ao2_callback(contacts, 0, registrar_add_contact, tdata);
|
2016-04-01 18:30:56 +00:00
|
|
|
ao2_cleanup(contacts);
|
2013-04-25 18:25:31 +00:00
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if ((expires_hdr = pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_EXPIRES, NULL))) {
|
|
|
|
expires_hdr = pjsip_expires_hdr_create(tdata->pool, registrar_get_expiration(aor, NULL, rdata));
|
2015-02-21 19:28:09 +00:00
|
|
|
pjsip_msg_add_hdr(tdata->msg, (pjsip_hdr*)expires_hdr);
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_sip_send_stateful_response(rdata, tdata, endpoint);
|
2013-04-25 18:25:31 +00:00
|
|
|
|
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
static int register_aor(pjsip_rx_data *rdata,
|
|
|
|
struct ast_sip_endpoint *endpoint,
|
|
|
|
struct ast_sip_aor *aor,
|
|
|
|
const char *aor_name)
|
2016-04-01 18:30:56 +00:00
|
|
|
{
|
|
|
|
int res;
|
|
|
|
struct ao2_container *contacts = NULL;
|
|
|
|
|
2016-08-26 22:22:51 +00:00
|
|
|
ao2_lock(aor);
|
2016-06-04 03:44:46 +00:00
|
|
|
contacts = ast_sip_location_retrieve_aor_contacts_nolock(aor);
|
2016-04-01 18:30:56 +00:00
|
|
|
if (!contacts) {
|
2016-08-26 22:22:51 +00:00
|
|
|
ao2_unlock(aor);
|
2016-04-01 18:30:56 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
res = register_aor_core(rdata, endpoint, aor, aor_name, contacts);
|
2016-04-01 18:30:56 +00:00
|
|
|
ao2_cleanup(contacts);
|
2016-08-26 22:22:51 +00:00
|
|
|
ao2_unlock(aor);
|
2016-04-01 18:30:56 +00:00
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
static int match_aor(const char *aor_name, const char *id)
|
|
|
|
{
|
|
|
|
if (ast_strlen_zero(aor_name)) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!strcmp(aor_name, id)) {
|
|
|
|
ast_debug(3, "Matched id '%s' to aor '%s'\n", id, aor_name);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *find_aor_name(const char *username, const char *domain, const char *aors)
|
|
|
|
{
|
|
|
|
char *configured_aors;
|
2016-08-30 21:40:59 +00:00
|
|
|
char *aors_buf;
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
char *aor_name;
|
|
|
|
char *id_domain;
|
|
|
|
struct ast_sip_domain_alias *alias;
|
|
|
|
|
|
|
|
id_domain = ast_alloca(strlen(username) + strlen(domain) + 2);
|
|
|
|
sprintf(id_domain, "%s@%s", username, domain);
|
|
|
|
|
2016-08-30 21:40:59 +00:00
|
|
|
aors_buf = ast_strdupa(aors);
|
|
|
|
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
/* Look for exact match on username@domain */
|
2016-08-30 21:40:59 +00:00
|
|
|
configured_aors = aors_buf;
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
while ((aor_name = ast_strip(strsep(&configured_aors, ",")))) {
|
|
|
|
if (match_aor(aor_name, id_domain)) {
|
|
|
|
return ast_strdup(aor_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If there's a domain alias, look for exact match on username@domain_alias */
|
|
|
|
alias = ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "domain_alias", domain);
|
|
|
|
if (alias) {
|
|
|
|
char *id_domain_alias = ast_alloca(strlen(username) + strlen(alias->domain) + 2);
|
|
|
|
|
|
|
|
sprintf(id_domain, "%s@%s", username, alias->domain);
|
|
|
|
ao2_cleanup(alias);
|
|
|
|
|
2016-08-30 21:40:59 +00:00
|
|
|
configured_aors = strcpy(aors_buf, aors);/* Safe */
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
while ((aor_name = ast_strip(strsep(&configured_aors, ",")))) {
|
|
|
|
if (match_aor(aor_name, id_domain_alias)) {
|
|
|
|
return ast_strdup(aor_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-30 21:40:59 +00:00
|
|
|
if (ast_strlen_zero(username)) {
|
|
|
|
/* No username, no match */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
/* Look for exact match on username only */
|
2016-08-30 21:40:59 +00:00
|
|
|
configured_aors = strcpy(aors_buf, aors);/* Safe */
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
while ((aor_name = ast_strip(strsep(&configured_aors, ",")))) {
|
|
|
|
if (match_aor(aor_name, username)) {
|
|
|
|
return ast_strdup(aor_name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
static struct ast_sip_aor *find_registrar_aor(struct pjsip_rx_data *rdata, struct ast_sip_endpoint *endpoint)
|
2013-09-26 18:51:54 +00:00
|
|
|
{
|
2016-06-04 03:44:46 +00:00
|
|
|
struct ast_sip_aor *aor = NULL;
|
|
|
|
char *aor_name = NULL;
|
|
|
|
char *domain_name;
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
char *username = NULL;
|
|
|
|
int i;
|
2013-09-26 18:51:54 +00:00
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
for (i = 0; i < AST_VECTOR_SIZE(&endpoint->ident_method_order); ++i) {
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
pjsip_sip_uri *uri;
|
|
|
|
pjsip_authorization_hdr *header = NULL;
|
2013-09-26 18:51:54 +00:00
|
|
|
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
switch (AST_VECTOR_GET(&endpoint->ident_method_order, i)) {
|
2016-06-04 03:44:46 +00:00
|
|
|
case AST_SIP_ENDPOINT_IDENTIFY_BY_USERNAME:
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
uri = pjsip_uri_get_uri(rdata->msg_info.to->uri);
|
2013-09-26 18:51:54 +00:00
|
|
|
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
domain_name = ast_alloca(uri->host.slen + 1);
|
|
|
|
ast_copy_pj_str(domain_name, &uri->host, uri->host.slen + 1);
|
|
|
|
username = ast_alloca(uri->user.slen + 1);
|
|
|
|
ast_copy_pj_str(username, &uri->user, uri->user.slen + 1);
|
2013-09-26 18:51:54 +00:00
|
|
|
|
2016-08-29 23:08:22 +00:00
|
|
|
/*
|
|
|
|
* We may want to match without any user options getting
|
|
|
|
* in the way.
|
|
|
|
*/
|
|
|
|
AST_SIP_USER_OPTIONS_TRUNCATE_CHECK(username);
|
|
|
|
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
aor_name = find_aor_name(username, domain_name, endpoint->aors);
|
|
|
|
if (aor_name) {
|
|
|
|
ast_debug(3, "Matched aor '%s' by To username\n", aor_name);
|
|
|
|
}
|
2013-09-26 18:51:54 +00:00
|
|
|
break;
|
2016-06-04 03:44:46 +00:00
|
|
|
case AST_SIP_ENDPOINT_IDENTIFY_BY_AUTH_USERNAME:
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
while ((header = pjsip_msg_find_hdr(rdata->msg_info.msg, PJSIP_H_AUTHORIZATION,
|
|
|
|
header ? header->next : NULL))) {
|
|
|
|
if (header && !pj_stricmp2(&header->scheme, "digest")) {
|
|
|
|
username = ast_alloca(header->credential.digest.username.slen + 1);
|
|
|
|
ast_copy_pj_str(username, &header->credential.digest.username, header->credential.digest.username.slen + 1);
|
|
|
|
domain_name = ast_alloca(header->credential.digest.realm.slen + 1);
|
|
|
|
ast_copy_pj_str(domain_name, &header->credential.digest.realm, header->credential.digest.realm.slen + 1);
|
|
|
|
|
|
|
|
aor_name = find_aor_name(username, domain_name, endpoint->aors);
|
|
|
|
if (aor_name) {
|
|
|
|
ast_debug(3, "Matched aor '%s' by Authentication username\n", aor_name);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
continue;
|
2013-09-26 18:51:54 +00:00
|
|
|
}
|
|
|
|
|
res_pjsip: Add ability to identify by Authorization username
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
2016-03-08 00:34:31 +00:00
|
|
|
if (aor_name) {
|
2013-09-26 18:51:54 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_strlen_zero(aor_name) || !(aor = ast_sip_location_retrieve_aor(aor_name))) {
|
|
|
|
/* The provided AOR name was not found (be it within the configuration or sorcery itself) */
|
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 404, NULL, NULL, NULL);
|
|
|
|
ast_sip_report_req_no_support(endpoint, rdata, "registrar_requested_aor_not_found");
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_log(LOG_WARNING, "AOR '%s' not found for endpoint '%s'\n",
|
|
|
|
username ?: "", ast_sorcery_object_get_id(endpoint));
|
2013-09-26 18:51:54 +00:00
|
|
|
}
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_free(aor_name);
|
|
|
|
return aor;
|
|
|
|
}
|
2013-09-26 18:51:54 +00:00
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
static pj_bool_t registrar_on_rx_request(struct pjsip_rx_data *rdata)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ast_sip_endpoint *, endpoint,
|
|
|
|
ast_pjsip_rdata_get_endpoint(rdata), ao2_cleanup);
|
|
|
|
struct ast_sip_aor *aor;
|
|
|
|
const char *aor_name;
|
|
|
|
|
|
|
|
if (pjsip_method_cmp(&rdata->msg_info.msg->line.req.method, &pjsip_register_method) || !endpoint) {
|
|
|
|
return PJ_FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_strlen_zero(endpoint->aors)) {
|
|
|
|
/* Short circuit early if the endpoint has no AORs configured on it, which means no registration possible */
|
2013-09-26 18:51:54 +00:00
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 403, NULL, NULL, NULL);
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_sip_report_failed_acl(endpoint, rdata, "registrar_attempt_without_configured_aors");
|
|
|
|
ast_log(LOG_WARNING, "Endpoint '%s' has no configured AORs\n", ast_sorcery_object_get_id(endpoint));
|
2013-09-26 18:51:54 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
if (!PJSIP_URI_SCHEME_IS_SIP(rdata->msg_info.to->uri) && !PJSIP_URI_SCHEME_IS_SIPS(rdata->msg_info.to->uri)) {
|
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 416, NULL, NULL, NULL);
|
|
|
|
ast_sip_report_failed_acl(endpoint, rdata, "registrar_invalid_uri_in_to_received");
|
|
|
|
ast_log(LOG_WARNING, "Endpoint '%s' attempted to register to an AOR with a non-SIP URI\n", ast_sorcery_object_get_id(endpoint));
|
2013-09-26 18:51:54 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
aor = find_registrar_aor(rdata, endpoint);
|
|
|
|
if (!aor) {
|
|
|
|
/* We've already responded about not finding an AOR. */
|
2013-09-26 18:51:54 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2016-06-04 03:44:46 +00:00
|
|
|
aor_name = ast_sorcery_object_get_id(aor);
|
|
|
|
|
|
|
|
if (!aor->max_contacts) {
|
|
|
|
/* Registration is not permitted for this AOR */
|
2013-09-26 18:51:54 +00:00
|
|
|
pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(), rdata, 403, NULL, NULL, NULL);
|
2016-06-04 03:44:46 +00:00
|
|
|
ast_sip_report_req_no_support(endpoint, rdata, "registrar_attempt_without_registration_permitted");
|
|
|
|
ast_log(LOG_WARNING, "AOR '%s' has no configured max_contacts. Endpoint '%s' unable to register\n",
|
|
|
|
aor_name, ast_sorcery_object_get_id(endpoint));
|
|
|
|
} else {
|
|
|
|
register_aor(rdata, endpoint, aor, aor_name);
|
2013-09-26 18:51:54 +00:00
|
|
|
}
|
2016-06-04 03:44:46 +00:00
|
|
|
ao2_ref(aor, -1);
|
2013-09-26 18:51:54 +00:00
|
|
|
return PJ_TRUE;
|
|
|
|
}
|
|
|
|
|
2013-12-04 21:42:39 +00:00
|
|
|
/* function pointer to callback needs to be within the module
|
|
|
|
in order to avoid problems with an undefined symbol */
|
2013-12-20 21:32:13 +00:00
|
|
|
static int sip_contact_to_str(void *acp, void *arg, int flags)
|
2013-12-04 21:42:39 +00:00
|
|
|
{
|
2013-12-20 21:32:13 +00:00
|
|
|
return ast_sip_contact_to_str(acp, arg, flags);
|
2013-12-04 21:42:39 +00:00
|
|
|
}
|
|
|
|
|
2013-11-23 17:26:57 +00:00
|
|
|
static int ami_registrations_aor(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_sip_aor *aor = obj;
|
|
|
|
struct ast_sip_ami *ami = arg;
|
|
|
|
int *count = ami->arg;
|
|
|
|
RAII_VAR(struct ast_str *, buf,
|
|
|
|
ast_sip_create_ami_event("InboundRegistrationDetail", ami), ast_free);
|
|
|
|
|
|
|
|
if (!buf) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_sip_sorcery_object_to_ami(aor, &buf);
|
|
|
|
ast_str_append(&buf, 0, "Contacts: ");
|
2013-12-04 21:42:39 +00:00
|
|
|
ast_sip_for_each_contact(aor, sip_contact_to_str, &buf);
|
2013-11-23 17:26:57 +00:00
|
|
|
ast_str_append(&buf, 0, "\r\n");
|
|
|
|
|
|
|
|
astman_append(ami->s, "%s\r\n", ast_str_buffer(buf));
|
|
|
|
(*count)++;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ami_registrations_endpoint(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_sip_endpoint *endpoint = obj;
|
|
|
|
return ast_sip_for_each_aor(
|
|
|
|
endpoint->aors, ami_registrations_aor, arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ami_registrations_endpoints(void *arg)
|
|
|
|
{
|
|
|
|
RAII_VAR(struct ao2_container *, endpoints,
|
|
|
|
ast_sip_get_endpoints(), ao2_cleanup);
|
|
|
|
|
|
|
|
if (!endpoints) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
ao2_callback(endpoints, OBJ_NODATA, ami_registrations_endpoint, arg);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ami_show_registrations(struct mansession *s, const struct message *m)
|
|
|
|
{
|
|
|
|
int count = 0;
|
2014-06-27 13:50:02 +00:00
|
|
|
struct ast_sip_ami ami = { .s = s, .m = m, .arg = &count, .action_id = astman_get_header(m, "ActionID"), };
|
2015-01-09 18:16:54 +00:00
|
|
|
|
2015-01-12 18:09:27 +00:00
|
|
|
astman_send_listack(s, m, "Following are Events for each Inbound registration",
|
|
|
|
"start");
|
2013-11-23 17:26:57 +00:00
|
|
|
|
|
|
|
ami_registrations_endpoints(&ami);
|
|
|
|
|
2015-01-09 18:16:54 +00:00
|
|
|
astman_send_list_complete_start(s, m, "InboundRegistrationDetailComplete", count);
|
|
|
|
astman_send_list_complete_end(s);
|
2013-11-23 17:26:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-12-06 20:54:25 +00:00
|
|
|
static int ami_show_registration_contact_statuses(struct mansession *s, const struct message *m)
|
|
|
|
{
|
|
|
|
int count = 0;
|
|
|
|
struct ast_sip_ami ami = { .s = s, .m = m, .arg = NULL, .action_id = astman_get_header(m, "ActionID"), };
|
|
|
|
struct ao2_container *contacts = ast_sorcery_retrieve_by_fields(
|
|
|
|
ast_sip_get_sorcery(), "contact", AST_RETRIEVE_FLAG_MULTIPLE | AST_RETRIEVE_FLAG_ALL, NULL);
|
|
|
|
struct ao2_iterator i;
|
|
|
|
struct ast_sip_contact *contact;
|
|
|
|
|
|
|
|
astman_send_listack(s, m, "Following are ContactStatusEvents for each Inbound "
|
|
|
|
"registration", "start");
|
|
|
|
|
|
|
|
if (contacts) {
|
|
|
|
i = ao2_iterator_init(contacts, 0);
|
|
|
|
while ((contact = ao2_iterator_next(&i))) {
|
|
|
|
struct ast_sip_contact_wrapper wrapper;
|
|
|
|
|
|
|
|
wrapper.aor_id = (char *)contact->aor;
|
|
|
|
wrapper.contact = contact;
|
|
|
|
wrapper.contact_id = (char *)ast_sorcery_object_get_id(contact);
|
|
|
|
|
|
|
|
ast_sip_format_contact_ami(&wrapper, &ami, 0);
|
|
|
|
count++;
|
|
|
|
|
|
|
|
ao2_ref(contact, -1);
|
|
|
|
}
|
|
|
|
ao2_iterator_destroy(&i);
|
|
|
|
ao2_ref(contacts, -1);
|
|
|
|
}
|
|
|
|
|
|
|
|
astman_send_list_complete_start(s, m, "ContactStatusDetailComplete", count);
|
|
|
|
astman_send_list_complete_end(s);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define AMI_SHOW_REGISTRATION_CONTACT_STATUSES "PJSIPShowRegistrationInboundContactStatuses"
|
2013-11-23 17:26:57 +00:00
|
|
|
#define AMI_SHOW_REGISTRATIONS "PJSIPShowRegistrationsInbound"
|
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
static pjsip_module registrar_module = {
|
|
|
|
.name = { "Registrar", 9 },
|
|
|
|
.id = -1,
|
|
|
|
.priority = PJSIP_MOD_PRIORITY_APPLICATION,
|
|
|
|
.on_rx_request = registrar_on_rx_request,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int load_module(void)
|
|
|
|
{
|
|
|
|
const pj_str_t STR_REGISTER = { "REGISTER", 8 };
|
|
|
|
|
2016-04-14 12:23:54 +00:00
|
|
|
CHECK_PJPROJECT_MODULE_LOADED();
|
|
|
|
|
|
|
|
ast_pjproject_get_buildopt("PJ_MAX_HOSTNAME", "%d", &pj_max_hostname);
|
|
|
|
/* As of pjproject 2.4.5, PJSIP_MAX_URL_SIZE isn't exposed yet but we try anyway. */
|
|
|
|
ast_pjproject_get_buildopt("PJSIP_MAX_URL_SIZE", "%d", &pjsip_max_url_size);
|
|
|
|
|
2014-10-16 16:32:25 +00:00
|
|
|
CHECK_PJSIP_MODULE_LOADED();
|
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
if (ast_sip_register_service(®istrar_module)) {
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pjsip_endpt_add_capability(ast_sip_get_pjsip_endpoint(), NULL, PJSIP_H_ALLOW, NULL, 1, &STR_REGISTER) != PJ_SUCCESS) {
|
|
|
|
ast_sip_unregister_service(®istrar_module);
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
|
2013-11-23 17:26:57 +00:00
|
|
|
ast_manager_register_xml(AMI_SHOW_REGISTRATIONS, EVENT_FLAG_SYSTEM,
|
|
|
|
ami_show_registrations);
|
2016-12-06 20:54:25 +00:00
|
|
|
ast_manager_register_xml(AMI_SHOW_REGISTRATION_CONTACT_STATUSES, EVENT_FLAG_SYSTEM,
|
|
|
|
ami_show_registration_contact_statuses);
|
2013-11-23 17:26:57 +00:00
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
return AST_MODULE_LOAD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int unload_module(void)
|
|
|
|
{
|
2013-11-23 17:26:57 +00:00
|
|
|
ast_manager_unregister(AMI_SHOW_REGISTRATIONS);
|
2016-12-06 20:54:25 +00:00
|
|
|
ast_manager_unregister(AMI_SHOW_REGISTRATION_CONTACT_STATUSES);
|
2013-04-25 18:25:31 +00:00
|
|
|
ast_sip_unregister_service(®istrar_module);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-30 18:14:50 +00:00
|
|
|
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_LOAD_ORDER, "PJSIP Registrar Support",
|
2015-05-06 00:49:04 +00:00
|
|
|
.support_level = AST_MODULE_SUPPORT_CORE,
|
|
|
|
.load = load_module,
|
|
|
|
.unload = unload_module,
|
2016-05-06 16:54:17 +00:00
|
|
|
.load_pri = AST_MODPRI_CHANNEL_DEPEND - 3,
|
2015-05-06 00:49:04 +00:00
|
|
|
);
|