asterisk/funcs/func_connectedline.c

276 lines
7.9 KiB
C
Raw Normal View History

/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 2007, Gareth Palmer
*
* Gareth Palmer <gareth@acsdata.co.nz>
*
* 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.
*/
/*! \file
*
* \brief Connected Line dialplan function
*
* \ingroup functions
*/
#include "asterisk.h"
ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include "asterisk/module.h"
#include "asterisk/channel.h"
#include "asterisk/pbx.h"
#include "asterisk/logger.h"
#include "asterisk/utils.h"
#include "asterisk/app.h"
#include "asterisk/options.h"
#include "asterisk/callerid.h"
/*
* Do not document the CONNECTEDLINE(source) datatype.
* It has turned out to not be needed. The source value is really
* only useful as a possible tracing aid.
*/
/*** DOCUMENTATION
<function name="CONNECTEDLINE" language="en_US">
<synopsis>
Gets or sets Connected Line data on the channel.
</synopsis>
<syntax>
<parameter name="datatype" required="true">
<para>The allowable datatypes are:</para>
<enumlist>
<enum name = "all" />
<enum name = "num" />
<enum name = "name" />
Enhancements to connected line and redirecting work. From reviewboard: Digium has a commercial customer who has made extensive use of the connected party and redirecting information present in later versions of Asterisk Business Edition and which is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions have come about. This patch adds several enhancements to maximize usage of the connected party and redirecting information functionality. First, Asterisk trunk already had connected line interception macros. These macros allow you to manipulate connected line information before it was sent out to its target. This patch adds the same feature except for redirecting information instead. Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI, mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is that it can be set to whatever value the administrator likes. Later, when running connected line and redirecting macros, the admin can read the tag off the appropriate structure to determine what action to take. You can think of this sort of like a channel variable, except that instead of having the variable associated with a channel, the variable is associated with a specific identity within Asterisk. Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force a specific calling presentation value on the outgoing channel. Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party being transferred would not have the opportunity to run a connected line interception macro to possibly alter the transfer target's connected line information. The issue here was that during a blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line update. The way this was corrected was to add this new control frame subclass. Now, we queue an AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should be run. When ast_read is called to read the frame, ast_read responds by calling a callback function associated with the specific read action the control frame describes. In this case, the action taken is to run the connected line interception macro on the transferee's channel. Review: https://reviewboard.asterisk.org/r/652/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-05-17 15:36:31 +00:00
<enum name = "tag" />
<enum name = "ton" />
<enum name = "pres" />
<enum name = "subaddr[-valid]|[-type]|[-odd]">
<para>ISDN Connected line subaddress</para>
</enum>
</enumlist>
</parameter>
<parameter name="i">
<para>If set, this will prevent the channel from sending out protocol
messages because of the value being set</para>
</parameter>
</syntax>
<description>
<para>Gets or sets Connected Line data on the channel.</para>
</description>
</function>
***/
static int connectedline_read(struct ast_channel *chan, const char *cmd, char *data,
char *buf, size_t len)
{
/* Ensure that the buffer is empty */
*buf = 0;
if (!chan)
return -1;
ast_channel_lock(chan);
if (!strncasecmp("all", data, 3)) {
snprintf(buf, len, "\"%s\" <%s>",
S_OR(chan->connected.id.name, ""),
S_OR(chan->connected.id.number, ""));
} else if (!strncasecmp("name", data, 4)) {
if (chan->connected.id.name) {
ast_copy_string(buf, chan->connected.id.name, len);
}
} else if (!strncasecmp("num", data, 3)) {
if (chan->connected.id.number) {
ast_copy_string(buf, chan->connected.id.number, len);
}
Enhancements to connected line and redirecting work. From reviewboard: Digium has a commercial customer who has made extensive use of the connected party and redirecting information present in later versions of Asterisk Business Edition and which is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions have come about. This patch adds several enhancements to maximize usage of the connected party and redirecting information functionality. First, Asterisk trunk already had connected line interception macros. These macros allow you to manipulate connected line information before it was sent out to its target. This patch adds the same feature except for redirecting information instead. Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI, mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is that it can be set to whatever value the administrator likes. Later, when running connected line and redirecting macros, the admin can read the tag off the appropriate structure to determine what action to take. You can think of this sort of like a channel variable, except that instead of having the variable associated with a channel, the variable is associated with a specific identity within Asterisk. Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force a specific calling presentation value on the outgoing channel. Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party being transferred would not have the opportunity to run a connected line interception macro to possibly alter the transfer target's connected line information. The issue here was that during a blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line update. The way this was corrected was to add this new control frame subclass. Now, we queue an AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should be run. When ast_read is called to read the frame, ast_read responds by calling a callback function associated with the specific read action the control frame describes. In this case, the action taken is to run the connected line interception macro on the transferee's channel. Review: https://reviewboard.asterisk.org/r/652/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-05-17 15:36:31 +00:00
} else if (!strncasecmp("tag", data, 3)) {
if (chan->connected.id.tag) {
ast_copy_string(buf, chan->connected.id.tag, len);
}
} else if (!strncasecmp("ton", data, 3)) {
snprintf(buf, len, "%d", chan->connected.id.number_type);
} else if (!strncasecmp("pres", data, 4)) {
ast_copy_string(buf, ast_named_caller_presentation(chan->connected.id.number_presentation), len);
} else if (!strncasecmp("source", data, 6)) {
ast_copy_string(buf, ast_connected_line_source_name(chan->connected.source), len);
} else if (!strncasecmp("subaddr", data, 7)) {
/* also matches subaddr-valid, subaddr-type, subaddr-odd, subaddr */
if (!strncasecmp(data + 7 ,"-valid", 6)) { /* subaddr-valid */
snprintf(buf, len, "%d", chan->connected.id.subaddress.valid);
} else if (!strncasecmp(data + 7 ,"-type", 5)) { /* subaddr-type */
snprintf(buf, len, "%d", chan->connected.id.subaddress.type);
} else if (!strncasecmp(data + 7 ,"-odd", 4)) { /* subaddr-odd */
snprintf(buf, len, "%d", chan->connected.id.subaddress.odd_even_indicator);
} else { /* subaddr */
if (chan->connected.id.subaddress.str) {
ast_copy_string(buf, chan->connected.id.subaddress.str, len);
}
}
} else {
ast_log(LOG_ERROR, "Unknown connectedline data type '%s'.\n", data);
}
ast_channel_unlock(chan);
return 0;
}
static int connectedline_write(struct ast_channel *chan, const char *cmd, char *data,
const char *value)
{
struct ast_party_connected_line connected;
char *val;
char *option;
void (*set_it)(struct ast_channel *chan, const struct ast_party_connected_line *connected);
if (!value || !chan) {
return -1;
}
/* Determine if the update indication inhibit option is present */
option = strchr(data, ',');
if (option) {
option = ast_skip_blanks(option + 1);
switch (*option) {
case 'i':
set_it = ast_channel_set_connected_line;
break;
default:
ast_log(LOG_ERROR, "Unknown connectedline option '%s'.\n", option);
return 0;
}
}
else {
set_it = ast_channel_update_connected_line;
}
ast_channel_lock(chan);
ast_party_connected_line_set_init(&connected, &chan->connected);
ast_channel_unlock(chan);
value = ast_skip_blanks(value);
if (!strncasecmp("all", data, 3)) {
char name[256];
char num[256];
ast_callerid_split(value, name, sizeof(name), num, sizeof(num));
connected.id.name = name;
connected.id.number = num;
set_it(chan, &connected);
} else if (!strncasecmp("name", data, 4)) {
connected.id.name = ast_strdupa(value);
ast_trim_blanks(connected.id.name);
set_it(chan, &connected);
} else if (!strncasecmp("num", data, 3)) {
connected.id.number = ast_strdupa(value);
ast_trim_blanks(connected.id.number);
set_it(chan, &connected);
Enhancements to connected line and redirecting work. From reviewboard: Digium has a commercial customer who has made extensive use of the connected party and redirecting information present in later versions of Asterisk Business Edition and which is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions have come about. This patch adds several enhancements to maximize usage of the connected party and redirecting information functionality. First, Asterisk trunk already had connected line interception macros. These macros allow you to manipulate connected line information before it was sent out to its target. This patch adds the same feature except for redirecting information instead. Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI, mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is that it can be set to whatever value the administrator likes. Later, when running connected line and redirecting macros, the admin can read the tag off the appropriate structure to determine what action to take. You can think of this sort of like a channel variable, except that instead of having the variable associated with a channel, the variable is associated with a specific identity within Asterisk. Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force a specific calling presentation value on the outgoing channel. Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party being transferred would not have the opportunity to run a connected line interception macro to possibly alter the transfer target's connected line information. The issue here was that during a blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line update. The way this was corrected was to add this new control frame subclass. Now, we queue an AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should be run. When ast_read is called to read the frame, ast_read responds by calling a callback function associated with the specific read action the control frame describes. In this case, the action taken is to run the connected line interception macro on the transferee's channel. Review: https://reviewboard.asterisk.org/r/652/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-05-17 15:36:31 +00:00
} else if (!strncasecmp("tag", data, 3)) {
connected.id.tag = ast_strdupa(value);
ast_trim_blanks(connected.id.tag);
set_it(chan, &connected);
} else if (!strncasecmp("ton", data, 3)) {
val = ast_strdupa(value);
ast_trim_blanks(val);
if (('0' <= val[0]) && (val[0] <= '9')) {
connected.id.number_type = atoi(val);
set_it(chan, &connected);
} else {
ast_log(LOG_ERROR, "Unknown connectedline type of number '%s', value unchanged\n", val);
}
} else if (!strncasecmp("pres", data, 4)) {
int pres;
val = ast_strdupa(value);
ast_trim_blanks(val);
if (('0' <= val[0]) && (val[0] <= '9')) {
pres = atoi(val);
} else {
pres = ast_parse_caller_presentation(val);
}
if (pres < 0) {
ast_log(LOG_ERROR, "Unknown connectedline number presentation '%s', value unchanged\n", val);
} else {
connected.id.number_presentation = pres;
set_it(chan, &connected);
}
} else if (!strncasecmp("source", data, 6)) {
int source;
val = ast_strdupa(value);
ast_trim_blanks(val);
if (('0' <= val[0]) && (val[0] <= '9')) {
source = atoi(val);
} else {
source = ast_connected_line_source_parse(val);
}
if (source < 0) {
ast_log(LOG_ERROR, "Unknown connectedline source '%s', value unchanged\n", val);
} else {
connected.source = source;
set_it(chan, &connected);
}
} else if (!strncasecmp("subaddr", data, 7)) { /* outbound: set calling subaddress */
/* also matches subaddr-valid, subaddr-type, subaddr-odd, subaddr */
if (!strncasecmp(data + 7 ,"-valid", 6)) { /* subaddr-valid */
connected.id.subaddress.valid = atoi(value) ? 1 : 0;
} else if (!strncasecmp(data + 7 ,"-type", 5)) { /* subaddr-type */
connected.id.subaddress.type = atoi(value) ? 2 : 0;
} else if (!strncasecmp(data + 7 ,"-odd", 4)) { /* subaddr-odd */
connected.id.subaddress.odd_even_indicator = atoi(value) ? 1 : 0;
} else { /* subaddr */
connected.id.subaddress.str = ast_strdupa(value);
ast_trim_blanks(connected.id.subaddress.str);
}
set_it(chan, &connected);
} else {
ast_log(LOG_ERROR, "Unknown connectedline data type '%s'.\n", data);
}
return 0;
}
static struct ast_custom_function connectedline_function = {
.name = "CONNECTEDLINE",
.read = connectedline_read,
.write = connectedline_write,
};
static int unload_module(void)
{
return ast_custom_function_unregister(&connectedline_function);
}
static int load_module(void)
{
return ast_custom_function_register(&connectedline_function)
? AST_MODULE_LOAD_DECLINE
: AST_MODULE_LOAD_SUCCESS;
}
AST_MODULE_INFO_STANDARD(ASTERISK_GPL_KEY, "Connected Line dialplan function");