2001-12-27 11:07:33 +00:00
|
|
|
/*
|
2005-09-14 20:46:50 +00:00
|
|
|
* Asterisk -- An open source telephony toolkit.
|
2001-12-27 11:07:33 +00:00
|
|
|
*
|
2008-01-23 23:09:11 +00:00
|
|
|
* Copyright (C) 1999 - 2008, Digium, Inc.
|
2001-12-27 11:07:33 +00:00
|
|
|
*
|
2004-08-31 13:32:11 +00:00
|
|
|
* Mark Spencer <markster@digium.com>
|
2001-12-27 11:07:33 +00:00
|
|
|
*
|
2005-09-14 20:46:50 +00:00
|
|
|
* 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.
|
|
|
|
*
|
2001-12-27 11:07:33 +00:00
|
|
|
* This program is free software, distributed under the terms of
|
2005-09-14 20:46:50 +00:00
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
* at the top of the source tree.
|
|
|
|
*/
|
|
|
|
|
2005-10-24 20:12:06 +00:00
|
|
|
/*! \file
|
2005-09-14 20:46:50 +00:00
|
|
|
*
|
2006-01-19 22:09:18 +00:00
|
|
|
* \brief Routines implementing call features as call pickup, parking and transfer
|
2005-12-30 21:18:06 +00:00
|
|
|
*
|
2012-03-22 19:51:16 +00:00
|
|
|
* \author Mark Spencer <markster@digium.com>
|
2001-12-27 11:07:33 +00:00
|
|
|
*/
|
|
|
|
|
2011-07-14 20:28:54 +00:00
|
|
|
/*** MODULEINFO
|
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
2006-06-07 18:54:56 +00:00
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
|
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
#include "asterisk/_private.h"
|
|
|
|
|
2005-06-06 22:12:19 +00:00
|
|
|
#include <pthread.h>
|
2010-03-20 12:03:07 +00:00
|
|
|
#include <signal.h>
|
2005-06-06 22:12:19 +00:00
|
|
|
#include <sys/time.h>
|
|
|
|
#include <sys/signal.h>
|
|
|
|
#include <netinet/in.h>
|
|
|
|
|
2005-04-21 06:02:45 +00:00
|
|
|
#include "asterisk/lock.h"
|
|
|
|
#include "asterisk/file.h"
|
|
|
|
#include "asterisk/channel.h"
|
|
|
|
#include "asterisk/pbx.h"
|
2005-06-23 22:12:01 +00:00
|
|
|
#include "asterisk/causes.h"
|
2005-04-21 06:02:45 +00:00
|
|
|
#include "asterisk/module.h"
|
|
|
|
#include "asterisk/translate.h"
|
|
|
|
#include "asterisk/app.h"
|
|
|
|
#include "asterisk/say.h"
|
|
|
|
#include "asterisk/features.h"
|
|
|
|
#include "asterisk/musiconhold.h"
|
|
|
|
#include "asterisk/config.h"
|
|
|
|
#include "asterisk/cli.h"
|
|
|
|
#include "asterisk/manager.h"
|
|
|
|
#include "asterisk/utils.h"
|
|
|
|
#include "asterisk/adsi.h"
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
#include "asterisk/devicestate.h"
|
2005-11-08 04:02:35 +00:00
|
|
|
#include "asterisk/monitor.h"
|
2007-11-30 21:19:57 +00:00
|
|
|
#include "asterisk/audiohook.h"
|
2008-03-01 01:30:37 +00:00
|
|
|
#include "asterisk/global_datastores.h"
|
2008-04-21 23:42:45 +00:00
|
|
|
#include "asterisk/astobj2.h"
|
2009-06-26 15:28:53 +00:00
|
|
|
#include "asterisk/cel.h"
|
2010-03-10 20:51:23 +00:00
|
|
|
#include "asterisk/test.h"
|
2001-12-27 11:07:33 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/*
|
|
|
|
* Party A - transferee
|
|
|
|
* Party B - transferer
|
|
|
|
* Party C - target of transfer
|
|
|
|
*
|
|
|
|
* DTMF attended transfer works within the channel bridge.
|
|
|
|
* Unfortunately, when either party A or B in the channel bridge
|
|
|
|
* hangs up, that channel is not completely hung up until the
|
|
|
|
* transfer completes. This is a real problem depending upon
|
|
|
|
* the channel technology involved.
|
|
|
|
*
|
|
|
|
* For chan_dahdi, the channel is crippled until the hangup is
|
|
|
|
* complete. Either the channel is not useable (analog) or the
|
|
|
|
* protocol disconnect messages are held up (PRI/BRI/SS7) and
|
|
|
|
* the media is not released.
|
|
|
|
*
|
|
|
|
* For chan_sip, a call limit of one is going to block that
|
|
|
|
* endpoint from any further calls until the hangup is complete.
|
|
|
|
*
|
|
|
|
* For party A this is a minor problem. The party A channel
|
|
|
|
* will only be in this condition while party B is dialing and
|
|
|
|
* when party B and C are conferring. The conversation between
|
|
|
|
* party B and C is expected to be a short one. Party B is
|
|
|
|
* either asking a question of party C or announcing party A.
|
|
|
|
* Also party A does not have much incentive to hangup at this
|
|
|
|
* point.
|
|
|
|
*
|
|
|
|
* For party B this can be a major problem during a blonde
|
|
|
|
* transfer. (A blonde transfer is our term for an attended
|
|
|
|
* transfer that is converted into a blind transfer. :)) Party
|
|
|
|
* B could be the operator. When party B hangs up, he assumes
|
|
|
|
* that he is out of the original call entirely. The party B
|
|
|
|
* channel will be in this condition while party C is ringing,
|
|
|
|
* while attempting to recall party B, and while waiting between
|
|
|
|
* call attempts.
|
|
|
|
*
|
|
|
|
* WARNING:
|
|
|
|
* The ATXFER_NULL_TECH conditional is a hack to fix the
|
|
|
|
* problem. It will replace the party B channel technology with
|
|
|
|
* a NULL channel driver. The consequences of this code is that
|
|
|
|
* the 'h' extension will not be able to access any channel
|
|
|
|
* technology specific information like SIP statistics for the
|
|
|
|
* call.
|
|
|
|
*
|
|
|
|
* Uncomment the ATXFER_NULL_TECH define below to replace the
|
|
|
|
* party B channel technology in the channel bridge to complete
|
|
|
|
* hanging up the channel technology.
|
|
|
|
*/
|
|
|
|
//#define ATXFER_NULL_TECH 1
|
|
|
|
|
2008-11-01 21:10:07 +00:00
|
|
|
/*** DOCUMENTATION
|
|
|
|
<application name="Bridge" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
Bridge two channels.
|
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<parameter name="channel" required="true">
|
|
|
|
<para>The current channel is bridged to the specified <replaceable>channel</replaceable>.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="options">
|
|
|
|
<optionlist>
|
|
|
|
<option name="p">
|
|
|
|
<para>Play a courtesy tone to <replaceable>channel</replaceable>.</para>
|
|
|
|
</option>
|
2012-03-22 21:25:22 +00:00
|
|
|
<option name="F" argsep="^">
|
|
|
|
<argument name="context" required="false" />
|
|
|
|
<argument name="exten" required="false" />
|
|
|
|
<argument name="priority" required="true" />
|
|
|
|
<para>When the bridger hangs up, transfer the <emphasis>bridged</emphasis> party
|
|
|
|
to the specified destination and <emphasis>start</emphasis> execution at that location.</para>
|
|
|
|
<note>
|
|
|
|
<para>Any channel variables you want the called channel to inherit from the caller channel must be
|
|
|
|
prefixed with one or two underbars ('_').</para>
|
|
|
|
</note>
|
|
|
|
<note>
|
|
|
|
<para>This option will override the 'x' option</para>
|
|
|
|
</note>
|
|
|
|
</option>
|
|
|
|
<option name="F">
|
|
|
|
<para>When the bridger hangs up, transfer the <emphasis>bridged</emphasis> party
|
|
|
|
to the next priority of the current extension and <emphasis>start</emphasis> execution
|
|
|
|
at that location.</para>
|
|
|
|
<note>
|
|
|
|
<para>Any channel variables you want the called channel to inherit from the caller channel must be
|
|
|
|
prefixed with one or two underbars ('_').</para>
|
|
|
|
</note>
|
|
|
|
<note>
|
|
|
|
<para>Using this option from a Macro() or GoSub() might not make sense as there would be no return points.</para>
|
|
|
|
</note>
|
|
|
|
<note>
|
|
|
|
<para>This option will override the 'x' option</para>
|
|
|
|
</note>
|
|
|
|
</option>
|
|
|
|
|
2009-09-24 20:29:51 +00:00
|
|
|
<option name="h">
|
|
|
|
<para>Allow the called party to hang up by sending the
|
|
|
|
<replaceable>*</replaceable> DTMF digit.</para>
|
|
|
|
</option>
|
|
|
|
<option name="H">
|
|
|
|
<para>Allow the calling party to hang up by pressing the
|
|
|
|
<replaceable>*</replaceable> DTMF digit.</para>
|
|
|
|
</option>
|
|
|
|
<option name="k">
|
|
|
|
<para>Allow the called party to enable parking of the call by sending
|
2011-08-16 17:23:08 +00:00
|
|
|
the DTMF sequence defined for call parking in <filename>features.conf</filename>.</para>
|
2009-09-24 20:29:51 +00:00
|
|
|
</option>
|
|
|
|
<option name="K">
|
|
|
|
<para>Allow the calling party to enable parking of the call by sending
|
2011-08-16 17:23:08 +00:00
|
|
|
the DTMF sequence defined for call parking in <filename>features.conf</filename>.</para>
|
2009-09-24 20:29:51 +00:00
|
|
|
</option>
|
|
|
|
<option name="L(x[:y][:z])">
|
|
|
|
<para>Limit the call to <replaceable>x</replaceable> ms. Play a warning
|
|
|
|
when <replaceable>y</replaceable> ms are left. Repeat the warning every
|
|
|
|
<replaceable>z</replaceable> ms. The following special variables can be
|
|
|
|
used with this option:</para>
|
|
|
|
<variablelist>
|
|
|
|
<variable name="LIMIT_PLAYAUDIO_CALLER">
|
|
|
|
<para>Play sounds to the caller. yes|no (default yes)</para>
|
|
|
|
</variable>
|
2012-03-22 19:51:16 +00:00
|
|
|
<variable name="LIMIT_PLAYAUDIO_CALLEE">
|
2009-09-24 20:29:51 +00:00
|
|
|
<para>Play sounds to the callee. yes|no</para>
|
|
|
|
</variable>
|
|
|
|
<variable name="LIMIT_TIMEOUT_FILE">
|
|
|
|
<para>File to play when time is up.</para>
|
|
|
|
</variable>
|
|
|
|
<variable name="LIMIT_CONNECT_FILE">
|
|
|
|
<para>File to play when call begins.</para>
|
|
|
|
</variable>
|
|
|
|
<variable name="LIMIT_WARNING_FILE">
|
|
|
|
<para>File to play as warning if <replaceable>y</replaceable> is
|
|
|
|
defined. The default is to say the time remaining.</para>
|
|
|
|
</variable>
|
|
|
|
</variablelist>
|
|
|
|
</option>
|
|
|
|
<option name="S(x)">
|
|
|
|
<para>Hang up the call after <replaceable>x</replaceable> seconds *after* the called party has answered the call.</para>
|
|
|
|
</option>
|
|
|
|
<option name="t">
|
|
|
|
<para>Allow the called party to transfer the calling party by sending the
|
2011-08-16 17:23:08 +00:00
|
|
|
DTMF sequence defined in <filename>features.conf</filename>.</para>
|
2009-09-24 20:29:51 +00:00
|
|
|
</option>
|
|
|
|
<option name="T">
|
|
|
|
<para>Allow the calling party to transfer the called party by sending the
|
2011-08-16 17:23:08 +00:00
|
|
|
DTMF sequence defined in <filename>features.conf</filename>.</para>
|
2009-09-24 20:29:51 +00:00
|
|
|
</option>
|
|
|
|
<option name="w">
|
|
|
|
<para>Allow the called party to enable recording of the call by sending
|
2011-08-16 17:23:08 +00:00
|
|
|
the DTMF sequence defined for one-touch recording in <filename>features.conf</filename>.</para>
|
2009-09-24 20:29:51 +00:00
|
|
|
</option>
|
|
|
|
<option name="W">
|
|
|
|
<para>Allow the calling party to enable recording of the call by sending
|
2011-08-16 17:23:08 +00:00
|
|
|
the DTMF sequence defined for one-touch recording in <filename>features.conf</filename>.</para>
|
2009-09-24 20:29:51 +00:00
|
|
|
</option>
|
|
|
|
<option name="x">
|
|
|
|
<para>Cause the called party to be hung up after the bridge, instead of being
|
|
|
|
restarted in the dialplan.</para>
|
|
|
|
</option>
|
2008-11-01 21:10:07 +00:00
|
|
|
</optionlist>
|
|
|
|
</parameter>
|
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para>Allows the ability to bridge two channels via the dialplan.</para>
|
|
|
|
<para>This application sets the following channel variable upon completion:</para>
|
|
|
|
<variablelist>
|
|
|
|
<variable name="BRIDGERESULT">
|
|
|
|
<para>The result of the bridge attempt as a text string.</para>
|
|
|
|
<value name="SUCCESS" />
|
|
|
|
<value name="FAILURE" />
|
|
|
|
<value name="LOOP" />
|
|
|
|
<value name="NONEXISTENT" />
|
|
|
|
<value name="INCOMPATIBLE" />
|
|
|
|
</variable>
|
|
|
|
</variablelist>
|
|
|
|
</description>
|
|
|
|
</application>
|
|
|
|
<application name="ParkedCall" language="en_US">
|
|
|
|
<synopsis>
|
2011-08-16 17:23:08 +00:00
|
|
|
Retrieve a parked call.
|
2008-11-01 21:10:07 +00:00
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
2011-08-16 17:23:08 +00:00
|
|
|
<parameter name="exten">
|
|
|
|
<para>Parking space extension to retrieve a parked call.
|
|
|
|
If not provided then the first available parked call in the
|
|
|
|
parking lot will be retrieved.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="parking_lot_name">
|
|
|
|
<para>Specify from which parking lot to retrieve a parked call.</para>
|
|
|
|
<para>The parking lot used is selected in the following order:</para>
|
|
|
|
<para>1) parking_lot_name option</para>
|
|
|
|
<para>2) <variable>PARKINGLOT</variable> variable</para>
|
|
|
|
<para>3) <literal>CHANNEL(parkinglot)</literal> function
|
|
|
|
(Possibly preset by the channel driver.)</para>
|
|
|
|
<para>4) Default parking lot.</para>
|
|
|
|
</parameter>
|
2008-11-01 21:10:07 +00:00
|
|
|
</syntax>
|
|
|
|
<description>
|
2011-08-16 17:23:08 +00:00
|
|
|
<para>Used to retrieve a parked call from a parking lot.</para>
|
|
|
|
<note>
|
|
|
|
<para>Parking lots automatically create and manage dialplan extensions in
|
|
|
|
the parking lot context. You do not need to explicitly use this
|
|
|
|
application in your dialplan. Instead, all you should do is include the
|
|
|
|
parking lot context in your dialplan.</para>
|
|
|
|
</note>
|
2008-11-01 21:10:07 +00:00
|
|
|
</description>
|
2008-11-05 14:37:07 +00:00
|
|
|
<see-also>
|
|
|
|
<ref type="application">Park</ref>
|
|
|
|
<ref type="application">ParkAndAnnounce</ref>
|
|
|
|
</see-also>
|
2008-11-01 21:10:07 +00:00
|
|
|
</application>
|
|
|
|
<application name="Park" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
Park yourself.
|
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<parameter name="timeout">
|
2010-12-20 16:19:22 +00:00
|
|
|
<para>A custom parking timeout for this parked call. Value in milliseconds.</para>
|
2008-11-01 21:10:07 +00:00
|
|
|
</parameter>
|
|
|
|
<parameter name="return_context">
|
|
|
|
<para>The context to return the call to after it times out.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="return_exten">
|
|
|
|
<para>The extension to return the call to after it times out.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="return_priority">
|
|
|
|
<para>The priority to return the call to after it times out.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="options">
|
|
|
|
<para>A list of options for this parked call.</para>
|
|
|
|
<optionlist>
|
|
|
|
<option name="r">
|
|
|
|
<para>Send ringing instead of MOH to the parked call.</para>
|
|
|
|
</option>
|
|
|
|
<option name="R">
|
|
|
|
<para>Randomize the selection of a parking space.</para>
|
|
|
|
</option>
|
|
|
|
<option name="s">
|
|
|
|
<para>Silence announcement of the parking space number.</para>
|
|
|
|
</option>
|
|
|
|
</optionlist>
|
|
|
|
</parameter>
|
2011-08-16 17:23:08 +00:00
|
|
|
<parameter name="parking_lot_name">
|
|
|
|
<para>Specify in which parking lot to park a call.</para>
|
|
|
|
<para>The parking lot used is selected in the following order:</para>
|
|
|
|
<para>1) parking_lot_name option</para>
|
|
|
|
<para>2) <variable>PARKINGLOT</variable> variable</para>
|
|
|
|
<para>3) <literal>CHANNEL(parkinglot)</literal> function
|
|
|
|
(Possibly preset by the channel driver.)</para>
|
|
|
|
<para>4) Default parking lot.</para>
|
|
|
|
</parameter>
|
2008-11-01 21:10:07 +00:00
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para>Used to park yourself (typically in combination with a supervised
|
2011-08-16 17:23:08 +00:00
|
|
|
transfer to know the parking space).</para>
|
|
|
|
<para>If you set the <variable>PARKINGEXTEN</variable> variable to a
|
|
|
|
parking space extension in the parking lot, Park() will attempt to park the call
|
|
|
|
on that extension. If the extension is already is in use then execution
|
|
|
|
will continue at the next priority.</para>
|
|
|
|
<para>If the <literal>parkeddynamic</literal> option is enabled in <filename>features.conf</filename>
|
|
|
|
the following variables can be used to dynamically create new parking lots.</para>
|
|
|
|
<para>If you set the <variable>PARKINGDYNAMIC</variable> variable and this parking lot
|
|
|
|
exists then it will be used as a template for the newly created dynamic lot. Otherwise,
|
|
|
|
the default parking lot will be used.</para>
|
|
|
|
<para>If you set the <variable>PARKINGDYNCONTEXT</variable> variable then the newly created dynamic
|
2010-02-17 18:29:48 +00:00
|
|
|
parking lot will use this context.</para>
|
2011-08-16 17:23:08 +00:00
|
|
|
<para>If you set the <variable>PARKINGDYNEXTEN</variable> variable then the newly created dynamic
|
|
|
|
parking lot will use this extension to access the parking lot.</para>
|
|
|
|
<para>If you set the <variable>PARKINGDYNPOS</variable> variable then the newly created dynamic parking lot
|
2010-02-17 18:29:48 +00:00
|
|
|
will use those parking postitions.</para>
|
2011-08-16 17:23:08 +00:00
|
|
|
<note>
|
|
|
|
<para>This application must be used as the first extension priority
|
|
|
|
to be recognized as a parking access extension. DTMF transfers
|
|
|
|
and some channel drivers need this distinction to operate properly.
|
|
|
|
The parking access extension in this case is treated like a dialplan
|
|
|
|
hint.</para>
|
|
|
|
</note>
|
|
|
|
<note>
|
|
|
|
<para>Parking lots automatically create and manage dialplan extensions in
|
|
|
|
the parking lot context. You do not need to explicitly use this
|
|
|
|
application in your dialplan. Instead, all you should do is include the
|
|
|
|
parking lot context in your dialplan.</para>
|
|
|
|
</note>
|
2008-11-01 21:10:07 +00:00
|
|
|
</description>
|
2008-11-05 14:37:07 +00:00
|
|
|
<see-also>
|
|
|
|
<ref type="application">ParkAndAnnounce</ref>
|
|
|
|
<ref type="application">ParkedCall</ref>
|
|
|
|
</see-also>
|
2008-11-01 21:10:07 +00:00
|
|
|
</application>
|
2009-05-22 17:52:35 +00:00
|
|
|
<manager name="ParkedCalls" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
List parked calls.
|
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<xi:include xpointer="xpointer(/docs/manager[@name='Login']/syntax/parameter[@name='ActionID'])" />
|
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para>List parked calls.</para>
|
|
|
|
</description>
|
|
|
|
</manager>
|
|
|
|
<manager name="Park" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
Park a channel.
|
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<xi:include xpointer="xpointer(/docs/manager[@name='Login']/syntax/parameter[@name='ActionID'])" />
|
|
|
|
<parameter name="Channel" required="true">
|
|
|
|
<para>Channel name to park.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="Channel2" required="true">
|
2011-09-07 19:35:18 +00:00
|
|
|
<para>Channel to return to if timeout.</para>
|
2009-05-22 17:52:35 +00:00
|
|
|
</parameter>
|
|
|
|
<parameter name="Timeout">
|
|
|
|
<para>Number of milliseconds to wait before callback.</para>
|
|
|
|
</parameter>
|
2010-09-15 19:23:56 +00:00
|
|
|
<parameter name="Parkinglot">
|
2011-08-16 17:23:08 +00:00
|
|
|
<para>Specify in which parking lot to park the channel.</para>
|
2010-09-15 19:23:56 +00:00
|
|
|
</parameter>
|
2009-05-22 17:52:35 +00:00
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para>Park a channel.</para>
|
|
|
|
</description>
|
|
|
|
</manager>
|
|
|
|
<manager name="Bridge" language="en_US">
|
|
|
|
<synopsis>
|
|
|
|
Bridge two channels already in the PBX.
|
|
|
|
</synopsis>
|
|
|
|
<syntax>
|
|
|
|
<xi:include xpointer="xpointer(/docs/manager[@name='Login']/syntax/parameter[@name='ActionID'])" />
|
|
|
|
<parameter name="Channel1" required="true">
|
|
|
|
<para>Channel to Bridge to Channel2.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="Channel2" required="true">
|
|
|
|
<para>Channel to Bridge to Channel1.</para>
|
|
|
|
</parameter>
|
|
|
|
<parameter name="Tone">
|
|
|
|
<para>Play courtesy tone to Channel 2.</para>
|
|
|
|
<enumlist>
|
|
|
|
<enum name="yes" />
|
|
|
|
<enum name="no" />
|
|
|
|
</enumlist>
|
|
|
|
</parameter>
|
|
|
|
</syntax>
|
|
|
|
<description>
|
|
|
|
<para>Bridge together two channels already in the PBX.</para>
|
|
|
|
</description>
|
|
|
|
</manager>
|
2008-11-01 21:10:07 +00:00
|
|
|
***/
|
|
|
|
|
2011-01-03 23:18:20 +00:00
|
|
|
#define DEFAULT_PARK_TIME 45000 /*!< ms */
|
|
|
|
#define DEFAULT_PARK_EXTENSION "700"
|
|
|
|
#define DEFAULT_TRANSFER_DIGIT_TIMEOUT 3000 /*!< ms */
|
|
|
|
#define DEFAULT_FEATURE_DIGIT_TIMEOUT 1000 /*!< ms */
|
|
|
|
#define DEFAULT_NOANSWER_TIMEOUT_ATTENDED_TRANSFER 15000 /*!< ms */
|
|
|
|
#define DEFAULT_ATXFER_DROP_CALL 0 /*!< Do not drop call. */
|
|
|
|
#define DEFAULT_ATXFER_LOOP_DELAY 10000 /*!< ms */
|
|
|
|
#define DEFAULT_ATXFER_CALLBACK_RETRIES 2
|
2012-01-20 20:47:42 +00:00
|
|
|
#define DEFAULT_COMEBACK_CONTEXT "parkedcallstimeout"
|
|
|
|
#define DEFAULT_COMEBACK_TO_ORIGIN 1
|
|
|
|
#define DEFAULT_COMEBACK_DIAL_TIME 30
|
2003-02-02 19:37:23 +00:00
|
|
|
|
2005-06-23 22:12:01 +00:00
|
|
|
#define AST_MAX_WATCHERS 256
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
#define MAX_DIAL_FEATURE_OPTIONS 30
|
2005-06-23 22:12:01 +00:00
|
|
|
|
2007-05-31 18:21:47 +00:00
|
|
|
struct feature_group_exten {
|
|
|
|
AST_LIST_ENTRY(feature_group_exten) entry;
|
|
|
|
AST_DECLARE_STRING_FIELDS(
|
|
|
|
AST_STRING_FIELD(exten);
|
|
|
|
);
|
|
|
|
struct ast_call_feature *feature;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct feature_group {
|
|
|
|
AST_LIST_ENTRY(feature_group) entry;
|
|
|
|
AST_DECLARE_STRING_FIELDS(
|
|
|
|
AST_STRING_FIELD(gname);
|
|
|
|
);
|
|
|
|
AST_LIST_HEAD_NOLOCK(, feature_group_exten) features;
|
|
|
|
};
|
|
|
|
|
|
|
|
static AST_RWLIST_HEAD_STATIC(feature_groups, feature_group);
|
|
|
|
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
typedef enum {
|
|
|
|
FEATURE_INTERPRET_DETECT, /* Used by ast_feature_detect */
|
|
|
|
FEATURE_INTERPRET_DO, /* Used by feature_interpret */
|
|
|
|
FEATURE_INTERPRET_CHECK, /* Used by feature_check */
|
|
|
|
} feature_interpret_op;
|
|
|
|
|
2011-10-20 22:03:35 +00:00
|
|
|
static const char *parkedcall = "ParkedCall";
|
2001-12-27 11:07:33 +00:00
|
|
|
|
2006-06-21 07:49:29 +00:00
|
|
|
static char pickup_ext[AST_MAX_EXTENSION]; /*!< Call pickup extension */
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Parking lot access ramp dialplan usage entry. */
|
|
|
|
struct parking_dp_ramp {
|
|
|
|
/*! Next node in the parking lot spaces dialplan list. */
|
|
|
|
AST_LIST_ENTRY(parking_dp_ramp) node;
|
|
|
|
/*! TRUE if the parking lot access extension is exclusive. */
|
|
|
|
unsigned int exclusive:1;
|
|
|
|
/*! Parking lot access extension */
|
|
|
|
char exten[1];
|
|
|
|
};
|
|
|
|
|
|
|
|
/*! Parking lot dialplan access ramp map */
|
|
|
|
AST_LIST_HEAD_NOLOCK(parking_dp_ramp_map, parking_dp_ramp);
|
|
|
|
|
|
|
|
/*! Parking lot spaces dialplan usage entry. */
|
|
|
|
struct parking_dp_spaces {
|
|
|
|
/*! Next node in the parking lot spaces dialplan list. */
|
|
|
|
AST_LIST_ENTRY(parking_dp_spaces) node;
|
|
|
|
/*! First parking space */
|
|
|
|
int start;
|
|
|
|
/*! Last parking space */
|
|
|
|
int stop;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*! Parking lot dialplan context space map */
|
|
|
|
AST_LIST_HEAD_NOLOCK(parking_dp_space_map, parking_dp_spaces);
|
|
|
|
|
|
|
|
/*! Parking lot context dialplan usage entry. */
|
|
|
|
struct parking_dp_context {
|
|
|
|
/*! Next node in the parking lot contexts dialplan list. */
|
|
|
|
AST_LIST_ENTRY(parking_dp_context) node;
|
|
|
|
/*! Parking access extensions defined in this context. */
|
|
|
|
struct parking_dp_ramp_map access_extens;
|
|
|
|
/*! Parking spaces defined in this context. */
|
|
|
|
struct parking_dp_space_map spaces;
|
|
|
|
/*! Parking hints defined in this context. */
|
|
|
|
struct parking_dp_space_map hints;
|
|
|
|
/*! Parking lot context name */
|
|
|
|
char context[1];
|
|
|
|
};
|
|
|
|
|
|
|
|
/*! Parking lot dialplan usage map. */
|
|
|
|
AST_LIST_HEAD_NOLOCK(parking_dp_map, parking_dp_context);
|
|
|
|
|
2011-05-20 17:04:53 +00:00
|
|
|
/*!
|
|
|
|
* \brief Description of one parked call, added to a list while active, then removed.
|
|
|
|
* The list belongs to a parkinglot.
|
|
|
|
*/
|
2008-04-21 23:42:45 +00:00
|
|
|
struct parkeduser {
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_channel *chan; /*!< Parked channel */
|
|
|
|
struct timeval start; /*!< Time the park started */
|
|
|
|
int parkingnum; /*!< Parking lot space used */
|
2008-04-21 23:42:45 +00:00
|
|
|
char parkingexten[AST_MAX_EXTENSION]; /*!< If set beforehand, parking extension used for this call */
|
|
|
|
char context[AST_MAX_CONTEXT]; /*!< Where to go if our parking time expires */
|
|
|
|
char exten[AST_MAX_EXTENSION];
|
|
|
|
int priority;
|
|
|
|
int parkingtime; /*!< Maximum length in parking lot before return */
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Method to entertain the caller when parked: AST_CONTROL_RINGING, AST_CONTROL_HOLD, or 0(none) */
|
|
|
|
enum ast_control_frame_type hold_method;
|
2009-07-08 17:26:26 +00:00
|
|
|
unsigned int notquiteyet:1;
|
|
|
|
unsigned int options_specified:1;
|
2011-10-18 21:15:45 +00:00
|
|
|
char peername[AST_CHANNEL_NAME];
|
2008-04-21 23:42:45 +00:00
|
|
|
unsigned char moh_trys;
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Parking lot this entry belongs to. Holds a parking lot reference. */
|
2008-04-21 23:42:45 +00:00
|
|
|
struct ast_parkinglot *parkinglot;
|
|
|
|
AST_LIST_ENTRY(parkeduser) list;
|
|
|
|
};
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Parking lot configuration options. */
|
|
|
|
struct parkinglot_cfg {
|
|
|
|
/*! Music class used for parking */
|
|
|
|
char mohclass[MAX_MUSICCLASS];
|
|
|
|
/*! Extension to park calls in this parking lot. */
|
|
|
|
char parkext[AST_MAX_EXTENSION];
|
|
|
|
/*! Context for which parking is made accessible */
|
2012-01-20 20:47:42 +00:00
|
|
|
char parking_con[AST_MAX_CONTEXT];
|
|
|
|
/*! Context that timed-out parked calls are called back on when comebacktoorigin=no */
|
|
|
|
char comebackcontext[AST_MAX_CONTEXT];
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! First available extension for parking */
|
|
|
|
int parking_start;
|
|
|
|
/*! Last available extension for parking */
|
|
|
|
int parking_stop;
|
|
|
|
/*! Default parking time in ms. */
|
|
|
|
int parkingtime;
|
|
|
|
/*!
|
|
|
|
* \brief Enable DTMF based transfers on bridge when picking up parked calls.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* none(0)
|
|
|
|
* AST_FEATURE_FLAG_BYCALLEE
|
|
|
|
* AST_FEATURE_FLAG_BYCALLER
|
|
|
|
* AST_FEATURE_FLAG_BYBOTH
|
|
|
|
*/
|
|
|
|
int parkedcalltransfers;
|
|
|
|
/*!
|
|
|
|
* \brief Enable DTMF based parking on bridge when picking up parked calls.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* none(0)
|
|
|
|
* AST_FEATURE_FLAG_BYCALLEE
|
|
|
|
* AST_FEATURE_FLAG_BYCALLER
|
|
|
|
* AST_FEATURE_FLAG_BYBOTH
|
|
|
|
*/
|
|
|
|
int parkedcallreparking;
|
|
|
|
/*!
|
|
|
|
* \brief Enable DTMF based hangup on a bridge when pickup up parked calls.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* none(0)
|
|
|
|
* AST_FEATURE_FLAG_BYCALLEE
|
|
|
|
* AST_FEATURE_FLAG_BYCALLER
|
|
|
|
* AST_FEATURE_FLAG_BYBOTH
|
|
|
|
*/
|
|
|
|
int parkedcallhangup;
|
|
|
|
/*!
|
|
|
|
* \brief Enable DTMF based recording on a bridge when picking up parked calls.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* none(0)
|
|
|
|
* AST_FEATURE_FLAG_BYCALLEE
|
|
|
|
* AST_FEATURE_FLAG_BYCALLER
|
|
|
|
* AST_FEATURE_FLAG_BYBOTH
|
|
|
|
*/
|
|
|
|
int parkedcallrecording;
|
|
|
|
|
2012-01-20 20:47:42 +00:00
|
|
|
/*! Time in seconds to dial the device that parked a timedout parked call */
|
|
|
|
unsigned int comebackdialtime;
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! TRUE if findslot is set to next */
|
|
|
|
unsigned int parkfindnext:1;
|
|
|
|
/*! TRUE if the parking lot is exclusively accessed by parkext */
|
|
|
|
unsigned int parkext_exclusive:1;
|
|
|
|
/*! Add parking hints automatically */
|
|
|
|
unsigned int parkaddhints:1;
|
|
|
|
/*! TRUE if configuration is invalid and the parking lot should not be used. */
|
|
|
|
unsigned int is_invalid:1;
|
2012-01-20 20:47:42 +00:00
|
|
|
/*! TRUE if a timed out parked call goes back to the parker */
|
|
|
|
unsigned int comebacktoorigin:1;
|
2011-08-16 17:23:08 +00:00
|
|
|
};
|
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/*! \brief Structure for parking lots which are put in a container. */
|
|
|
|
struct ast_parkinglot {
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Name of the parking lot. */
|
2008-04-21 23:42:45 +00:00
|
|
|
char name[AST_MAX_CONTEXT];
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Parking lot user configuration. */
|
|
|
|
struct parkinglot_cfg cfg;
|
|
|
|
|
|
|
|
/*! Parking space to start next park search. */
|
|
|
|
int next_parking_space;
|
|
|
|
|
|
|
|
/*! That which bears the_mark shall be deleted if parking lot empty! (Used during reloads.) */
|
|
|
|
unsigned int the_mark:1;
|
|
|
|
/*! TRUE if the parking lot is disabled. */
|
|
|
|
unsigned int disabled:1;
|
|
|
|
|
|
|
|
/*! List of active parkings in this parkinglot */
|
|
|
|
AST_LIST_HEAD(parkinglot_parklist, parkeduser) parkings;
|
2008-04-21 23:42:45 +00:00
|
|
|
};
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! \brief The configured parking lots container. Always at least one - the default parking lot */
|
2008-04-21 23:42:45 +00:00
|
|
|
static struct ao2_container *parkinglots;
|
2006-06-21 07:49:29 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \brief Default parking lot.
|
|
|
|
* \note Holds a parkinglot reference.
|
|
|
|
* \note Will not be NULL while running.
|
|
|
|
*/
|
|
|
|
static struct ast_parkinglot *default_parkinglot;
|
|
|
|
|
|
|
|
/*! Force a config reload to reload regardless of config file timestamp. */
|
|
|
|
static int force_reload_load;
|
|
|
|
|
|
|
|
static int parkedplay = 0; /*!< Who to play courtesytone to when someone picks up a parked call. */
|
2010-02-17 18:29:48 +00:00
|
|
|
static int parkeddynamic = 0; /*!< Enable creation of parkinglots dynamically */
|
2011-08-16 17:23:08 +00:00
|
|
|
static char courtesytone[256]; /*!< Courtesy tone used to pickup parked calls and on-touch-record */
|
2006-06-21 07:49:29 +00:00
|
|
|
static char xfersound[256]; /*!< Call transfer sound */
|
|
|
|
static char xferfailsound[256]; /*!< Call transfer failure sound */
|
2009-02-26 18:41:28 +00:00
|
|
|
static char pickupsound[256]; /*!< Pickup sound */
|
|
|
|
static char pickupfailsound[256]; /*!< Pickup failure sound */
|
2001-12-27 11:07:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \brief Context for parking dialback to parker.
|
|
|
|
* \note The need for the context is a KLUDGE.
|
|
|
|
*
|
|
|
|
* \todo Might be able to eliminate the parking_con_dial context
|
|
|
|
* kludge by running app_dial directly in its own thread to
|
|
|
|
* simulate a PBX.
|
|
|
|
*/
|
|
|
|
static char parking_con_dial[] = "park-dial";
|
|
|
|
|
|
|
|
/*! Ensure that features.conf reloads on one thread at a time. */
|
|
|
|
AST_MUTEX_DEFINE_STATIC(features_reload_lock);
|
|
|
|
|
2005-10-13 23:58:33 +00:00
|
|
|
static int adsipark;
|
2004-09-15 19:49:33 +00:00
|
|
|
|
2005-10-13 23:58:33 +00:00
|
|
|
static int transferdigittimeout;
|
|
|
|
static int featuredigittimeout;
|
2004-08-01 01:38:15 +00:00
|
|
|
|
2006-05-23 18:23:05 +00:00
|
|
|
static int atxfernoanswertimeout;
|
2007-05-01 22:24:51 +00:00
|
|
|
static unsigned int atxferdropcall;
|
|
|
|
static unsigned int atxferloopdelay;
|
|
|
|
static unsigned int atxfercallbackretries;
|
2006-05-23 18:23:05 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
static char *registrar = "features"; /*!< Registrar for operations */
|
2001-12-27 11:07:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! PARK_APP_NAME application arguments */
|
|
|
|
AST_DEFINE_APP_ARGS_TYPE(park_app_args,
|
|
|
|
AST_APP_ARG(timeout); /*!< Time in ms to remain in the parking lot. */
|
|
|
|
AST_APP_ARG(return_con); /*!< Context to return parked call if timeout. */
|
|
|
|
AST_APP_ARG(return_ext); /*!< Exten to return parked call if timeout. */
|
|
|
|
AST_APP_ARG(return_pri); /*!< Priority to return parked call if timeout. */
|
|
|
|
AST_APP_ARG(options); /*!< Parking option flags. */
|
|
|
|
AST_APP_ARG(pl_name); /*!< Parking lot name to use if present. */
|
|
|
|
AST_APP_ARG(dummy); /*!< Place to put any remaining args string. */
|
|
|
|
);
|
|
|
|
|
2006-01-09 09:07:58 +00:00
|
|
|
/* module and CLI command definitions */
|
2011-10-20 22:03:35 +00:00
|
|
|
static const char *parkcall = "Park";
|
2004-08-03 06:31:20 +00:00
|
|
|
|
2006-01-09 09:07:58 +00:00
|
|
|
static struct ast_app *monitor_app = NULL;
|
|
|
|
static int monitor_ok = 1;
|
2004-09-17 03:49:57 +00:00
|
|
|
|
2007-11-30 21:19:57 +00:00
|
|
|
static struct ast_app *mixmonitor_app = NULL;
|
|
|
|
static int mixmonitor_ok = 1;
|
|
|
|
|
|
|
|
static struct ast_app *stopmixmonitor_app = NULL;
|
|
|
|
static int stopmixmonitor_ok = 1;
|
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
static pthread_t parking_thread;
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
struct ast_dial_features {
|
2012-04-25 01:26:44 +00:00
|
|
|
/*! Channel's feature flags. */
|
|
|
|
struct ast_flags my_features;
|
|
|
|
/*! Bridge peer's feature flags. */
|
|
|
|
struct ast_flags peer_features;
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
};
|
2001-12-27 11:07:33 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
#if defined(ATXFER_NULL_TECH)
|
|
|
|
/*!
|
|
|
|
* \internal
|
2011-05-25 16:50:38 +00:00
|
|
|
* \brief Set the channel technology to the kill technology.
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
*
|
|
|
|
* \param chan Channel to change technology.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
2011-05-25 16:50:38 +00:00
|
|
|
static void set_kill_chan_tech(struct ast_channel *chan)
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
{
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
|
|
|
|
/* Hangup the channel's physical side */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_tech(chan)->hangup) {
|
|
|
|
ast_channel_tech(chan)->hangup(chan);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
}
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_tech_pvt(chan)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_log(LOG_WARNING, "Channel '%s' may not have been hung up properly\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(chan));
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_free(ast_channel_tech_pvt(chan));
|
|
|
|
ast_channel_tech_pvt_set(chan, NULL);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
}
|
|
|
|
|
2011-05-25 16:50:38 +00:00
|
|
|
/* Install the kill technology and wake up anyone waiting on it. */
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_tech_set(chan, &ast_kill_tech);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
for (idx = 0; idx < AST_MAX_FDS; ++idx) {
|
|
|
|
switch (idx) {
|
|
|
|
case AST_ALERT_FD:
|
|
|
|
case AST_TIMING_FD:
|
|
|
|
case AST_GENERATOR_FD:
|
|
|
|
/* Don't clear these fd's. */
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ast_channel_set_fd(chan, idx, -1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ast_queue_frame(chan, &ast_null_frame);
|
|
|
|
|
|
|
|
ast_channel_unlock(chan);
|
|
|
|
}
|
|
|
|
#endif /* defined(ATXFER_NULL_TECH) */
|
|
|
|
|
|
|
|
#if defined(ATXFER_NULL_TECH)
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Set the channel name to something unique.
|
|
|
|
*
|
|
|
|
* \param chan Channel to change name.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void set_new_chan_name(struct ast_channel *chan)
|
|
|
|
{
|
|
|
|
static int seq_num_last;
|
|
|
|
int seq_num;
|
|
|
|
int len;
|
|
|
|
char *chan_name;
|
|
|
|
char dummy[1];
|
|
|
|
|
|
|
|
/* Create the new channel name string. */
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
seq_num = ast_atomic_fetchadd_int(&seq_num_last, +1);
|
2012-01-09 22:15:50 +00:00
|
|
|
len = snprintf(dummy, sizeof(dummy), "%s<XFER_%x>", ast_channel_name(chan), seq_num) + 1;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
chan_name = alloca(len);
|
2012-01-09 22:15:50 +00:00
|
|
|
snprintf(chan_name, len, "%s<XFER_%x>", ast_channel_name(chan), seq_num);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_unlock(chan);
|
|
|
|
|
|
|
|
ast_change_name(chan, chan_name);
|
|
|
|
}
|
|
|
|
#endif /* defined(ATXFER_NULL_TECH) */
|
|
|
|
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
static void *dial_features_duplicate(void *data)
|
|
|
|
{
|
|
|
|
struct ast_dial_features *df = data, *df_copy;
|
2012-03-22 19:51:16 +00:00
|
|
|
|
|
|
|
if (!(df_copy = ast_calloc(1, sizeof(*df)))) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(df_copy, df, sizeof(*df));
|
|
|
|
|
|
|
|
return df_copy;
|
2009-06-15 17:34:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void dial_features_destroy(void *data)
|
|
|
|
{
|
2012-03-22 19:51:16 +00:00
|
|
|
struct ast_dial_features *df = data;
|
|
|
|
if (df) {
|
|
|
|
ast_free(df);
|
|
|
|
}
|
2009-06-15 17:34:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct ast_datastore_info dial_features_info = {
|
2012-03-22 19:51:16 +00:00
|
|
|
.type = "dial-features",
|
|
|
|
.destroy = dial_features_destroy,
|
|
|
|
.duplicate = dial_features_duplicate,
|
2011-06-09 16:47:07 +00:00
|
|
|
};
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2012-04-25 01:26:44 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Set the features datastore if it doesn't exist.
|
|
|
|
*
|
|
|
|
* \param chan Channel to add features datastore
|
|
|
|
* \param my_features The channel's feature flags
|
|
|
|
* \param peer_features The channel's bridge peer feature flags
|
|
|
|
*
|
|
|
|
* \retval TRUE if features datastore already existed.
|
|
|
|
*/
|
|
|
|
static int add_features_datastore(struct ast_channel *chan, const struct ast_flags *my_features, const struct ast_flags *peer_features)
|
|
|
|
{
|
|
|
|
struct ast_datastore *datastore;
|
|
|
|
struct ast_dial_features *dialfeatures;
|
|
|
|
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
datastore = ast_channel_datastore_find(chan, &dial_features_info, NULL);
|
|
|
|
ast_channel_unlock(chan);
|
|
|
|
if (datastore) {
|
|
|
|
/* Already exists. */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Create a new datastore with specified feature flags. */
|
|
|
|
datastore = ast_datastore_alloc(&dial_features_info, NULL);
|
|
|
|
if (!datastore) {
|
|
|
|
ast_log(LOG_WARNING, "Unable to create channel features datastore.\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
dialfeatures = ast_calloc(1, sizeof(*dialfeatures));
|
|
|
|
if (!dialfeatures) {
|
|
|
|
ast_log(LOG_WARNING, "Unable to allocate memory for feature flags.\n");
|
|
|
|
ast_datastore_free(datastore);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
ast_copy_flags(&dialfeatures->my_features, my_features, AST_FLAGS_ALL);
|
|
|
|
ast_copy_flags(&dialfeatures->peer_features, peer_features, AST_FLAGS_ALL);
|
|
|
|
datastore->inheritance = DATASTORE_INHERIT_FOREVER;
|
|
|
|
datastore->data = dialfeatures;
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
ast_channel_datastore_add(chan, datastore);
|
|
|
|
ast_channel_unlock(chan);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/* Forward declarations */
|
|
|
|
static struct ast_parkinglot *parkinglot_addref(struct ast_parkinglot *parkinglot);
|
|
|
|
static void parkinglot_unref(struct ast_parkinglot *parkinglot);
|
2011-08-16 17:23:08 +00:00
|
|
|
static struct ast_parkinglot *find_parkinglot(const char *name);
|
2010-02-17 18:29:48 +00:00
|
|
|
static struct ast_parkinglot *create_parkinglot(const char *name);
|
|
|
|
static struct ast_parkinglot *copy_parkinglot(const char *name, const struct ast_parkinglot *parkinglot);
|
2011-08-16 17:23:08 +00:00
|
|
|
static int parkinglot_activate(struct ast_parkinglot *parkinglot);
|
|
|
|
static int play_message_on_chan(struct ast_channel *play_to, struct ast_channel *other, const char *msg, const char *audiofile);
|
2001-12-27 11:07:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Get the parking extension if it exists.
|
|
|
|
*
|
|
|
|
* \param exten_str Parking extension to see if exists.
|
|
|
|
* \param chan Channel to autoservice while looking for exten. (Could be NULL)
|
|
|
|
* \param context Parking context to look in for exten.
|
|
|
|
*
|
|
|
|
* \retval exten on success.
|
|
|
|
* \retval NULL on error or exten does not exist.
|
|
|
|
*/
|
|
|
|
static struct ast_exten *get_parking_exten(const char *exten_str, struct ast_channel *chan, const char *context)
|
2010-09-15 19:23:56 +00:00
|
|
|
{
|
|
|
|
struct ast_exten *exten;
|
|
|
|
struct pbx_find_info q = { .stacklen = 0 }; /* the rest is reset in pbx_find_extension */
|
|
|
|
const char *app_at_exten;
|
|
|
|
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_debug(4, "Checking if %s@%s is a parking exten\n", exten_str, context);
|
2011-08-16 17:23:08 +00:00
|
|
|
exten = pbx_find_extension(chan, NULL, &q, context, exten_str, 1, NULL, NULL,
|
|
|
|
E_MATCH);
|
2010-09-15 19:23:56 +00:00
|
|
|
if (!exten) {
|
2011-08-16 17:23:08 +00:00
|
|
|
return NULL;
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
app_at_exten = ast_get_extension_app(exten);
|
2011-10-20 22:03:35 +00:00
|
|
|
if (!app_at_exten || strcasecmp(parkcall, app_at_exten)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
return NULL;
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
return exten;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ast_parking_ext_valid(const char *exten_str, struct ast_channel *chan, const char *context)
|
|
|
|
{
|
|
|
|
return get_parking_exten(exten_str, chan, context) ? 1 : 0;
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
|
|
|
|
2007-06-06 21:08:07 +00:00
|
|
|
const char *ast_pickup_ext(void)
|
2003-04-09 04:00:43 +00:00
|
|
|
{
|
|
|
|
return pickup_ext;
|
|
|
|
}
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
struct ast_bridge_thread_obj
|
2005-01-05 19:56:47 +00:00
|
|
|
{
|
|
|
|
struct ast_bridge_config bconfig;
|
|
|
|
struct ast_channel *chan;
|
|
|
|
struct ast_channel *peer;
|
2012-03-29 20:01:20 +00:00
|
|
|
struct ast_callid *callid; /*<! callid pointer (Only used to bind thread) */
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
unsigned int return_to_pbx:1;
|
2005-01-05 19:56:47 +00:00
|
|
|
};
|
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
static int parkinglot_hash_cb(const void *obj, const int flags)
|
|
|
|
{
|
|
|
|
const struct ast_parkinglot *parkinglot = obj;
|
2008-11-15 04:25:57 +00:00
|
|
|
|
|
|
|
return ast_str_case_hash(parkinglot->name);
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2007-03-30 14:37:21 +00:00
|
|
|
|
2008-11-25 01:01:49 +00:00
|
|
|
static int parkinglot_cmp_cb(void *obj, void *arg, int flags)
|
2008-04-21 23:42:45 +00:00
|
|
|
{
|
2011-08-09 23:17:13 +00:00
|
|
|
struct ast_parkinglot *parkinglot = obj;
|
|
|
|
struct ast_parkinglot *parkinglot2 = arg;
|
2008-11-15 04:25:57 +00:00
|
|
|
|
2008-08-29 17:47:17 +00:00
|
|
|
return !strcasecmp(parkinglot->name, parkinglot2->name) ? CMP_MATCH | CMP_STOP : 0;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2007-03-30 14:37:21 +00:00
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
2012-03-22 19:51:16 +00:00
|
|
|
* \brief store context, extension and priority
|
2007-08-07 23:04:01 +00:00
|
|
|
* \param chan, context, ext, pri
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2006-04-17 04:31:21 +00:00
|
|
|
static void set_c_e_p(struct ast_channel *chan, const char *context, const char *ext, int pri)
|
2006-04-16 18:49:46 +00:00
|
|
|
{
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_context_set(chan, context);
|
|
|
|
ast_channel_exten_set(chan, ext);
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_priority_set(chan, pri);
|
2006-04-16 18:49:46 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief Check goto on transfer
|
|
|
|
* \param chan
|
2007-09-05 16:31:39 +00:00
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Check if channel has 'GOTO_ON_BLINDXFR' set, if not exit.
|
|
|
|
* When found make sure the types are compatible. Check if channel is valid
|
2012-03-22 19:51:16 +00:00
|
|
|
* if so start the new channel else hangup the call.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2012-03-22 19:51:16 +00:00
|
|
|
static void check_goto_on_transfer(struct ast_channel *chan)
|
2005-04-22 02:55:14 +00:00
|
|
|
{
|
|
|
|
struct ast_channel *xferchan;
|
2011-10-13 23:08:48 +00:00
|
|
|
const char *val;
|
|
|
|
char *goto_on_transfer;
|
|
|
|
char *x;
|
2005-04-22 02:55:14 +00:00
|
|
|
|
2011-10-13 23:08:48 +00:00
|
|
|
ast_channel_lock(chan);
|
|
|
|
val = pbx_builtin_getvar_helper(chan, "GOTO_ON_BLINDXFR");
|
|
|
|
if (ast_strlen_zero(val)) {
|
|
|
|
ast_channel_unlock(chan);
|
2006-05-10 13:22:15 +00:00
|
|
|
return;
|
2011-10-13 23:08:48 +00:00
|
|
|
}
|
2006-05-10 13:22:15 +00:00
|
|
|
goto_on_transfer = ast_strdupa(val);
|
2011-10-13 23:08:48 +00:00
|
|
|
ast_channel_unlock(chan);
|
2006-05-10 13:22:15 +00:00
|
|
|
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(1, "Attempting GOTO_ON_BLINDXFR=%s for %s.\n", val, ast_channel_name(chan));
|
2006-05-10 13:22:15 +00:00
|
|
|
|
2012-01-24 20:12:09 +00:00
|
|
|
xferchan = ast_channel_alloc(0, AST_STATE_DOWN, 0, 0, "", "", "", ast_channel_linkedid(chan), 0,
|
2012-01-09 22:15:50 +00:00
|
|
|
"%s", ast_channel_name(chan));
|
2011-10-13 23:08:48 +00:00
|
|
|
if (!xferchan) {
|
|
|
|
return;
|
2006-05-10 13:22:15 +00:00
|
|
|
}
|
2011-10-13 23:08:48 +00:00
|
|
|
|
2006-05-10 13:22:15 +00:00
|
|
|
/* Make formats okay */
|
2012-02-24 00:32:20 +00:00
|
|
|
ast_format_copy(ast_channel_readformat(xferchan), ast_channel_readformat(chan));
|
|
|
|
ast_format_copy(ast_channel_writeformat(xferchan), ast_channel_writeformat(chan));
|
2011-10-13 23:08:48 +00:00
|
|
|
|
|
|
|
if (ast_channel_masquerade(xferchan, chan)) {
|
|
|
|
/* Failed to setup masquerade. */
|
|
|
|
ast_hangup(xferchan);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (x = goto_on_transfer; *x; ++x) {
|
|
|
|
if (*x == '^') {
|
|
|
|
*x = ',';
|
|
|
|
}
|
|
|
|
}
|
2006-05-10 13:22:15 +00:00
|
|
|
ast_parseable_goto(xferchan, goto_on_transfer);
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_state_set(xferchan, AST_STATE_UP);
|
2012-03-22 19:51:16 +00:00
|
|
|
ast_clear_flag(ast_channel_flags(xferchan), AST_FLAGS_ALL);
|
Merged revisions 303549 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r303549 | russell | 2011-01-24 14:51:37 -0600 (Mon, 24 Jan 2011) | 45 lines
Merged revisions 303548 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines
Merged revisions 303546 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
Fix channel redirect out of MeetMe() and other issues with channel softhangup.
Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
working properly. This issue includes a patch that resolves the issue by
removing a call to ast_check_hangup() from app_meetme.c. I left that in my
patch, as it doesn't need to be there. However, the rest of the patch fixes
this problem with or without the change to app_meetme.
The key difference between what happens before and after this patch is the
effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(),
ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme
sees this which causes it to exit as intended. Checking ast_check_hangup()
caused app_meetme to exit earlier in the process, and the target of the
redirect saw the condition where ast_read() returned NULL.
Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
solve the issue if another application did the same thing. There are also
other edge cases where if an application finishes at the same time that a
redirect happens, the target of the redirect will think that the channel hung
up. So, I made some changes in pbx.c to resolve it at a deeper level. There
are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
abort the hangup process. My patch extends this to remove the END_OF_Q frame
from the channel's read queue, making the "abort hangup" more complete. This
same technique was used in every place where a softhangup flag was cleared.
(closes issue #18585)
Reported by: oej
Tested by: oej, wedhorn, russell
Review: https://reviewboard.asterisk.org/r/1082/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-24 20:57:28 +00:00
|
|
|
ast_channel_clear_softhangup(xferchan, AST_SOFTHANGUP_ALL);
|
2011-10-13 23:08:48 +00:00
|
|
|
|
|
|
|
if (ast_do_masquerade(xferchan) || ast_pbx_start(xferchan)) {
|
|
|
|
/* Failed to do masquerade or could not start PBX. */
|
2006-05-10 13:22:15 +00:00
|
|
|
ast_hangup(xferchan);
|
2005-04-22 02:55:14 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
static struct ast_channel *feature_request_and_dial(struct ast_channel *caller,
|
|
|
|
const char *caller_name, struct ast_channel *requestor,
|
2012-02-01 19:53:38 +00:00
|
|
|
struct ast_channel *transferee, const char *type, struct ast_format_cap *cap, const char *addr,
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
int timeout, int *outstate, const char *language);
|
2005-06-23 22:12:01 +00:00
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
2012-03-22 19:51:16 +00:00
|
|
|
* \brief bridge the call
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param data thread bridge.
|
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Set Last Data for respective channels, reset cdr for channels
|
|
|
|
* bridge call, check if we're going back to dialplan
|
|
|
|
* if not hangup both legs of the call
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2009-03-13 17:49:01 +00:00
|
|
|
static void *bridge_call_thread(void *data)
|
2005-01-05 19:56:47 +00:00
|
|
|
{
|
|
|
|
struct ast_bridge_thread_obj *tobj = data;
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
int res;
|
2005-11-06 21:00:35 +00:00
|
|
|
|
2012-03-29 20:01:20 +00:00
|
|
|
if (tobj->callid) {
|
|
|
|
ast_callid_threadassoc_add(tobj->callid);
|
|
|
|
/* Need to deref and set to null since ast_bridge_thread_obj has no common destructor */
|
|
|
|
tobj->callid = ast_callid_unref(tobj->callid);
|
|
|
|
}
|
|
|
|
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_appl_set(tobj->chan, !tobj->return_to_pbx ? "Transferred Call" : "ManagerBridge");
|
|
|
|
ast_channel_data_set(tobj->chan, ast_channel_name(tobj->peer));
|
|
|
|
ast_channel_appl_set(tobj->peer, !tobj->return_to_pbx ? "Transferred Call" : "ManagerBridge");
|
|
|
|
ast_channel_data_set(tobj->peer, ast_channel_name(tobj->chan));
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2005-01-05 19:56:47 +00:00
|
|
|
ast_bridge_call(tobj->peer, tobj->chan, &tobj->bconfig);
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
|
|
|
if (tobj->return_to_pbx) {
|
|
|
|
if (!ast_check_hangup(tobj->peer)) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_VERBOSE, "putting peer %s into PBX again\n", ast_channel_name(tobj->peer));
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
res = ast_pbx_start(tobj->peer);
|
2012-04-25 00:03:52 +00:00
|
|
|
if (res != AST_PBX_SUCCESS) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "FAILED continuing PBX on peer %s\n", ast_channel_name(tobj->peer));
|
2012-04-25 00:03:52 +00:00
|
|
|
ast_hangup(tobj->peer);
|
|
|
|
}
|
|
|
|
} else {
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_hangup(tobj->peer);
|
2012-04-25 00:03:52 +00:00
|
|
|
}
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
if (!ast_check_hangup(tobj->chan)) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_VERBOSE, "putting chan %s into PBX again\n", ast_channel_name(tobj->chan));
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
res = ast_pbx_start(tobj->chan);
|
2012-04-25 00:03:52 +00:00
|
|
|
if (res != AST_PBX_SUCCESS) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "FAILED continuing PBX on chan %s\n", ast_channel_name(tobj->chan));
|
2012-04-25 00:03:52 +00:00
|
|
|
ast_hangup(tobj->chan);
|
|
|
|
}
|
|
|
|
} else {
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_hangup(tobj->chan);
|
2012-04-25 00:03:52 +00:00
|
|
|
}
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
} else {
|
|
|
|
ast_hangup(tobj->chan);
|
|
|
|
ast_hangup(tobj->peer);
|
|
|
|
}
|
|
|
|
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(tobj);
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2005-01-05 19:56:47 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief create thread for the parked call
|
|
|
|
* \param data
|
2007-09-05 16:31:39 +00:00
|
|
|
*
|
2009-03-13 17:49:01 +00:00
|
|
|
* Create thread and attributes, call bridge_call_thread
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2012-03-29 20:01:20 +00:00
|
|
|
static void bridge_call_thread_launch(struct ast_bridge_thread_obj *data)
|
2005-01-05 19:56:47 +00:00
|
|
|
{
|
|
|
|
pthread_t thread;
|
|
|
|
pthread_attr_t attr;
|
2005-11-09 00:16:08 +00:00
|
|
|
struct sched_param sched;
|
2005-01-05 19:56:47 +00:00
|
|
|
|
2012-03-29 20:01:20 +00:00
|
|
|
/* This needs to be unreffed once it has been associated with the new thread. */
|
|
|
|
data->callid = ast_read_threadstorage_callid();
|
|
|
|
|
2005-11-09 00:16:08 +00:00
|
|
|
pthread_attr_init(&attr);
|
2005-01-05 19:56:47 +00:00
|
|
|
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
|
2012-03-29 20:01:20 +00:00
|
|
|
if (ast_pthread_create(&thread, &attr, bridge_call_thread, data)) {
|
|
|
|
/* Failed to create thread. Ditch the reference to callid. */
|
|
|
|
ast_callid_unref(data->callid);
|
|
|
|
ast_log(LOG_ERROR, "Failed to create bridge_call_thread.\n");
|
|
|
|
return;
|
|
|
|
}
|
2005-11-09 00:16:08 +00:00
|
|
|
pthread_attr_destroy(&attr);
|
|
|
|
memset(&sched, 0, sizeof(sched));
|
|
|
|
pthread_setschedparam(thread, SCHED_RR, &sched);
|
2005-01-05 19:56:47 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief Announce call parking by ADSI
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param chan .
|
|
|
|
* \param parkingexten .
|
2007-08-07 23:04:01 +00:00
|
|
|
* Create message to show for ADSI, display message.
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on failure.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
static int adsi_announce_park(struct ast_channel *chan, char *parkingexten)
|
2004-09-15 19:49:33 +00:00
|
|
|
{
|
|
|
|
int res;
|
|
|
|
int justify[5] = {ADSI_JUST_CENT, ADSI_JUST_CENT, ADSI_JUST_CENT, ADSI_JUST_CENT};
|
2005-09-07 21:01:31 +00:00
|
|
|
char tmp[256];
|
2005-09-07 18:55:03 +00:00
|
|
|
char *message[5] = {NULL, NULL, NULL, NULL, NULL};
|
2004-09-15 19:49:33 +00:00
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
snprintf(tmp, sizeof(tmp), "Parked on %s", parkingexten);
|
2005-09-07 18:55:03 +00:00
|
|
|
message[0] = tmp;
|
2006-09-20 04:34:51 +00:00
|
|
|
res = ast_adsi_load_session(chan, NULL, 0, 1);
|
2006-04-14 23:20:29 +00:00
|
|
|
if (res == -1)
|
2004-09-15 19:49:33 +00:00
|
|
|
return res;
|
2006-09-20 04:34:51 +00:00
|
|
|
return ast_adsi_print(chan, message, justify, 1);
|
2004-09-15 19:49:33 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \brief Find parking lot name from channel
|
|
|
|
* \note Channel needs to be locked while the returned string is in use.
|
|
|
|
*/
|
2008-04-21 23:42:45 +00:00
|
|
|
static const char *findparkinglotname(struct ast_channel *chan)
|
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
const char *name;
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* The channel variable overrides everything */
|
|
|
|
name = pbx_builtin_getvar_helper(chan, "PARKINGLOT");
|
2012-01-24 20:12:09 +00:00
|
|
|
if (!name && !ast_strlen_zero(ast_channel_parkinglot(chan))) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Use the channel's parking lot. */
|
2012-01-24 20:12:09 +00:00
|
|
|
name = ast_channel_parkinglot(chan);
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
return name;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
/*! \brief Notify metermaids that we've changed an extension */
|
2007-08-10 16:24:11 +00:00
|
|
|
static void notify_metermaids(const char *exten, char *context, enum ast_device_state state)
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
{
|
2011-02-04 16:55:39 +00:00
|
|
|
ast_debug(4, "Notification of state change to metermaids %s@%s\n to state '%s'",
|
2008-11-04 18:47:20 +00:00
|
|
|
exten, context, ast_devstate2str(state));
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
|
2007-08-10 16:24:11 +00:00
|
|
|
ast_devstate_changed(state, "park:%s@%s", exten, context);
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief metermaids callback from devicestate.c */
|
2007-02-13 22:02:20 +00:00
|
|
|
static enum ast_device_state metermaidstate(const char *data)
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
{
|
2007-07-08 13:22:30 +00:00
|
|
|
char *context;
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
char *exten;
|
|
|
|
|
2007-07-08 13:22:30 +00:00
|
|
|
context = ast_strdupa(data);
|
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
exten = strsep(&context, "@");
|
|
|
|
if (!context)
|
2007-07-08 13:22:30 +00:00
|
|
|
return AST_DEVICE_INVALID;
|
2011-02-04 16:55:39 +00:00
|
|
|
|
2007-06-14 19:39:12 +00:00
|
|
|
ast_debug(4, "Checking state of exten %s in context %s\n", exten, context);
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
|
2007-07-08 13:22:30 +00:00
|
|
|
if (!ast_exists_extension(NULL, context, exten, 1, NULL))
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
return AST_DEVICE_NOT_INUSE;
|
2007-07-08 13:22:30 +00:00
|
|
|
|
|
|
|
return AST_DEVICE_INUSE;
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
}
|
|
|
|
|
2009-03-13 17:49:01 +00:00
|
|
|
/*! Options to pass to park_call_full */
|
2008-04-25 18:18:27 +00:00
|
|
|
enum ast_park_call_options {
|
|
|
|
/*! Provide ringing to the parked caller instead of music on hold */
|
|
|
|
AST_PARK_OPT_RINGING = (1 << 0),
|
|
|
|
/*! Randomly choose a parking spot for the caller instead of choosing
|
|
|
|
* the first one that is available. */
|
|
|
|
AST_PARK_OPT_RANDOMIZE = (1 << 1),
|
2008-08-29 17:53:32 +00:00
|
|
|
/*! Do not announce the parking number */
|
|
|
|
AST_PARK_OPT_SILENCE = (1 << 2),
|
2008-04-25 18:18:27 +00:00
|
|
|
};
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Optional additional parking options when parking a call. */
|
2008-04-25 18:18:27 +00:00
|
|
|
struct ast_park_call_args {
|
|
|
|
/*! How long to wait in the parking lot before the call gets sent back
|
|
|
|
* to the specified return extension (or a best guess at where it came
|
|
|
|
* from if not explicitly specified). */
|
|
|
|
int timeout;
|
|
|
|
/*! An output parameter to store the parking space where the parked caller
|
|
|
|
* was placed. */
|
|
|
|
int *extout;
|
|
|
|
const char *orig_chan_name;
|
|
|
|
const char *return_con;
|
|
|
|
const char *return_ext;
|
|
|
|
int return_pri;
|
|
|
|
uint32_t flags;
|
2009-02-04 21:17:53 +00:00
|
|
|
/*! Parked user that has already obtained a parking space */
|
|
|
|
struct parkeduser *pu;
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! \brief Parkinglot to be parked in */
|
|
|
|
struct ast_parkinglot *parkinglot;
|
2008-04-25 18:18:27 +00:00
|
|
|
};
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Create a dynamic parking lot.
|
|
|
|
*
|
|
|
|
* \param name Dynamic parking lot name to create.
|
|
|
|
* \param chan Channel to get dynamic parking lot parameters.
|
|
|
|
*
|
|
|
|
* \retval parkinglot on success.
|
|
|
|
* \retval NULL on error.
|
|
|
|
*/
|
|
|
|
static struct ast_parkinglot *create_dynamic_parkinglot(const char *name, struct ast_channel *chan)
|
|
|
|
{
|
|
|
|
const char *dyn_context;
|
|
|
|
const char *dyn_exten;
|
|
|
|
const char *dyn_range;
|
|
|
|
const char *template_name;
|
|
|
|
struct ast_parkinglot *template_parkinglot = NULL;
|
|
|
|
struct ast_parkinglot *parkinglot;
|
|
|
|
int dyn_start;
|
|
|
|
int dyn_end;
|
|
|
|
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
template_name = ast_strdupa(S_OR(pbx_builtin_getvar_helper(chan, "PARKINGDYNAMIC"), ""));
|
|
|
|
dyn_context = ast_strdupa(S_OR(pbx_builtin_getvar_helper(chan, "PARKINGDYNCONTEXT"), ""));
|
|
|
|
dyn_exten = ast_strdupa(S_OR(pbx_builtin_getvar_helper(chan, "PARKINGDYNEXTEN"), ""));
|
|
|
|
dyn_range = ast_strdupa(S_OR(pbx_builtin_getvar_helper(chan, "PARKINGDYNPOS"), ""));
|
|
|
|
ast_channel_unlock(chan);
|
|
|
|
|
|
|
|
if (!ast_strlen_zero(template_name)) {
|
|
|
|
template_parkinglot = find_parkinglot(template_name);
|
|
|
|
if (!template_parkinglot) {
|
|
|
|
ast_debug(1, "PARKINGDYNAMIC lot %s does not exist.\n",
|
|
|
|
template_name);
|
|
|
|
} else if (template_parkinglot->cfg.is_invalid) {
|
|
|
|
ast_debug(1, "PARKINGDYNAMIC lot %s has invalid config.\n",
|
|
|
|
template_name);
|
|
|
|
parkinglot_unref(template_parkinglot);
|
|
|
|
template_parkinglot = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!template_parkinglot) {
|
|
|
|
template_parkinglot = parkinglot_addref(default_parkinglot);
|
|
|
|
ast_debug(1, "Using default parking lot for template\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
parkinglot = copy_parkinglot(name, template_parkinglot);
|
|
|
|
if (!parkinglot) {
|
|
|
|
ast_log(LOG_ERROR, "Could not build dynamic parking lot!\n");
|
|
|
|
} else {
|
|
|
|
/* Configure the dynamic parking lot. */
|
|
|
|
if (!ast_strlen_zero(dyn_context)) {
|
|
|
|
ast_copy_string(parkinglot->cfg.parking_con, dyn_context,
|
|
|
|
sizeof(parkinglot->cfg.parking_con));
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(dyn_exten)) {
|
|
|
|
ast_copy_string(parkinglot->cfg.parkext, dyn_exten,
|
|
|
|
sizeof(parkinglot->cfg.parkext));
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(dyn_range)) {
|
|
|
|
if (sscanf(dyn_range, "%30d-%30d", &dyn_start, &dyn_end) != 2) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Format for parking positions is a-b, where a and b are numbers\n");
|
|
|
|
} else if (dyn_end < dyn_start || dyn_start <= 0 || dyn_end <= 0) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Format for parking positions is a-b, where a <= b\n");
|
|
|
|
} else {
|
|
|
|
parkinglot->cfg.parking_start = dyn_start;
|
|
|
|
parkinglot->cfg.parking_stop = dyn_end;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sanity check for dynamic parking lot configuration.
|
|
|
|
*
|
|
|
|
* XXX It may be desirable to instead check if the dynamic
|
|
|
|
* parking lot overlaps any existing lots like what is done for
|
|
|
|
* a reload.
|
|
|
|
*/
|
|
|
|
if (!strcmp(parkinglot->cfg.parking_con, template_parkinglot->cfg.parking_con)) {
|
|
|
|
if (!strcmp(parkinglot->cfg.parkext, template_parkinglot->cfg.parkext)
|
|
|
|
&& parkinglot->cfg.parkext_exclusive) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Parking lot '%s' conflicts with template parking lot '%s'!\n"
|
|
|
|
"Change either PARKINGDYNCONTEXT or PARKINGDYNEXTEN.\n",
|
|
|
|
parkinglot->name, template_parkinglot->name);
|
|
|
|
}
|
|
|
|
if ((template_parkinglot->cfg.parking_start <= parkinglot->cfg.parking_start
|
|
|
|
&& parkinglot->cfg.parking_start <= template_parkinglot->cfg.parking_stop)
|
|
|
|
|| (template_parkinglot->cfg.parking_start <= parkinglot->cfg.parking_stop
|
|
|
|
&& parkinglot->cfg.parking_stop <= template_parkinglot->cfg.parking_stop)
|
|
|
|
|| (parkinglot->cfg.parking_start < template_parkinglot->cfg.parking_start
|
|
|
|
&& template_parkinglot->cfg.parking_stop < parkinglot->cfg.parking_stop)) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Parking lot '%s' parking spaces overlap template parking lot '%s'!\n"
|
|
|
|
"Change PARKINGDYNPOS.\n",
|
|
|
|
parkinglot->name, template_parkinglot->name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
parkinglot_activate(parkinglot);
|
|
|
|
ao2_link(parkinglots, parkinglot);
|
|
|
|
}
|
|
|
|
parkinglot_unref(template_parkinglot);
|
|
|
|
|
|
|
|
return parkinglot;
|
|
|
|
}
|
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Abort parking a call that has not completed parking yet.
|
|
|
|
*
|
|
|
|
* \param pu Parked user item to clean up.
|
|
|
|
*
|
|
|
|
* \note The parking lot parkings list is locked on entry.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void park_space_abort(struct parkeduser *pu)
|
|
|
|
{
|
|
|
|
struct ast_parkinglot *parkinglot;
|
|
|
|
|
|
|
|
parkinglot = pu->parkinglot;
|
|
|
|
|
|
|
|
/* Put back the parking space just allocated. */
|
|
|
|
--parkinglot->next_parking_space;
|
|
|
|
|
|
|
|
AST_LIST_REMOVE(&parkinglot->parkings, pu, list);
|
|
|
|
|
|
|
|
AST_LIST_UNLOCK(&parkinglot->parkings);
|
|
|
|
parkinglot_unref(parkinglot);
|
|
|
|
ast_free(pu);
|
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Reserve a parking space in a parking lot for a call being parked.
|
|
|
|
*
|
|
|
|
* \param park_me Channel being parked.
|
|
|
|
* \param parker Channel parking the call.
|
|
|
|
* \param args Optional additional parking options when parking a call.
|
|
|
|
*
|
|
|
|
* \return Parked call descriptor or NULL if failed.
|
|
|
|
* \note The parking lot list is locked if successful.
|
|
|
|
*/
|
|
|
|
static struct parkeduser *park_space_reserve(struct ast_channel *park_me, struct ast_channel *parker, struct ast_park_call_args *args)
|
2001-12-27 11:07:33 +00:00
|
|
|
{
|
2008-04-25 18:18:27 +00:00
|
|
|
struct parkeduser *pu;
|
2011-08-16 17:23:08 +00:00
|
|
|
int i;
|
|
|
|
int parking_space = -1;
|
|
|
|
const char *parkinglotname;
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
const char *parkingexten;
|
2011-08-16 17:23:08 +00:00
|
|
|
struct parkeduser *cur;
|
2010-09-15 21:00:03 +00:00
|
|
|
struct ast_parkinglot *parkinglot = NULL;
|
2010-02-17 18:29:48 +00:00
|
|
|
|
2010-09-15 19:23:56 +00:00
|
|
|
if (args->parkinglot) {
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot = parkinglot_addref(args->parkinglot);
|
2010-09-15 19:23:56 +00:00
|
|
|
parkinglotname = parkinglot->name;
|
2011-08-16 17:23:08 +00:00
|
|
|
} else {
|
|
|
|
if (parker) {
|
|
|
|
parkinglotname = findparkinglotname(parker);
|
|
|
|
} else { /* parker was NULL, check park_me (ParkAndAnnounce / res_agi) */
|
|
|
|
parkinglotname = findparkinglotname(park_me);
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(parkinglotname)) {
|
2010-09-15 19:23:56 +00:00
|
|
|
parkinglot = find_parkinglot(parkinglotname);
|
|
|
|
} else {
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Parking lot is not specified, so use the default parking lot. */
|
2010-09-15 19:23:56 +00:00
|
|
|
ast_debug(4, "This could be an indication channel driver needs updating, using default lot.\n");
|
|
|
|
parkinglot = parkinglot_addref(default_parkinglot);
|
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2010-02-17 18:29:48 +00:00
|
|
|
|
|
|
|
/* Dynamically create parkinglot */
|
|
|
|
if (!parkinglot && parkeddynamic && !ast_strlen_zero(parkinglotname)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot = create_dynamic_parkinglot(parkinglotname, park_me);
|
2010-02-17 18:29:48 +00:00
|
|
|
}
|
|
|
|
|
2009-12-21 17:00:46 +00:00
|
|
|
if (!parkinglot) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Parking lot not available to park %s.\n", ast_channel_name(park_me));
|
2011-08-16 17:23:08 +00:00
|
|
|
return NULL;
|
2009-12-21 17:00:46 +00:00
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(1, "Parking lot: %s\n", parkinglot->name);
|
|
|
|
if (parkinglot->disabled || parkinglot->cfg.is_invalid) {
|
|
|
|
ast_log(LOG_WARNING, "Parking lot %s is not in a useable state.\n",
|
|
|
|
parkinglot->name);
|
|
|
|
parkinglot_unref(parkinglot);
|
|
|
|
return NULL;
|
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
/* Allocate memory for parking data */
|
2008-04-21 23:42:45 +00:00
|
|
|
if (!(pu = ast_calloc(1, sizeof(*pu)))) {
|
2008-05-14 16:52:30 +00:00
|
|
|
parkinglot_unref(parkinglot);
|
2009-02-04 21:17:53 +00:00
|
|
|
return NULL;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2006-06-21 07:49:29 +00:00
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/* Lock parking list */
|
2008-05-14 16:52:30 +00:00
|
|
|
AST_LIST_LOCK(&parkinglot->parkings);
|
2011-08-16 17:23:08 +00:00
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
/* Check for channel variable PARKINGEXTEN */
|
2011-08-16 17:23:08 +00:00
|
|
|
parkingexten = ast_strdupa(S_OR(pbx_builtin_getvar_helper(park_me, "PARKINGEXTEN"), ""));
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
if (!ast_strlen_zero(parkingexten)) {
|
2011-05-20 17:04:53 +00:00
|
|
|
/*!
|
|
|
|
* \note The API forces us to specify a numeric parking slot, even
|
2008-06-12 23:08:37 +00:00
|
|
|
* though the architecture would tend to support non-numeric extensions
|
|
|
|
* (as are possible with SIP, for example). Hence, we enforce that
|
|
|
|
* limitation here. If extout was not numeric, we could permit
|
|
|
|
* arbitrary non-numeric extensions.
|
|
|
|
*/
|
2011-08-16 17:23:08 +00:00
|
|
|
if (sscanf(parkingexten, "%30d", &parking_space) != 1 || parking_space <= 0) {
|
|
|
|
ast_log(LOG_WARNING, "PARKINGEXTEN='%s' is not a valid parking space.\n",
|
|
|
|
parkingexten);
|
2008-06-12 23:08:37 +00:00
|
|
|
AST_LIST_UNLOCK(&parkinglot->parkings);
|
|
|
|
parkinglot_unref(parkinglot);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_free(pu);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (parking_space < parkinglot->cfg.parking_start
|
|
|
|
|| parkinglot->cfg.parking_stop < parking_space) {
|
|
|
|
/*
|
|
|
|
* Cannot allow park because parking lots are not setup for
|
|
|
|
* spaces outside of the lot. (Things like dialplan hints don't
|
|
|
|
* exist for outside lot space.)
|
|
|
|
*/
|
|
|
|
ast_log(LOG_WARNING, "PARKINGEXTEN=%d is not in %s (%d-%d).\n",
|
|
|
|
parking_space, parkinglot->name, parkinglot->cfg.parking_start,
|
|
|
|
parkinglot->cfg.parking_stop);
|
2008-05-14 16:52:30 +00:00
|
|
|
AST_LIST_UNLOCK(&parkinglot->parkings);
|
|
|
|
parkinglot_unref(parkinglot);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(pu);
|
2009-02-04 21:17:53 +00:00
|
|
|
return NULL;
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
/* Check if requested parking space is in use. */
|
|
|
|
AST_LIST_TRAVERSE(&parkinglot->parkings, cur, list) {
|
|
|
|
if (cur->parkingnum == parking_space) {
|
|
|
|
ast_log(LOG_WARNING, "PARKINGEXTEN=%d is already in use in %s\n",
|
|
|
|
parking_space, parkinglot->name);
|
|
|
|
AST_LIST_UNLOCK(&parkinglot->parkings);
|
|
|
|
parkinglot_unref(parkinglot);
|
|
|
|
ast_free(pu);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* PARKINGEXTEN is empty, so find a usable extension in the lot to park the call */
|
2011-05-19 18:36:38 +00:00
|
|
|
int start; /* The first slot we look in the parkinglot. It can be randomized. */
|
|
|
|
int start_checked = 0; /* flag raised once the first slot is checked */
|
2008-04-25 18:18:27 +00:00
|
|
|
|
2011-05-19 18:36:38 +00:00
|
|
|
/* If using randomize mode, set start to random position on parking range */
|
2008-04-25 18:18:27 +00:00
|
|
|
if (ast_test_flag(args, AST_PARK_OPT_RANDOMIZE)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
start = ast_random() % (parkinglot->cfg.parking_stop - parkinglot->cfg.parking_start + 1);
|
|
|
|
start += parkinglot->cfg.parking_start;
|
|
|
|
} else if (parkinglot->cfg.parkfindnext
|
|
|
|
&& parkinglot->cfg.parking_start <= parkinglot->next_parking_space
|
|
|
|
&& parkinglot->next_parking_space <= parkinglot->cfg.parking_stop) {
|
|
|
|
/* Start looking with the next parking space in the lot. */
|
|
|
|
start = parkinglot->next_parking_space;
|
|
|
|
} else {
|
|
|
|
/* Otherwise, just set it to the start position. */
|
|
|
|
start = parkinglot->cfg.parking_start;
|
2008-04-25 18:18:27 +00:00
|
|
|
}
|
|
|
|
|
2011-05-19 18:36:38 +00:00
|
|
|
/* free parking extension linear search: O(n^2) */
|
2011-08-16 17:23:08 +00:00
|
|
|
for (i = start; ; i++) {
|
2011-05-19 18:36:38 +00:00
|
|
|
/* If we are past the end, wrap around to the first parking slot*/
|
2011-08-16 17:23:08 +00:00
|
|
|
if (i == parkinglot->cfg.parking_stop + 1) {
|
|
|
|
i = parkinglot->cfg.parking_start;
|
2011-05-19 18:36:38 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (i == start) {
|
|
|
|
/* At this point, if start_checked, we've exhausted all the possible slots. */
|
2011-05-19 18:36:38 +00:00
|
|
|
if (start_checked) {
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
start_checked = 1;
|
|
|
|
}
|
2008-04-25 18:18:27 +00:00
|
|
|
}
|
|
|
|
|
2011-05-19 18:36:38 +00:00
|
|
|
/* Search the list of parked calls already in use for i. If we find it, it's in use. */
|
2008-05-14 16:52:30 +00:00
|
|
|
AST_LIST_TRAVERSE(&parkinglot->parkings, cur, list) {
|
2008-04-25 18:18:27 +00:00
|
|
|
if (cur->parkingnum == i) {
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
break;
|
2008-04-25 18:18:27 +00:00
|
|
|
}
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
}
|
2010-01-08 17:18:41 +00:00
|
|
|
if (!cur) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/* We found a parking space. */
|
2009-02-04 21:17:53 +00:00
|
|
|
parking_space = i;
|
2001-12-27 11:07:33 +00:00
|
|
|
break;
|
2008-04-25 18:18:27 +00:00
|
|
|
}
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (parking_space == -1) {
|
|
|
|
/* We did not find a parking space. Lot is full. */
|
|
|
|
ast_log(LOG_WARNING, "No more parking spaces in %s\n", parkinglot->name);
|
2008-05-14 16:52:30 +00:00
|
|
|
AST_LIST_UNLOCK(&parkinglot->parkings);
|
|
|
|
parkinglot_unref(parkinglot);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_free(pu);
|
2009-02-04 21:17:53 +00:00
|
|
|
return NULL;
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
}
|
2005-07-25 17:31:53 +00:00
|
|
|
}
|
2009-02-04 21:17:53 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Prepare for next parking space search. */
|
|
|
|
parkinglot->next_parking_space = parking_space + 1;
|
|
|
|
|
|
|
|
snprintf(pu->parkingexten, sizeof(pu->parkingexten), "%d", parking_space);
|
2009-02-04 21:17:53 +00:00
|
|
|
pu->notquiteyet = 1;
|
|
|
|
pu->parkingnum = parking_space;
|
2010-09-15 19:23:56 +00:00
|
|
|
pu->parkinglot = parkinglot;
|
2009-02-04 21:17:53 +00:00
|
|
|
AST_LIST_INSERT_TAIL(&parkinglot->parkings, pu, list);
|
|
|
|
|
|
|
|
return pu;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Park a call */
|
2009-03-13 17:49:01 +00:00
|
|
|
static int park_call_full(struct ast_channel *chan, struct ast_channel *peer, struct ast_park_call_args *args)
|
2009-02-04 21:17:53 +00:00
|
|
|
{
|
|
|
|
struct parkeduser *pu = args->pu;
|
2012-02-23 20:14:54 +00:00
|
|
|
const char *event_from; /*!< Channel name that is parking the call. */
|
2011-08-16 17:23:08 +00:00
|
|
|
char app_data[AST_MAX_EXTENSION + AST_MAX_CONTEXT];
|
2009-02-04 21:17:53 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (pu == NULL) {
|
2010-03-10 20:51:23 +00:00
|
|
|
args->pu = pu = park_space_reserve(chan, peer, args);
|
2011-08-16 17:23:08 +00:00
|
|
|
if (pu == NULL) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
2010-03-10 20:51:23 +00:00
|
|
|
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_appl_set(chan, "Parked Call");
|
|
|
|
ast_channel_data_set(chan, NULL);
|
2005-07-25 17:31:53 +00:00
|
|
|
|
|
|
|
pu->chan = chan;
|
2010-03-10 20:51:23 +00:00
|
|
|
|
2006-07-19 20:44:39 +00:00
|
|
|
/* Put the parked channel on hold if we have two different channels */
|
2005-07-25 17:31:53 +00:00
|
|
|
if (chan != peer) {
|
2008-04-25 18:18:27 +00:00
|
|
|
if (ast_test_flag(args, AST_PARK_OPT_RINGING)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
pu->hold_method = AST_CONTROL_RINGING;
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_indicate(chan, AST_CONTROL_RINGING);
|
2008-04-25 18:18:27 +00:00
|
|
|
} else {
|
2011-08-16 17:23:08 +00:00
|
|
|
pu->hold_method = AST_CONTROL_HOLD;
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_indicate_data(chan, AST_CONTROL_HOLD,
|
2011-08-16 17:23:08 +00:00
|
|
|
S_OR(pu->parkinglot->cfg.mohclass, NULL),
|
|
|
|
!ast_strlen_zero(pu->parkinglot->cfg.mohclass) ? strlen(pu->parkinglot->cfg.mohclass) + 1 : 0);
|
2008-04-25 18:18:27 +00:00
|
|
|
}
|
2005-07-25 17:31:53 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2005-07-25 17:31:53 +00:00
|
|
|
pu->start = ast_tvnow();
|
2011-08-16 17:23:08 +00:00
|
|
|
pu->parkingtime = (args->timeout > 0) ? args->timeout : pu->parkinglot->cfg.parkingtime;
|
2008-04-25 18:18:27 +00:00
|
|
|
if (args->extout)
|
2009-02-04 21:17:53 +00:00
|
|
|
*(args->extout) = pu->parkingnum;
|
2007-12-26 17:26:04 +00:00
|
|
|
|
2012-02-23 20:14:54 +00:00
|
|
|
if (peer) {
|
|
|
|
event_from = S_OR(args->orig_chan_name, ast_channel_name(peer));
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*
|
|
|
|
* This is so ugly that it hurts, but implementing
|
|
|
|
* get_base_channel() on local channels could have ugly side
|
|
|
|
* effects. We could have
|
|
|
|
* transferer<->local,1<->local,2<->parking and we need the
|
|
|
|
* callback name to be that of transferer. Since local,1/2 have
|
|
|
|
* the same name we can be tricky and just grab the bridged
|
|
|
|
* channel from the other side of the local.
|
|
|
|
*/
|
2012-02-20 23:43:27 +00:00
|
|
|
if (!strcasecmp(ast_channel_tech(peer)->type, "Local")) {
|
2009-01-20 19:22:24 +00:00
|
|
|
struct ast_channel *tmpchan, *base_peer;
|
|
|
|
char other_side[AST_CHANNEL_NAME];
|
|
|
|
char *c;
|
2011-08-16 17:23:08 +00:00
|
|
|
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_copy_string(other_side, event_from, sizeof(other_side));
|
2009-01-20 19:22:24 +00:00
|
|
|
if ((c = strrchr(other_side, ';'))) {
|
|
|
|
*++c = '1';
|
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
if ((tmpchan = ast_channel_get_by_name(other_side))) {
|
|
|
|
ast_channel_lock(tmpchan);
|
2009-01-20 19:22:24 +00:00
|
|
|
if ((base_peer = ast_bridged_channel(tmpchan))) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_copy_string(pu->peername, ast_channel_name(base_peer), sizeof(pu->peername));
|
2009-01-20 19:22:24 +00:00
|
|
|
}
|
|
|
|
ast_channel_unlock(tmpchan);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
tmpchan = ast_channel_unref(tmpchan);
|
2009-01-20 19:22:24 +00:00
|
|
|
}
|
|
|
|
} else {
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_copy_string(pu->peername, event_from, sizeof(pu->peername));
|
2009-01-20 19:22:24 +00:00
|
|
|
}
|
2012-02-23 20:14:54 +00:00
|
|
|
} else {
|
|
|
|
event_from = S_OR(pbx_builtin_getvar_helper(chan, "BLINDTRANSFER"),
|
|
|
|
ast_channel_name(chan));
|
2009-01-20 19:22:24 +00:00
|
|
|
}
|
2005-07-25 17:31:53 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*
|
|
|
|
* Remember what had been dialed, so that if the parking
|
|
|
|
* expires, we try to come back to the same place
|
|
|
|
*/
|
2009-07-08 17:26:26 +00:00
|
|
|
pu->options_specified = (!ast_strlen_zero(args->return_con) || !ast_strlen_zero(args->return_ext) || args->return_pri);
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*
|
|
|
|
* If extension has options specified, they override all other
|
|
|
|
* possibilities such as the returntoorigin flag and transferred
|
|
|
|
* context. Information on extension options is lost here, so
|
|
|
|
* we set a flag
|
|
|
|
*/
|
2012-03-22 19:51:16 +00:00
|
|
|
ast_copy_string(pu->context,
|
|
|
|
S_OR(args->return_con, S_OR(ast_channel_macrocontext(chan), ast_channel_context(chan))),
|
2008-04-25 18:18:27 +00:00
|
|
|
sizeof(pu->context));
|
2012-03-22 19:51:16 +00:00
|
|
|
ast_copy_string(pu->exten,
|
|
|
|
S_OR(args->return_ext, S_OR(ast_channel_macroexten(chan), ast_channel_exten(chan))),
|
2008-04-25 18:18:27 +00:00
|
|
|
sizeof(pu->exten));
|
2012-03-22 19:51:16 +00:00
|
|
|
pu->priority = args->return_pri ? args->return_pri :
|
2012-02-20 23:43:27 +00:00
|
|
|
(ast_channel_macropriority(chan) ? ast_channel_macropriority(chan) : ast_channel_priority(chan));
|
2008-04-25 18:18:27 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*
|
|
|
|
* If parking a channel directly, don't quite yet get parking
|
|
|
|
* running on it. All parking lot entries are put into the
|
|
|
|
* parking lot with notquiteyet on.
|
|
|
|
*/
|
|
|
|
if (peer != chan) {
|
2009-02-04 21:17:53 +00:00
|
|
|
pu->notquiteyet = 0;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2005-07-25 17:31:53 +00:00
|
|
|
/* Wake up the (presumably select()ing) thread */
|
|
|
|
pthread_kill(parking_thread, SIGURG);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_verb(2, "Parked %s on %d (lot %s). Will timeout back to extension [%s] %s, %d in %d seconds\n",
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_channel_name(chan), pu->parkingnum, pu->parkinglot->name,
|
2011-08-16 17:23:08 +00:00
|
|
|
pu->context, pu->exten, pu->priority, (pu->parkingtime / 1000));
|
2005-07-25 17:31:53 +00:00
|
|
|
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_cel_report_event(chan, AST_CEL_PARK_START, NULL, pu->parkinglot->name, peer);
|
2009-06-26 15:28:53 +00:00
|
|
|
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_manager_event(chan, EVENT_FLAG_CALL, "ParkedCall",
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
"Exten: %s\r\n"
|
2005-07-25 17:31:53 +00:00
|
|
|
"Channel: %s\r\n"
|
2008-04-21 23:42:45 +00:00
|
|
|
"Parkinglot: %s\r\n"
|
2005-07-25 17:31:53 +00:00
|
|
|
"From: %s\r\n"
|
|
|
|
"Timeout: %ld\r\n"
|
2006-10-02 20:35:16 +00:00
|
|
|
"CallerIDNum: %s\r\n"
|
2008-08-17 14:12:11 +00:00
|
|
|
"CallerIDName: %s\r\n"
|
2011-05-25 17:14:11 +00:00
|
|
|
"ConnectedLineNum: %s\r\n"
|
|
|
|
"ConnectedLineName: %s\r\n"
|
2008-08-17 14:12:11 +00:00
|
|
|
"Uniqueid: %s\r\n",
|
2012-02-23 20:14:54 +00:00
|
|
|
pu->parkingexten, ast_channel_name(chan), pu->parkinglot->name, event_from,
|
2006-04-21 10:47:07 +00:00
|
|
|
(long)pu->start.tv_sec + (long)(pu->parkingtime/1000) - (long)time(NULL),
|
2012-02-29 16:52:47 +00:00
|
|
|
S_COR(ast_channel_caller(chan)->id.number.valid, ast_channel_caller(chan)->id.number.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_caller(chan)->id.name.valid, ast_channel_caller(chan)->id.name.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_connected(chan)->id.number.valid, ast_channel_connected(chan)->id.number.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_connected(chan)->id.name.valid, ast_channel_connected(chan)->id.name.str, "<unknown>"),
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_channel_uniqueid(chan)
|
2005-07-25 17:31:53 +00:00
|
|
|
);
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_debug(4, "peer: %s\n", peer ? ast_channel_name(peer) : "-No peer-");
|
|
|
|
ast_debug(4, "args->orig_chan_name: %s\n", args->orig_chan_name ? args->orig_chan_name : "-none-");
|
|
|
|
ast_debug(4, "pu->peername: %s\n", pu->peername);
|
|
|
|
ast_debug(4, "AMI ParkedCall Channel: %s\n", ast_channel_name(chan));
|
|
|
|
ast_debug(4, "AMI ParkedCall From: %s\n", event_from);
|
2003-07-02 14:06:12 +00:00
|
|
|
|
2006-09-20 04:34:51 +00:00
|
|
|
if (peer && adsipark && ast_adsi_available(peer)) {
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
adsi_announce_park(peer, pu->parkingexten); /* Only supports parking numbers */
|
2006-09-20 04:34:51 +00:00
|
|
|
ast_adsi_unload_session(peer);
|
2005-07-25 17:31:53 +00:00
|
|
|
}
|
2006-06-21 07:49:29 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
snprintf(app_data, sizeof(app_data), "%s,%s", pu->parkingexten,
|
|
|
|
pu->parkinglot->name);
|
|
|
|
if (ast_add_extension(pu->parkinglot->cfg.parking_con, 1, pu->parkingexten, 1,
|
|
|
|
NULL, NULL, parkedcall, ast_strdup(app_data), ast_free_ptr, registrar)) {
|
|
|
|
ast_log(LOG_ERROR, "Could not create parked call exten: %s@%s\n",
|
|
|
|
pu->parkingexten, pu->parkinglot->cfg.parking_con);
|
|
|
|
} else {
|
|
|
|
notify_metermaids(pu->parkingexten, pu->parkinglot->cfg.parking_con, AST_DEVICE_INUSE);
|
2008-10-06 22:26:25 +00:00
|
|
|
}
|
|
|
|
|
2009-02-04 21:17:53 +00:00
|
|
|
AST_LIST_UNLOCK(&pu->parkinglot->parkings);
|
2008-10-06 22:26:25 +00:00
|
|
|
|
2008-10-06 22:08:40 +00:00
|
|
|
/* Only say number if it's a number and the channel hasn't been masqueraded away */
|
2011-08-16 17:23:08 +00:00
|
|
|
if (peer && !ast_test_flag(args, AST_PARK_OPT_SILENCE)
|
2012-01-09 22:15:50 +00:00
|
|
|
&& (ast_strlen_zero(args->orig_chan_name) || !strcasecmp(ast_channel_name(peer), args->orig_chan_name))) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/*
|
|
|
|
* If a channel is masqueraded into peer while playing back the
|
|
|
|
* parking space number do not continue playing it back. This
|
|
|
|
* is the case if an attended transfer occurs.
|
|
|
|
*/
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_set_flag(ast_channel_flags(peer), AST_FLAG_MASQ_NOSTREAM);
|
2008-10-06 22:08:40 +00:00
|
|
|
/* Tell the peer channel the number of the parking space */
|
2012-01-24 20:12:09 +00:00
|
|
|
ast_say_digits(peer, pu->parkingnum, "", ast_channel_language(peer));
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_clear_flag(ast_channel_flags(peer), AST_FLAG_MASQ_NOSTREAM);
|
2007-09-05 20:58:19 +00:00
|
|
|
}
|
2008-10-06 22:26:25 +00:00
|
|
|
if (peer == chan) { /* pu->notquiteyet = 1 */
|
2005-07-25 17:31:53 +00:00
|
|
|
/* Wake up parking thread if we're really done */
|
2011-08-16 17:23:08 +00:00
|
|
|
pu->hold_method = AST_CONTROL_HOLD;
|
2012-02-23 20:14:54 +00:00
|
|
|
ast_indicate_data(chan, AST_CONTROL_HOLD,
|
2011-08-16 17:23:08 +00:00
|
|
|
S_OR(pu->parkinglot->cfg.mohclass, NULL),
|
|
|
|
!ast_strlen_zero(pu->parkinglot->cfg.mohclass) ? strlen(pu->parkinglot->cfg.mohclass) + 1 : 0);
|
2005-07-25 17:31:53 +00:00
|
|
|
pu->notquiteyet = 0;
|
|
|
|
pthread_kill(parking_thread, SIGURG);
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
int ast_park_call_exten(struct ast_channel *park_me, struct ast_channel *parker, const char *park_exten, const char *park_context, int timeout, int *extout)
|
2007-11-21 19:20:33 +00:00
|
|
|
{
|
2011-10-18 21:15:45 +00:00
|
|
|
int res;
|
|
|
|
char *parse;
|
|
|
|
const char *app_data;
|
|
|
|
struct ast_exten *exten;
|
|
|
|
struct park_app_args app_args;
|
2008-04-25 18:18:27 +00:00
|
|
|
struct ast_park_call_args args = {
|
|
|
|
.timeout = timeout,
|
|
|
|
.extout = extout,
|
|
|
|
};
|
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
if (!park_exten || !park_context) {
|
|
|
|
return park_call_full(park_me, parker, &args);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determiine if the specified park extension has an exclusive
|
|
|
|
* parking lot to use.
|
|
|
|
*/
|
|
|
|
if (parker && parker != park_me) {
|
|
|
|
ast_autoservice_start(park_me);
|
|
|
|
}
|
|
|
|
exten = get_parking_exten(park_exten, parker, park_context);
|
|
|
|
if (exten) {
|
|
|
|
app_data = ast_get_extension_app_data(exten);
|
|
|
|
if (!app_data) {
|
|
|
|
app_data = "";
|
|
|
|
}
|
|
|
|
parse = ast_strdupa(app_data);
|
|
|
|
AST_STANDARD_APP_ARGS(app_args, parse);
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
if (!ast_strlen_zero(app_args.pl_name)) {
|
|
|
|
/* Find the specified exclusive parking lot */
|
|
|
|
args.parkinglot = find_parkinglot(app_args.pl_name);
|
|
|
|
if (!args.parkinglot && parkeddynamic) {
|
|
|
|
args.parkinglot = create_dynamic_parkinglot(app_args.pl_name, park_me);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (parker && parker != park_me) {
|
|
|
|
ast_autoservice_stop(park_me);
|
|
|
|
}
|
|
|
|
|
|
|
|
res = park_call_full(park_me, parker, &args);
|
|
|
|
if (args.parkinglot) {
|
|
|
|
parkinglot_unref(args.parkinglot);
|
|
|
|
}
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ast_park_call(struct ast_channel *park_me, struct ast_channel *parker, int timeout, const char *park_exten, int *extout)
|
|
|
|
{
|
|
|
|
struct ast_park_call_args args = {
|
|
|
|
.timeout = timeout,
|
|
|
|
.extout = extout,
|
|
|
|
};
|
|
|
|
|
|
|
|
return park_call_full(park_me, parker, &args);
|
2007-11-21 19:20:33 +00:00
|
|
|
}
|
|
|
|
|
2010-09-15 19:23:56 +00:00
|
|
|
/*!
|
2011-10-18 21:15:45 +00:00
|
|
|
* \brief Park call via masqueraded channel and announce parking spot on peer channel.
|
|
|
|
*
|
2011-08-16 17:23:08 +00:00
|
|
|
* \param rchan the real channel to be parked
|
|
|
|
* \param peer the channel to have the parking read to.
|
2011-10-18 21:15:45 +00:00
|
|
|
* \param args Additional parking options when parking a call.
|
2011-08-16 17:23:08 +00:00
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on failure.
|
2010-09-15 19:23:56 +00:00
|
|
|
*/
|
2011-10-18 21:15:45 +00:00
|
|
|
static int masq_park_call(struct ast_channel *rchan, struct ast_channel *peer, struct ast_park_call_args *args)
|
2001-12-27 11:07:33 +00:00
|
|
|
{
|
|
|
|
struct ast_channel *chan;
|
2009-02-04 21:17:53 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Make a new, channel that we'll use to masquerade in the real one */
|
2012-02-13 17:27:06 +00:00
|
|
|
chan = ast_channel_alloc(0, AST_STATE_DOWN, 0, 0, ast_channel_accountcode(rchan), ast_channel_exten(rchan),
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_context(rchan), ast_channel_linkedid(rchan), ast_channel_amaflags(rchan), "Parked/%s", ast_channel_name(rchan));
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!chan) {
|
|
|
|
ast_log(LOG_WARNING, "Unable to create parked channel\n");
|
2011-09-07 19:35:18 +00:00
|
|
|
if (!ast_test_flag(args, AST_PARK_OPT_SILENCE)) {
|
|
|
|
if (peer == rchan) {
|
|
|
|
/* Only have one channel to worry about. */
|
|
|
|
ast_stream_and_wait(peer, "pbx-parkingfailed", "");
|
|
|
|
} else if (peer) {
|
|
|
|
/* Have two different channels to worry about. */
|
|
|
|
play_message_on_chan(peer, rchan, "failure message", "pbx-parkingfailed");
|
|
|
|
}
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
return -1;
|
2009-02-04 21:17:53 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
args->pu = park_space_reserve(rchan, peer, args);
|
|
|
|
if (!args->pu) {
|
|
|
|
ast_hangup(chan);
|
2011-09-07 19:35:18 +00:00
|
|
|
if (!ast_test_flag(args, AST_PARK_OPT_SILENCE)) {
|
|
|
|
if (peer == rchan) {
|
|
|
|
/* Only have one channel to worry about. */
|
|
|
|
ast_stream_and_wait(peer, "pbx-parkingfailed", "");
|
|
|
|
} else if (peer) {
|
|
|
|
/* Have two different channels to worry about. */
|
|
|
|
play_message_on_chan(peer, rchan, "failure message", "pbx-parkingfailed");
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2001-12-27 11:07:33 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2006-06-21 07:49:29 +00:00
|
|
|
|
|
|
|
/* Make formats okay */
|
2012-02-24 00:32:20 +00:00
|
|
|
ast_format_copy(ast_channel_readformat(chan), ast_channel_readformat(rchan));
|
|
|
|
ast_format_copy(ast_channel_writeformat(chan), ast_channel_writeformat(rchan));
|
2011-10-18 21:15:45 +00:00
|
|
|
|
|
|
|
if (ast_channel_masquerade(chan, rchan)) {
|
|
|
|
park_space_abort(args->pu);
|
|
|
|
args->pu = NULL;
|
|
|
|
ast_hangup(chan);
|
|
|
|
if (!ast_test_flag(args, AST_PARK_OPT_SILENCE)) {
|
|
|
|
if (peer == rchan) {
|
|
|
|
/* Only have one channel to worry about. */
|
|
|
|
ast_stream_and_wait(peer, "pbx-parkingfailed", "");
|
|
|
|
} else if (peer) {
|
|
|
|
/* Have two different channels to worry about. */
|
|
|
|
play_message_on_chan(peer, rchan, "failure message", "pbx-parkingfailed");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
2006-06-21 07:49:29 +00:00
|
|
|
|
|
|
|
/* Setup the extensions and such */
|
2012-02-20 23:43:27 +00:00
|
|
|
set_c_e_p(chan, ast_channel_context(rchan), ast_channel_exten(rchan), ast_channel_priority(rchan));
|
2006-06-21 07:49:29 +00:00
|
|
|
|
2010-01-13 19:48:16 +00:00
|
|
|
/* Setup the macro extension and such */
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_macrocontext_set(chan, ast_channel_macrocontext(rchan));
|
|
|
|
ast_channel_macroexten_set(chan, ast_channel_macroexten(rchan));
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_macropriority_set(chan, ast_channel_macropriority(rchan));
|
2010-01-13 19:48:16 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Manually do the masquerade to make sure it is complete. */
|
|
|
|
ast_do_masquerade(chan);
|
2006-06-21 07:49:29 +00:00
|
|
|
|
2009-01-16 22:16:23 +00:00
|
|
|
if (peer == rchan) {
|
|
|
|
peer = chan;
|
|
|
|
}
|
2008-04-25 18:18:27 +00:00
|
|
|
|
2010-09-15 19:23:56 +00:00
|
|
|
/* parking space reserved, return code check unnecessary */
|
|
|
|
park_call_full(chan, peer, args);
|
2008-01-28 18:41:23 +00:00
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
int ast_masq_park_call_exten(struct ast_channel *park_me, struct ast_channel *parker, const char *park_exten, const char *park_context, int timeout, int *extout)
|
2008-10-06 22:26:25 +00:00
|
|
|
{
|
2011-10-18 21:15:45 +00:00
|
|
|
int res;
|
|
|
|
char *parse;
|
|
|
|
const char *app_data;
|
|
|
|
struct ast_exten *exten;
|
|
|
|
struct park_app_args app_args;
|
|
|
|
struct ast_park_call_args args = {
|
|
|
|
.timeout = timeout,
|
|
|
|
.extout = extout,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (parker) {
|
2012-01-09 22:15:50 +00:00
|
|
|
args.orig_chan_name = ast_strdupa(ast_channel_name(parker));
|
2011-10-18 21:15:45 +00:00
|
|
|
}
|
|
|
|
if (!park_exten || !park_context) {
|
|
|
|
return masq_park_call(park_me, parker, &args);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determiine if the specified park extension has an exclusive
|
|
|
|
* parking lot to use.
|
|
|
|
*/
|
|
|
|
if (parker && parker != park_me) {
|
|
|
|
ast_autoservice_start(park_me);
|
|
|
|
}
|
|
|
|
exten = get_parking_exten(park_exten, parker, park_context);
|
|
|
|
if (exten) {
|
|
|
|
app_data = ast_get_extension_app_data(exten);
|
|
|
|
if (!app_data) {
|
|
|
|
app_data = "";
|
|
|
|
}
|
|
|
|
parse = ast_strdupa(app_data);
|
|
|
|
AST_STANDARD_APP_ARGS(app_args, parse);
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
if (!ast_strlen_zero(app_args.pl_name)) {
|
|
|
|
/* Find the specified exclusive parking lot */
|
|
|
|
args.parkinglot = find_parkinglot(app_args.pl_name);
|
|
|
|
if (!args.parkinglot && parkeddynamic) {
|
|
|
|
args.parkinglot = create_dynamic_parkinglot(app_args.pl_name, park_me);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (parker && parker != park_me) {
|
|
|
|
ast_autoservice_stop(park_me);
|
|
|
|
}
|
|
|
|
|
|
|
|
res = masq_park_call(park_me, parker, &args);
|
|
|
|
if (args.parkinglot) {
|
|
|
|
parkinglot_unref(args.parkinglot);
|
|
|
|
}
|
|
|
|
return res;
|
2008-10-06 22:26:25 +00:00
|
|
|
}
|
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
int ast_masq_park_call(struct ast_channel *rchan, struct ast_channel *peer, int timeout, int *extout)
|
2008-10-06 22:26:25 +00:00
|
|
|
{
|
2011-10-18 21:15:45 +00:00
|
|
|
struct ast_park_call_args args = {
|
|
|
|
.timeout = timeout,
|
|
|
|
.extout = extout,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (peer) {
|
2012-01-09 22:15:50 +00:00
|
|
|
args.orig_chan_name = ast_strdupa(ast_channel_name(peer));
|
2011-10-18 21:15:45 +00:00
|
|
|
}
|
|
|
|
return masq_park_call(rchan, peer, &args);
|
2008-10-06 22:26:25 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
static int finishup(struct ast_channel *chan)
|
2010-03-10 20:51:23 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_indicate(chan, AST_CONTROL_UNHOLD);
|
|
|
|
|
|
|
|
return ast_autoservice_stop(chan);
|
2010-03-10 20:51:23 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Builtin transfer park call helper.
|
|
|
|
*
|
|
|
|
* \param park_me Channel to be parked.
|
|
|
|
* \param parker Channel parking the call.
|
|
|
|
* \param park_exten Parking lot dialplan access ramp extension.
|
|
|
|
*
|
|
|
|
* \note Assumes park_me is on hold and in autoservice.
|
|
|
|
*
|
|
|
|
* \retval -1 on successful park.
|
|
|
|
* \retval -1 on park_me hangup.
|
|
|
|
* \retval AST_FEATURE_RETURN_SUCCESS on error to keep the bridge connected.
|
|
|
|
*/
|
|
|
|
static int xfer_park_call_helper(struct ast_channel *park_me, struct ast_channel *parker, struct ast_exten *park_exten)
|
2010-03-10 20:51:23 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
char *parse;
|
|
|
|
const char *app_data;
|
|
|
|
const char *pl_name;
|
|
|
|
struct ast_park_call_args args = { 0, };
|
|
|
|
struct park_app_args app_args;
|
|
|
|
int res;
|
2010-03-10 20:51:23 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
app_data = ast_get_extension_app_data(park_exten);
|
|
|
|
if (!app_data) {
|
|
|
|
app_data = "";
|
|
|
|
}
|
|
|
|
parse = ast_strdupa(app_data);
|
|
|
|
AST_STANDARD_APP_ARGS(app_args, parse);
|
2011-02-03 16:22:10 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Find the parking lot */
|
|
|
|
if (!ast_strlen_zero(app_args.pl_name)) {
|
|
|
|
pl_name = app_args.pl_name;
|
|
|
|
} else {
|
|
|
|
pl_name = findparkinglotname(parker);
|
|
|
|
}
|
|
|
|
if (ast_strlen_zero(pl_name)) {
|
|
|
|
/* Parking lot is not specified, so use the default parking lot. */
|
|
|
|
args.parkinglot = parkinglot_addref(default_parkinglot);
|
|
|
|
} else {
|
|
|
|
args.parkinglot = find_parkinglot(pl_name);
|
|
|
|
if (!args.parkinglot && parkeddynamic) {
|
|
|
|
args.parkinglot = create_dynamic_parkinglot(pl_name, park_me);
|
|
|
|
}
|
|
|
|
}
|
2011-02-03 16:22:10 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (args.parkinglot) {
|
|
|
|
/* Park the call */
|
|
|
|
res = finishup(park_me);
|
|
|
|
if (res) {
|
|
|
|
/* park_me hungup on us. */
|
|
|
|
parkinglot_unref(args.parkinglot);
|
|
|
|
return -1;
|
|
|
|
}
|
2011-10-18 21:15:45 +00:00
|
|
|
res = masq_park_call(park_me, parker, &args);
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot_unref(args.parkinglot);
|
|
|
|
} else {
|
|
|
|
/* Parking failed because parking lot does not exist. */
|
2011-09-07 19:35:18 +00:00
|
|
|
if (!ast_test_flag(&args, AST_PARK_OPT_SILENCE)) {
|
|
|
|
ast_stream_and_wait(parker, "pbx-parkingfailed", "");
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
finishup(park_me);
|
|
|
|
res = -1;
|
|
|
|
}
|
2010-03-10 20:51:23 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
return res ? AST_FEATURE_RETURN_SUCCESS : -1;
|
2010-03-10 20:51:23 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \brief set caller and callee according to the direction
|
|
|
|
* \param caller, callee, peer, chan, sense
|
|
|
|
*
|
|
|
|
* Detect who triggered feature and set callee/caller variables accordingly
|
|
|
|
*/
|
|
|
|
static void set_peers(struct ast_channel **caller, struct ast_channel **callee,
|
|
|
|
struct ast_channel *peer, struct ast_channel *chan, int sense)
|
2006-04-16 19:26:57 +00:00
|
|
|
{
|
|
|
|
if (sense == FEATURE_SENSE_PEER) {
|
|
|
|
*caller = peer;
|
|
|
|
*callee = chan;
|
|
|
|
} else {
|
|
|
|
*callee = peer;
|
|
|
|
*caller = chan;
|
|
|
|
}
|
|
|
|
}
|
2005-01-04 04:01:40 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
2010-09-15 19:23:56 +00:00
|
|
|
* \brief support routing for one touch call parking
|
|
|
|
* \param chan channel parking call
|
|
|
|
* \param peer channel to be parked
|
|
|
|
* \param config unsed
|
|
|
|
* \param code unused
|
|
|
|
* \param sense feature options
|
2011-08-16 17:23:08 +00:00
|
|
|
* \param data unused
|
2010-09-15 19:23:56 +00:00
|
|
|
*
|
2011-08-16 17:23:08 +00:00
|
|
|
* \retval -1 on successful park.
|
|
|
|
* \retval -1 on chan hangup.
|
|
|
|
* \retval AST_FEATURE_RETURN_SUCCESS on error to keep the bridge connected.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2010-09-15 19:23:56 +00:00
|
|
|
static int builtin_parkcall(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense, void *data)
|
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_channel *parker;
|
|
|
|
struct ast_channel *parkee;
|
2011-10-18 21:15:45 +00:00
|
|
|
struct ast_park_call_args args = { 0, };
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We used to set chan's exten and priority to "s" and 1 here,
|
|
|
|
* but this generates (in some cases) an invalid extension, and
|
|
|
|
* if "s" exists, could errantly cause execution of extensions
|
|
|
|
* you don't expect. It makes more sense to let nature take its
|
|
|
|
* course when chan finishes, and let the pbx do its thing and
|
|
|
|
* hang up when the park is over.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Answer if call is not up */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chan) != AST_STATE_UP) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/*
|
|
|
|
* XXX Why are we doing this? Both of the channels should be up
|
|
|
|
* since you cannot do DTMF features unless you are bridged.
|
|
|
|
*/
|
|
|
|
if (ast_answer(chan)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Sleep to allow VoIP streams to settle down */
|
|
|
|
if (ast_safe_sleep(chan, 1000)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* one direction used to call park_call.... */
|
|
|
|
set_peers(&parker, &parkee, peer, chan, sense);
|
2011-10-18 21:15:45 +00:00
|
|
|
return masq_park_call(parkee, parker, &args) ? AST_FEATURE_RETURN_SUCCESS : -1;
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
|
|
|
|
2011-05-20 17:04:53 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \internal
|
|
|
|
* \brief Play file to specified channel.
|
|
|
|
*
|
|
|
|
* \param play_to Channel to play audiofile to.
|
|
|
|
* \param other Channel to put in autoservice while playing file.
|
|
|
|
* \param msg Descriptive name of message type being played.
|
|
|
|
* \param audiofile Audio file to play.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on error. (Couldn't play file, a channel hung up,...)
|
2008-05-12 18:39:09 +00:00
|
|
|
*/
|
2011-08-16 17:23:08 +00:00
|
|
|
static int play_message_on_chan(struct ast_channel *play_to, struct ast_channel *other, const char *msg, const char *audiofile)
|
2008-05-12 18:39:09 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Put other channel in autoservice. */
|
|
|
|
if (ast_autoservice_start(other)) {
|
2008-05-12 18:39:09 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_autoservice_ignore(other, AST_FRAME_DTMF_BEGIN);
|
|
|
|
ast_autoservice_ignore(other, AST_FRAME_DTMF_END);
|
|
|
|
if (ast_stream_and_wait(play_to, audiofile, "")) {
|
|
|
|
ast_log(LOG_WARNING, "Failed to play %s '%s'!\n", msg, audiofile);
|
|
|
|
ast_autoservice_stop(other);
|
2008-05-12 18:39:09 +00:00
|
|
|
return -1;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
if (ast_autoservice_stop(other)) {
|
2008-05-12 18:39:09 +00:00
|
|
|
return -1;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Play file to specified channels.
|
|
|
|
*
|
|
|
|
* \param left Channel on left to play file.
|
|
|
|
* \param right Channel on right to play file.
|
|
|
|
* \param which Play file on indicated channels: which < 0 play left, which == 0 play both, which > 0 play right
|
|
|
|
* \param msg Descriptive name of message type being played.
|
|
|
|
* \param audiofile Audio file to play to channels.
|
|
|
|
*
|
|
|
|
* \note Plays file to the indicated channels in turn so please
|
|
|
|
* don't use this for very long messages.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on error. (Couldn't play file, channel hung up,...)
|
|
|
|
*/
|
|
|
|
static int play_message_to_chans(struct ast_channel *left, struct ast_channel *right, int which, const char *msg, const char *audiofile)
|
|
|
|
{
|
|
|
|
/* First play the file to the left channel if requested. */
|
|
|
|
if (which <= 0 && play_message_on_chan(left, right, msg, audiofile)) {
|
2008-05-12 18:39:09 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
/* Then play the file to the right channel if requested. */
|
|
|
|
if (which >= 0 && play_message_on_chan(right, left, msg, audiofile)) {
|
2008-05-12 18:39:09 +00:00
|
|
|
return -1;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief Play message to both caller and callee in bridged call, plays synchronously, autoservicing the
|
|
|
|
* other channel during the message, so please don't use this for very long messages
|
|
|
|
*/
|
|
|
|
static int play_message_in_bridged_call(struct ast_channel *caller_chan, struct ast_channel *callee_chan, const char *audiofile)
|
|
|
|
{
|
|
|
|
return play_message_to_chans(caller_chan, callee_chan, 0, "automon message",
|
|
|
|
audiofile);
|
2008-05-12 18:39:09 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief Monitor a channel by DTMF
|
|
|
|
* \param chan channel requesting monitor
|
|
|
|
* \param peer channel to be monitored
|
|
|
|
* \param config
|
|
|
|
* \param code
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param sense feature options
|
|
|
|
*
|
2007-08-23 20:20:17 +00:00
|
|
|
* \param data
|
2007-08-07 23:04:01 +00:00
|
|
|
* Check monitor app enabled, setup channels, both caller/callee chans not null
|
|
|
|
* get TOUCH_MONITOR variable for filename if exists, exec monitor app.
|
2008-04-08 17:32:42 +00:00
|
|
|
* \retval AST_FEATURE_RETURN_SUCCESS on success.
|
2007-08-07 23:04:01 +00:00
|
|
|
* \retval -1 on error.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2009-05-21 21:13:09 +00:00
|
|
|
static int builtin_automonitor(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense, void *data)
|
2005-01-05 19:56:47 +00:00
|
|
|
{
|
2005-12-08 18:18:59 +00:00
|
|
|
char *caller_chan_id = NULL, *callee_chan_id = NULL, *args = NULL, *touch_filename = NULL;
|
2005-01-10 04:03:30 +00:00
|
|
|
int x = 0;
|
|
|
|
size_t len;
|
2006-04-18 13:05:48 +00:00
|
|
|
struct ast_channel *caller_chan, *callee_chan;
|
2008-05-12 18:39:09 +00:00
|
|
|
const char *automon_message_start = NULL;
|
|
|
|
const char *automon_message_stop = NULL;
|
2005-01-11 18:24:27 +00:00
|
|
|
|
2005-01-10 04:03:30 +00:00
|
|
|
if (!monitor_ok) {
|
|
|
|
ast_log(LOG_ERROR,"Cannot record the call. The monitor application is disabled.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
2005-01-05 19:56:47 +00:00
|
|
|
|
2006-04-16 18:37:01 +00:00
|
|
|
if (!monitor_app && !(monitor_app = pbx_findapp("Monitor"))) {
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
monitor_ok = 0;
|
2006-04-16 18:37:01 +00:00
|
|
|
ast_log(LOG_ERROR,"Cannot record the call. The monitor application is disabled.\n");
|
|
|
|
return -1;
|
2005-01-10 04:03:30 +00:00
|
|
|
}
|
2006-04-16 19:26:57 +00:00
|
|
|
|
|
|
|
set_peers(&caller_chan, &callee_chan, peer, chan, sense);
|
2008-05-12 18:39:09 +00:00
|
|
|
if (caller_chan) { /* Find extra messages */
|
|
|
|
automon_message_start = pbx_builtin_getvar_helper(caller_chan, "TOUCH_MONITOR_MESSAGE_START");
|
|
|
|
automon_message_stop = pbx_builtin_getvar_helper(caller_chan, "TOUCH_MONITOR_MESSAGE_STOP");
|
|
|
|
}
|
2006-04-16 19:26:57 +00:00
|
|
|
|
2008-05-12 18:39:09 +00:00
|
|
|
if (!ast_strlen_zero(courtesytone)) { /* Play courtesy tone if configured */
|
|
|
|
if(play_message_in_bridged_call(caller_chan, callee_chan, courtesytone) == -1) {
|
2006-04-16 22:46:00 +00:00
|
|
|
return -1;
|
2005-01-05 22:38:07 +00:00
|
|
|
}
|
2005-01-10 04:03:30 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_monitor(callee_chan)) {
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(4, "User hit '%s' to stop recording call.\n", code);
|
2008-05-12 18:39:09 +00:00
|
|
|
if (!ast_strlen_zero(automon_message_stop)) {
|
|
|
|
play_message_in_bridged_call(caller_chan, callee_chan, automon_message_stop);
|
|
|
|
}
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_monitor(callee_chan)->stop(callee_chan, 1);
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2005-01-05 19:56:47 +00:00
|
|
|
}
|
|
|
|
|
2005-01-11 18:24:27 +00:00
|
|
|
if (caller_chan && callee_chan) {
|
2005-12-03 19:25:33 +00:00
|
|
|
const char *touch_format = pbx_builtin_getvar_helper(caller_chan, "TOUCH_MONITOR_FORMAT");
|
|
|
|
const char *touch_monitor = pbx_builtin_getvar_helper(caller_chan, "TOUCH_MONITOR");
|
2007-10-15 20:08:04 +00:00
|
|
|
const char *touch_monitor_prefix = pbx_builtin_getvar_helper(caller_chan, "TOUCH_MONITOR_PREFIX");
|
2005-12-03 19:25:33 +00:00
|
|
|
|
2005-05-16 00:43:16 +00:00
|
|
|
if (!touch_format)
|
|
|
|
touch_format = pbx_builtin_getvar_helper(callee_chan, "TOUCH_MONITOR_FORMAT");
|
|
|
|
|
2005-01-10 04:03:30 +00:00
|
|
|
if (!touch_monitor)
|
2005-01-11 18:24:27 +00:00
|
|
|
touch_monitor = pbx_builtin_getvar_helper(callee_chan, "TOUCH_MONITOR");
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2007-10-15 20:08:04 +00:00
|
|
|
if (!touch_monitor_prefix)
|
|
|
|
touch_monitor_prefix = pbx_builtin_getvar_helper(callee_chan, "TOUCH_MONITOR_PREFIX");
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2005-01-10 04:03:30 +00:00
|
|
|
if (touch_monitor) {
|
|
|
|
len = strlen(touch_monitor) + 50;
|
|
|
|
args = alloca(len);
|
2005-12-08 18:18:59 +00:00
|
|
|
touch_filename = alloca(len);
|
2007-10-15 20:08:04 +00:00
|
|
|
snprintf(touch_filename, len, "%s-%ld-%s", S_OR(touch_monitor_prefix, "auto"), (long)time(NULL), touch_monitor);
|
2008-02-26 14:51:21 +00:00
|
|
|
snprintf(args, len, "%s,%s,m", S_OR(touch_format, "wav"), touch_filename);
|
2005-01-10 04:03:30 +00:00
|
|
|
} else {
|
2012-02-29 16:52:47 +00:00
|
|
|
caller_chan_id = ast_strdupa(S_COR(ast_channel_caller(caller_chan)->id.number.valid,
|
|
|
|
ast_channel_caller(caller_chan)->id.number.str, ast_channel_name(caller_chan)));
|
|
|
|
callee_chan_id = ast_strdupa(S_COR(ast_channel_caller(callee_chan)->id.number.valid,
|
|
|
|
ast_channel_caller(callee_chan)->id.number.str, ast_channel_name(callee_chan)));
|
2005-01-11 18:24:27 +00:00
|
|
|
len = strlen(caller_chan_id) + strlen(callee_chan_id) + 50;
|
2005-01-10 04:03:30 +00:00
|
|
|
args = alloca(len);
|
2005-12-08 18:18:59 +00:00
|
|
|
touch_filename = alloca(len);
|
2007-10-15 20:08:04 +00:00
|
|
|
snprintf(touch_filename, len, "%s-%ld-%s-%s", S_OR(touch_monitor_prefix, "auto"), (long)time(NULL), caller_chan_id, callee_chan_id);
|
2008-02-26 14:51:21 +00:00
|
|
|
snprintf(args, len, "%s,%s,m", S_OR(touch_format, "wav"), touch_filename);
|
2005-01-10 04:03:30 +00:00
|
|
|
}
|
|
|
|
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
for(x = 0; x < strlen(args); x++) {
|
2005-01-10 04:03:30 +00:00
|
|
|
if (args[x] == '/')
|
|
|
|
args[x] = '-';
|
2006-04-14 23:20:29 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(4, "User hit '%s' to record call. filename: %s\n", code, args);
|
2005-01-10 04:03:30 +00:00
|
|
|
|
2006-03-30 21:29:39 +00:00
|
|
|
pbx_exec(callee_chan, monitor_app, args);
|
2005-12-08 18:18:59 +00:00
|
|
|
pbx_builtin_setvar_helper(callee_chan, "TOUCH_MONITOR_OUTPUT", touch_filename);
|
|
|
|
pbx_builtin_setvar_helper(caller_chan, "TOUCH_MONITOR_OUTPUT", touch_filename);
|
2008-05-12 18:39:09 +00:00
|
|
|
|
|
|
|
if (!ast_strlen_zero(automon_message_start)) { /* Play start message for both channels */
|
|
|
|
play_message_in_bridged_call(caller_chan, callee_chan, automon_message_start);
|
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2005-01-10 04:03:30 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
|
|
|
ast_log(LOG_NOTICE,"Cannot record the call. One or both channels have gone away.\n");
|
2005-01-05 19:56:47 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
static int builtin_automixmonitor(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense, void *data)
|
2007-11-30 21:19:57 +00:00
|
|
|
{
|
|
|
|
char *caller_chan_id = NULL, *callee_chan_id = NULL, *args = NULL, *touch_filename = NULL;
|
|
|
|
int x = 0;
|
|
|
|
size_t len;
|
|
|
|
struct ast_channel *caller_chan, *callee_chan;
|
|
|
|
const char *mixmonitor_spy_type = "MixMonitor";
|
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
if (!mixmonitor_ok) {
|
|
|
|
ast_log(LOG_ERROR,"Cannot record the call. The mixmonitor application is disabled.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(mixmonitor_app = pbx_findapp("MixMonitor"))) {
|
|
|
|
mixmonitor_ok = 0;
|
|
|
|
ast_log(LOG_ERROR,"Cannot record the call. The mixmonitor application is disabled.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
set_peers(&caller_chan, &callee_chan, peer, chan, sense);
|
|
|
|
|
|
|
|
if (!ast_strlen_zero(courtesytone)) {
|
|
|
|
if (ast_autoservice_start(callee_chan))
|
|
|
|
return -1;
|
2010-07-20 22:26:23 +00:00
|
|
|
ast_autoservice_ignore(callee_chan, AST_FRAME_DTMF_END);
|
2007-11-30 21:19:57 +00:00
|
|
|
if (ast_stream_and_wait(caller_chan, courtesytone, "")) {
|
|
|
|
ast_log(LOG_WARNING, "Failed to play courtesy tone!\n");
|
|
|
|
ast_autoservice_stop(callee_chan);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (ast_autoservice_stop(callee_chan))
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_channel_lock(callee_chan);
|
|
|
|
count = ast_channel_audiohook_count_by_source(callee_chan, mixmonitor_spy_type, AST_AUDIOHOOK_TYPE_SPY);
|
|
|
|
ast_channel_unlock(callee_chan);
|
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/* This means a mixmonitor is attached to the channel, running or not is unknown. */
|
2007-11-30 21:19:57 +00:00
|
|
|
if (count > 0) {
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2007-12-14 14:48:38 +00:00
|
|
|
ast_verb(3, "User hit '%s' to stop recording call.\n", code);
|
2007-11-30 21:19:57 +00:00
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/* Make sure they are running */
|
2007-11-30 21:19:57 +00:00
|
|
|
ast_channel_lock(callee_chan);
|
|
|
|
count = ast_channel_audiohook_count_by_source_running(callee_chan, mixmonitor_spy_type, AST_AUDIOHOOK_TYPE_SPY);
|
|
|
|
ast_channel_unlock(callee_chan);
|
|
|
|
if (count > 0) {
|
|
|
|
if (!stopmixmonitor_ok) {
|
|
|
|
ast_log(LOG_ERROR,"Cannot stop recording the call. The stopmixmonitor application is disabled.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (!(stopmixmonitor_app = pbx_findapp("StopMixMonitor"))) {
|
|
|
|
stopmixmonitor_ok = 0;
|
|
|
|
ast_log(LOG_ERROR,"Cannot stop recording the call. The stopmixmonitor application is disabled.\n");
|
|
|
|
return -1;
|
|
|
|
} else {
|
|
|
|
pbx_exec(callee_chan, stopmixmonitor_app, "");
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2007-11-30 21:19:57 +00:00
|
|
|
}
|
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
|
|
|
ast_log(LOG_WARNING,"Stopped MixMonitors are attached to the channel.\n");
|
|
|
|
}
|
2007-11-30 21:19:57 +00:00
|
|
|
|
|
|
|
if (caller_chan && callee_chan) {
|
|
|
|
const char *touch_format = pbx_builtin_getvar_helper(caller_chan, "TOUCH_MIXMONITOR_FORMAT");
|
|
|
|
const char *touch_monitor = pbx_builtin_getvar_helper(caller_chan, "TOUCH_MIXMONITOR");
|
|
|
|
|
|
|
|
if (!touch_format)
|
|
|
|
touch_format = pbx_builtin_getvar_helper(callee_chan, "TOUCH_MIXMONITOR_FORMAT");
|
|
|
|
|
|
|
|
if (!touch_monitor)
|
|
|
|
touch_monitor = pbx_builtin_getvar_helper(callee_chan, "TOUCH_MIXMONITOR");
|
|
|
|
|
|
|
|
if (touch_monitor) {
|
|
|
|
len = strlen(touch_monitor) + 50;
|
|
|
|
args = alloca(len);
|
|
|
|
touch_filename = alloca(len);
|
|
|
|
snprintf(touch_filename, len, "auto-%ld-%s", (long)time(NULL), touch_monitor);
|
|
|
|
snprintf(args, len, "%s.%s,b", touch_filename, (touch_format) ? touch_format : "wav");
|
|
|
|
} else {
|
2012-02-29 16:52:47 +00:00
|
|
|
caller_chan_id = ast_strdupa(S_COR(ast_channel_caller(caller_chan)->id.number.valid,
|
|
|
|
ast_channel_caller(caller_chan)->id.number.str, ast_channel_name(caller_chan)));
|
|
|
|
callee_chan_id = ast_strdupa(S_COR(ast_channel_caller(callee_chan)->id.number.valid,
|
|
|
|
ast_channel_caller(callee_chan)->id.number.str, ast_channel_name(callee_chan)));
|
2007-11-30 21:19:57 +00:00
|
|
|
len = strlen(caller_chan_id) + strlen(callee_chan_id) + 50;
|
|
|
|
args = alloca(len);
|
|
|
|
touch_filename = alloca(len);
|
|
|
|
snprintf(touch_filename, len, "auto-%ld-%s-%s", (long)time(NULL), caller_chan_id, callee_chan_id);
|
|
|
|
snprintf(args, len, "%s.%s,b", touch_filename, S_OR(touch_format, "wav"));
|
|
|
|
}
|
|
|
|
|
|
|
|
for( x = 0; x < strlen(args); x++) {
|
|
|
|
if (args[x] == '/')
|
|
|
|
args[x] = '-';
|
|
|
|
}
|
|
|
|
|
2007-12-14 14:48:38 +00:00
|
|
|
ast_verb(3, "User hit '%s' to record call. filename: %s\n", code, touch_filename);
|
2007-11-30 21:19:57 +00:00
|
|
|
|
|
|
|
pbx_exec(callee_chan, mixmonitor_app, args);
|
|
|
|
pbx_builtin_setvar_helper(callee_chan, "TOUCH_MIXMONITOR_OUTPUT", touch_filename);
|
|
|
|
pbx_builtin_setvar_helper(caller_chan, "TOUCH_MIXMONITOR_OUTPUT", touch_filename);
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2007-11-30 21:19:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ast_log(LOG_NOTICE,"Cannot record the call. One or both channels have gone away.\n");
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
static int builtin_disconnect(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense, void *data)
|
2005-01-04 04:01:40 +00:00
|
|
|
{
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(4, "User hit '%s' to disconnect call.\n", code);
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_HANGUP;
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief Find the context for the transfer
|
|
|
|
* \param transferer
|
|
|
|
* \param transferee
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Grab the TRANSFER_CONTEXT, if fails try grabbing macrocontext.
|
|
|
|
* \return a context string
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2006-04-16 19:26:57 +00:00
|
|
|
static const char *real_ctx(struct ast_channel *transferer, struct ast_channel *transferee)
|
|
|
|
{
|
2008-03-04 23:04:29 +00:00
|
|
|
const char *s = pbx_builtin_getvar_helper(transferer, "TRANSFER_CONTEXT");
|
|
|
|
if (ast_strlen_zero(s)) {
|
|
|
|
s = pbx_builtin_getvar_helper(transferee, "TRANSFER_CONTEXT");
|
|
|
|
}
|
|
|
|
if (ast_strlen_zero(s)) { /* Use the non-macro context to transfer the call XXX ? */
|
2012-02-13 17:27:06 +00:00
|
|
|
s = ast_channel_macrocontext(transferer);
|
2008-03-04 23:04:29 +00:00
|
|
|
}
|
|
|
|
if (ast_strlen_zero(s)) {
|
2012-02-13 17:27:06 +00:00
|
|
|
s = ast_channel_context(transferer);
|
2008-03-04 23:04:29 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
return s;
|
2006-04-16 19:26:57 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief Blind transfer user to another extension
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param chan channel to be transfered
|
|
|
|
* \param peer channel initiated blind transfer
|
2007-08-07 23:04:01 +00:00
|
|
|
* \param config
|
|
|
|
* \param code
|
2007-08-23 20:20:17 +00:00
|
|
|
* \param data
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param sense feature options
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2007-09-05 16:31:39 +00:00
|
|
|
* Place chan on hold, check if transferred to parkinglot extension,
|
2007-08-07 23:04:01 +00:00
|
|
|
* otherwise check extension exists and transfer caller.
|
2008-04-08 17:32:42 +00:00
|
|
|
* \retval AST_FEATURE_RETURN_SUCCESS.
|
2007-08-07 23:04:01 +00:00
|
|
|
* \retval -1 on failure.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2009-05-21 21:13:09 +00:00
|
|
|
static int builtin_blindtransfer(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense, void *data)
|
2005-01-04 04:01:40 +00:00
|
|
|
{
|
|
|
|
struct ast_channel *transferer;
|
|
|
|
struct ast_channel *transferee;
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_exten *park_exten;
|
2005-12-03 19:25:33 +00:00
|
|
|
const char *transferer_real_context;
|
2011-08-16 17:23:08 +00:00
|
|
|
char xferto[256] = "";
|
|
|
|
int res;
|
2005-01-04 04:01:40 +00:00
|
|
|
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(1, "Executing Blind Transfer %s, %s (sense=%d) \n", ast_channel_name(chan), ast_channel_name(peer), sense);
|
2006-04-16 19:26:57 +00:00
|
|
|
set_peers(&transferer, &transferee, peer, chan, sense);
|
|
|
|
transferer_real_context = real_ctx(transferer, transferee);
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
/* Start autoservice on transferee while we talk to the transferer */
|
2005-01-04 04:01:40 +00:00
|
|
|
ast_autoservice_start(transferee);
|
2006-07-19 20:44:39 +00:00
|
|
|
ast_indicate(transferee, AST_CONTROL_HOLD);
|
2005-01-04 04:01:40 +00:00
|
|
|
|
|
|
|
/* Transfer */
|
2006-11-17 23:18:51 +00:00
|
|
|
res = ast_stream_and_wait(transferer, "pbx-transfer", AST_DIGIT_ANY);
|
2006-04-16 21:41:06 +00:00
|
|
|
if (res < 0) {
|
|
|
|
finishup(transferee);
|
|
|
|
return -1; /* error ? */
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (res > 0) { /* If they've typed a digit already, handle it */
|
2006-04-18 13:05:48 +00:00
|
|
|
xferto[0] = (char) res;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2005-01-04 04:01:40 +00:00
|
|
|
|
2006-04-16 19:56:08 +00:00
|
|
|
res = ast_app_dtget(transferer, transferer_real_context, xferto, sizeof(xferto), 100, transferdigittimeout);
|
2011-01-19 21:35:28 +00:00
|
|
|
if (res < 0) { /* hangup or error, (would be 0 for invalid and 1 for valid) */
|
2006-04-16 21:41:06 +00:00
|
|
|
finishup(transferee);
|
2011-01-19 21:35:28 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (res == 0) {
|
|
|
|
if (xferto[0]) {
|
|
|
|
ast_log(LOG_WARNING, "Extension '%s' does not exist in context '%s'\n",
|
|
|
|
xferto, transferer_real_context);
|
|
|
|
} else {
|
|
|
|
/* Does anyone care about this case? */
|
|
|
|
ast_log(LOG_WARNING, "No digits dialed.\n");
|
|
|
|
}
|
|
|
|
ast_stream_and_wait(transferer, "pbx-invalid", "");
|
|
|
|
finishup(transferee);
|
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
2010-09-15 19:23:56 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
park_exten = get_parking_exten(xferto, transferer, transferer_real_context);
|
|
|
|
if (park_exten) {
|
|
|
|
/* We are transfering the transferee to a parking lot. */
|
|
|
|
return xfer_park_call_helper(transferee, transferer, park_exten);
|
|
|
|
}
|
2007-11-21 15:17:12 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Do blind transfer. */
|
2011-10-13 23:08:48 +00:00
|
|
|
ast_verb(3, "Blind transferring %s to '%s' (context %s) priority 1\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(transferee), xferto, transferer_real_context);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_cel_report_event(transferer, AST_CEL_BLINDTRANSFER, NULL, xferto, transferee);
|
2012-01-09 22:15:50 +00:00
|
|
|
pbx_builtin_setvar_helper(transferer, "BLINDTRANSFER", ast_channel_name(transferee));
|
|
|
|
pbx_builtin_setvar_helper(transferee, "BLINDTRANSFER", ast_channel_name(transferer));
|
2011-10-13 23:08:48 +00:00
|
|
|
finishup(transferee);
|
2011-12-16 21:10:19 +00:00
|
|
|
ast_channel_lock(transferer);
|
2012-02-20 23:43:27 +00:00
|
|
|
if (!ast_channel_cdr(transferer)) { /* this code should never get called (in a perfect world) */
|
|
|
|
ast_channel_cdr_set(transferer, ast_cdr_alloc());
|
|
|
|
if (ast_channel_cdr(transferer)) {
|
|
|
|
ast_cdr_init(ast_channel_cdr(transferer), transferer); /* initialize our channel's cdr */
|
|
|
|
ast_cdr_start(ast_channel_cdr(transferer));
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
}
|
2011-12-16 21:10:19 +00:00
|
|
|
ast_channel_unlock(transferer);
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_cdr(transferer)) {
|
|
|
|
struct ast_cdr *swap = ast_channel_cdr(transferer);
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
ast_debug(1,
|
|
|
|
"transferer=%s; transferee=%s; lastapp=%s; lastdata=%s; chan=%s; dstchan=%s\n",
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_name(transferer), ast_channel_name(transferee), ast_channel_cdr(transferer)->lastapp,
|
|
|
|
ast_channel_cdr(transferer)->lastdata, ast_channel_cdr(transferer)->channel,
|
|
|
|
ast_channel_cdr(transferer)->dstchannel);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(1, "TRANSFEREE; lastapp=%s; lastdata=%s, chan=%s; dstchan=%s\n",
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_cdr(transferee)->lastapp, ast_channel_cdr(transferee)->lastdata, ast_channel_cdr(transferee)->channel,
|
|
|
|
ast_channel_cdr(transferee)->dstchannel);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(1, "transferer_real_context=%s; xferto=%s\n",
|
|
|
|
transferer_real_context, xferto);
|
|
|
|
/* swap cdrs-- it will save us some time & work */
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_cdr_set(transferer, ast_channel_cdr(transferee));
|
|
|
|
ast_channel_cdr_set(transferee, swap);
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2012-02-20 23:43:27 +00:00
|
|
|
if (!ast_channel_pbx(transferee)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Doh! Use our handy async_goto functions */
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(1, "About to ast_async_goto %s.\n", ast_channel_name(transferee));
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_async_goto(transferee, transferer_real_context, xferto, 1)) {
|
|
|
|
ast_log(LOG_WARNING, "Async goto failed :-(\n");
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
2011-10-13 23:08:48 +00:00
|
|
|
|
|
|
|
/* The transferee is masqueraded and the original bridged channels can be hungup. */
|
|
|
|
res = -1;
|
2011-01-19 21:35:28 +00:00
|
|
|
} else {
|
2011-10-13 23:08:48 +00:00
|
|
|
/* Set the transferee's new extension, since it exists, using transferer context */
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(1, "About to explicit goto %s, it has a PBX.\n", ast_channel_name(transferee));
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_set_flag(ast_channel_flags(transferee), AST_FLAG_BRIDGE_HANGUP_DONT); /* don't let the after-bridge code run the h-exten */
|
2011-08-16 17:23:08 +00:00
|
|
|
set_c_e_p(transferee, transferer_real_context, xferto, 0);
|
2011-10-13 23:08:48 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Break the bridge. The transferee needs to resume executing
|
|
|
|
* dialplan at the xferto location.
|
|
|
|
*/
|
|
|
|
res = AST_FEATURE_RETURN_SUCCESSBREAK;
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
check_goto_on_transfer(transferer);
|
|
|
|
return res;
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief make channels compatible
|
|
|
|
* \param c
|
|
|
|
* \param newchan
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on failure.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2006-04-18 13:05:48 +00:00
|
|
|
static int check_compat(struct ast_channel *c, struct ast_channel *newchan)
|
|
|
|
{
|
|
|
|
if (ast_channel_make_compatible(c, newchan) < 0) {
|
|
|
|
ast_log(LOG_WARNING, "Had to drop call because I couldn't make %s compatible with %s\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(c), ast_channel_name(newchan));
|
2006-04-18 13:05:48 +00:00
|
|
|
ast_hangup(newchan);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Builtin attended transfer failed cleanup.
|
2011-07-21 20:26:44 +00:00
|
|
|
* \since 10.0
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
*
|
|
|
|
* \param transferee Party A in the transfer.
|
|
|
|
* \param transferer Party B in the transfer.
|
|
|
|
* \param connected_line Saved connected line info about party A.
|
|
|
|
*
|
|
|
|
* \note The connected_line data is freed.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void atxfer_fail_cleanup(struct ast_channel *transferee, struct ast_channel *transferer, struct ast_party_connected_line *connected_line)
|
|
|
|
{
|
|
|
|
finishup(transferee);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Restore party B connected line info about party A.
|
|
|
|
*
|
|
|
|
* Party B was the caller to party C and is the last known mode
|
|
|
|
* for party B.
|
|
|
|
*/
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(transferee, transferer, connected_line, 0) &&
|
|
|
|
ast_channel_connected_line_macro(transferee, transferer, connected_line, 1, 0)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_update_connected_line(transferer, connected_line, NULL);
|
|
|
|
}
|
|
|
|
ast_party_connected_line_free(connected_line);
|
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief Attended transfer
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param chan transfered user
|
|
|
|
* \param peer person transfering call
|
2007-08-07 23:04:01 +00:00
|
|
|
* \param config
|
|
|
|
* \param code
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param sense feature options
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
*
|
2007-08-23 20:20:17 +00:00
|
|
|
* \param data
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
* Get extension to transfer to, if you cannot generate channel (or find extension)
|
2007-08-07 23:04:01 +00:00
|
|
|
* return to host channel. After called channel answered wait for hangup of transferer,
|
|
|
|
* bridge call between transfer peer (taking them off hold) to attended transfer channel.
|
2007-09-05 16:31:39 +00:00
|
|
|
*
|
|
|
|
* \return -1 on failure
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2009-05-21 21:13:09 +00:00
|
|
|
static int builtin_atxfer(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense, void *data)
|
2005-01-05 19:56:47 +00:00
|
|
|
{
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
struct ast_channel *transferer;/* Party B */
|
|
|
|
struct ast_channel *transferee;/* Party A */
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_exten *park_exten;
|
2005-12-03 19:25:33 +00:00
|
|
|
const char *transferer_real_context;
|
2006-07-19 20:44:39 +00:00
|
|
|
char xferto[256] = "";
|
2005-01-05 19:56:47 +00:00
|
|
|
int res;
|
2006-04-18 13:05:48 +00:00
|
|
|
int outstate=0;
|
|
|
|
struct ast_channel *newchan;
|
|
|
|
struct ast_channel *xferchan;
|
2005-01-05 19:56:47 +00:00
|
|
|
struct ast_bridge_thread_obj *tobj;
|
2006-04-18 13:05:48 +00:00
|
|
|
struct ast_bridge_config bconfig;
|
|
|
|
int l;
|
2009-05-05 20:54:07 +00:00
|
|
|
struct ast_party_connected_line connected_line;
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
struct ast_datastore *features_datastore;
|
2012-04-25 01:26:44 +00:00
|
|
|
struct ast_dial_features *dialfeatures;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
char *transferer_tech;
|
|
|
|
char *transferer_name;
|
|
|
|
char *transferer_name_orig;
|
|
|
|
char *dash;
|
2005-01-05 19:56:47 +00:00
|
|
|
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(1, "Executing Attended Transfer %s, %s (sense=%d) \n", ast_channel_name(chan), ast_channel_name(peer), sense);
|
2006-04-16 19:26:57 +00:00
|
|
|
set_peers(&transferer, &transferee, peer, chan, sense);
|
2008-03-04 23:04:29 +00:00
|
|
|
transferer_real_context = real_ctx(transferer, transferee);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
|
|
|
/* Start autoservice on transferee while we talk to the transferer */
|
2005-01-05 19:56:47 +00:00
|
|
|
ast_autoservice_start(transferee);
|
2006-07-19 20:44:39 +00:00
|
|
|
ast_indicate(transferee, AST_CONTROL_HOLD);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
2005-01-05 19:56:47 +00:00
|
|
|
/* Transfer */
|
2006-11-17 23:18:51 +00:00
|
|
|
res = ast_stream_and_wait(transferer, "pbx-transfer", AST_DIGIT_ANY);
|
2006-04-16 22:22:53 +00:00
|
|
|
if (res < 0) {
|
|
|
|
finishup(transferee);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
return -1;
|
2006-04-18 13:05:48 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (res > 0) { /* If they've typed a digit already, handle it */
|
2006-04-16 22:22:53 +00:00
|
|
|
xferto[0] = (char) res;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2006-04-16 19:26:57 +00:00
|
|
|
|
2006-04-16 22:22:53 +00:00
|
|
|
/* this is specific of atxfer */
|
|
|
|
res = ast_app_dtget(transferer, transferer_real_context, xferto, sizeof(xferto), 100, transferdigittimeout);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (res < 0) { /* hangup or error, (would be 0 for invalid and 1 for valid) */
|
2008-03-04 23:04:29 +00:00
|
|
|
finishup(transferee);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
return -1;
|
2008-03-04 23:04:29 +00:00
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
l = strlen(xferto);
|
2006-04-16 23:05:42 +00:00
|
|
|
if (res == 0) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (l) {
|
|
|
|
ast_log(LOG_WARNING, "Extension '%s' does not exist in context '%s'\n",
|
|
|
|
xferto, transferer_real_context);
|
|
|
|
} else {
|
|
|
|
/* Does anyone care about this case? */
|
|
|
|
ast_log(LOG_WARNING, "No digits dialed for atxfer.\n");
|
|
|
|
}
|
|
|
|
ast_stream_and_wait(transferer, "pbx-invalid", "");
|
2006-04-18 13:05:48 +00:00
|
|
|
finishup(transferee);
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2006-04-18 13:05:48 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
park_exten = get_parking_exten(xferto, transferer, transferer_real_context);
|
|
|
|
if (park_exten) {
|
|
|
|
/* We are transfering the transferee to a parking lot. */
|
|
|
|
return xfer_park_call_helper(transferee, transferer, park_exten);
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
|
2012-04-25 01:26:44 +00:00
|
|
|
/*
|
|
|
|
* Append context to dialed transfer number.
|
|
|
|
*
|
|
|
|
* NOTE: The local channel needs the /n flag so party C will use
|
|
|
|
* the feature flags set by the dialplan when calling that
|
|
|
|
* party.
|
|
|
|
*/
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
snprintf(xferto + l, sizeof(xferto) - l, "@%s/n", transferer_real_context);
|
2008-07-30 16:40:43 +00:00
|
|
|
|
|
|
|
/* If we are performing an attended transfer and we have two channels involved then
|
|
|
|
copy sound file information to play upon attended transfer completion */
|
|
|
|
if (transferee) {
|
|
|
|
const char *chan1_attended_sound = pbx_builtin_getvar_helper(transferer, "ATTENDED_TRANSFER_COMPLETE_SOUND");
|
|
|
|
const char *chan2_attended_sound = pbx_builtin_getvar_helper(transferee, "ATTENDED_TRANSFER_COMPLETE_SOUND");
|
|
|
|
|
|
|
|
if (!ast_strlen_zero(chan1_attended_sound)) {
|
|
|
|
pbx_builtin_setvar_helper(transferer, "BRIDGE_PLAY_SOUND", chan1_attended_sound);
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(chan2_attended_sound)) {
|
|
|
|
pbx_builtin_setvar_helper(transferee, "BRIDGE_PLAY_SOUND", chan2_attended_sound);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/* Extract redial transferer information from the channel name. */
|
2012-01-09 22:15:50 +00:00
|
|
|
transferer_name_orig = ast_strdupa(ast_channel_name(transferer));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
transferer_name = ast_strdupa(transferer_name_orig);
|
|
|
|
transferer_tech = strsep(&transferer_name, "/");
|
|
|
|
dash = strrchr(transferer_name, '-');
|
|
|
|
if (dash) {
|
|
|
|
/* Trim off channel name sequence/serial number. */
|
|
|
|
*dash = '\0';
|
|
|
|
}
|
2007-05-01 22:24:51 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/* Stop autoservice so we can monitor all parties involved in the transfer. */
|
|
|
|
if (ast_autoservice_stop(transferee) < 0) {
|
|
|
|
ast_indicate(transferee, AST_CONTROL_UNHOLD);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Save connected line info for party B about party A in case transfer fails. */
|
2009-05-05 20:54:07 +00:00
|
|
|
ast_party_connected_line_init(&connected_line);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_lock(transferer);
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_party_connected_line_copy(&connected_line, ast_channel_connected(transferer));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_unlock(transferer);
|
|
|
|
connected_line.source = AST_CONNECTED_LINE_UPDATE_SOURCE_TRANSFER;
|
|
|
|
|
|
|
|
/* Dial party C */
|
|
|
|
newchan = feature_request_and_dial(transferer, transferer_name_orig, transferer,
|
2012-02-20 23:43:27 +00:00
|
|
|
transferee, "Local", ast_channel_nativeformats(transferer), xferto,
|
2012-01-24 20:12:09 +00:00
|
|
|
atxfernoanswertimeout, &outstate, ast_channel_language(transferer));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_debug(2, "Dial party C result: newchan:%d, outstate:%d\n", !!newchan, outstate);
|
|
|
|
|
2007-05-01 22:24:51 +00:00
|
|
|
if (!ast_check_hangup(transferer)) {
|
2010-07-16 23:23:15 +00:00
|
|
|
int hangup_dont = 0;
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/* Transferer (party B) is up */
|
|
|
|
ast_debug(1, "Actually doing an attended transfer.\n");
|
|
|
|
|
|
|
|
/* Start autoservice on transferee while the transferer deals with party C. */
|
|
|
|
ast_autoservice_start(transferee);
|
|
|
|
|
2007-05-01 22:24:51 +00:00
|
|
|
ast_indicate(transferer, -1);
|
|
|
|
if (!newchan) {
|
|
|
|
/* any reason besides user requested cancel and busy triggers the failed sound */
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
switch (outstate) {
|
|
|
|
case AST_CONTROL_UNHOLD:/* Caller requested cancel or party C answer timeout. */
|
|
|
|
case AST_CONTROL_BUSY:
|
|
|
|
case AST_CONTROL_CONGESTION:
|
|
|
|
if (ast_stream_and_wait(transferer, xfersound, "")) {
|
|
|
|
ast_log(LOG_WARNING, "Failed to play transfer sound!\n");
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
if (ast_stream_and_wait(transferer, xferfailsound, "")) {
|
|
|
|
ast_log(LOG_WARNING, "Failed to play transfer failed sound!\n");
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
atxfer_fail_cleanup(transferee, transferer, &connected_line);
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2007-05-01 22:24:51 +00:00
|
|
|
}
|
|
|
|
|
2007-10-02 18:59:39 +00:00
|
|
|
if (check_compat(transferer, newchan)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (ast_stream_and_wait(transferer, xferfailsound, "")) {
|
|
|
|
ast_log(LOG_WARNING, "Failed to play transfer failed sound!\n");
|
|
|
|
}
|
|
|
|
atxfer_fail_cleanup(transferee, transferer, &connected_line);
|
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2007-10-02 18:59:39 +00:00
|
|
|
}
|
2007-05-01 22:24:51 +00:00
|
|
|
memset(&bconfig,0,sizeof(struct ast_bridge_config));
|
|
|
|
ast_set_flag(&(bconfig.features_caller), AST_FEATURE_DISCONNECT);
|
|
|
|
ast_set_flag(&(bconfig.features_callee), AST_FEATURE_DISCONNECT);
|
2010-07-16 23:23:15 +00:00
|
|
|
|
2012-04-26 20:35:41 +00:00
|
|
|
/*
|
|
|
|
* ast_bridge_call clears AST_FLAG_BRIDGE_HANGUP_DONT, but we
|
|
|
|
* don't want that to happen here because the transferer is in
|
|
|
|
* another bridge already.
|
2010-07-16 23:23:15 +00:00
|
|
|
*/
|
2012-04-26 20:35:41 +00:00
|
|
|
if (ast_test_flag(ast_channel_flags(transferer), AST_FLAG_BRIDGE_HANGUP_DONT)) {
|
2010-07-16 23:23:15 +00:00
|
|
|
hangup_dont = 1;
|
|
|
|
}
|
2012-04-26 20:35:41 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't let the after-bridge code run the h-exten. It is the
|
|
|
|
* wrong bridge to run the h-exten after.
|
|
|
|
*/
|
|
|
|
ast_set_flag(ast_channel_flags(transferer), AST_FLAG_BRIDGE_HANGUP_DONT);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Let party B and C talk as long as they want while party A
|
|
|
|
* languishes in autoservice listening to MOH.
|
|
|
|
*/
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_bridge_call(transferer, newchan, &bconfig);
|
2012-04-26 20:35:41 +00:00
|
|
|
|
2010-07-16 23:23:15 +00:00
|
|
|
if (hangup_dont) {
|
2012-04-26 20:35:41 +00:00
|
|
|
/* Restore the AST_FLAG_BRIDGE_HANGUP_DONT flag */
|
|
|
|
ast_set_flag(ast_channel_flags(transferer), AST_FLAG_BRIDGE_HANGUP_DONT);
|
2010-07-16 23:23:15 +00:00
|
|
|
}
|
|
|
|
|
2007-08-01 15:39:54 +00:00
|
|
|
if (ast_check_hangup(newchan) || !ast_check_hangup(transferer)) {
|
2007-05-01 22:24:51 +00:00
|
|
|
ast_hangup(newchan);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (ast_stream_and_wait(transferer, xfersound, "")) {
|
2007-05-01 22:24:51 +00:00
|
|
|
ast_log(LOG_WARNING, "Failed to play transfer sound!\n");
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
}
|
|
|
|
atxfer_fail_cleanup(transferee, transferer, &connected_line);
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS;
|
2007-05-01 22:24:51 +00:00
|
|
|
}
|
2009-06-26 15:28:53 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/* Transferer (party B) is confirmed hung up at this point. */
|
2007-10-02 18:59:39 +00:00
|
|
|
if (check_compat(transferee, newchan)) {
|
|
|
|
finishup(transferee);
|
2009-04-03 22:41:46 +00:00
|
|
|
ast_party_connected_line_free(&connected_line);
|
2007-05-01 22:24:51 +00:00
|
|
|
return -1;
|
2007-10-02 18:59:39 +00:00
|
|
|
}
|
2007-05-01 22:24:51 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_indicate(transferee, AST_CONTROL_UNHOLD);
|
2007-05-01 22:24:51 +00:00
|
|
|
if ((ast_autoservice_stop(transferee) < 0)
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|| (ast_waitfordigit(transferee, 100) < 0)
|
|
|
|
|| (ast_waitfordigit(newchan, 100) < 0)
|
|
|
|
|| ast_check_hangup(transferee)
|
|
|
|
|| ast_check_hangup(newchan)) {
|
2007-05-01 22:24:51 +00:00
|
|
|
ast_hangup(newchan);
|
2009-04-03 22:41:46 +00:00
|
|
|
ast_party_connected_line_free(&connected_line);
|
2007-05-01 22:24:51 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else if (!ast_check_hangup(transferee)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/* Transferer (party B) has hung up at this point. Doing blonde transfer. */
|
|
|
|
ast_debug(1, "Actually doing a blonde transfer.\n");
|
2006-04-18 13:05:48 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (!newchan && !atxferdropcall) {
|
|
|
|
/* Party C is not available, try to call party B back. */
|
2007-05-01 22:24:51 +00:00
|
|
|
unsigned int tries = 0;
|
2007-11-06 20:32:49 +00:00
|
|
|
|
|
|
|
if (ast_strlen_zero(transferer_name) || ast_strlen_zero(transferer_tech)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Transferer channel name: '%s' cannot be used for callback.\n",
|
|
|
|
transferer_name_orig);
|
|
|
|
ast_indicate(transferee, AST_CONTROL_UNHOLD);
|
|
|
|
ast_party_connected_line_free(&connected_line);
|
|
|
|
return -1;
|
2007-05-01 22:24:51 +00:00
|
|
|
}
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
tries = 0;
|
|
|
|
for (;;) {
|
|
|
|
/* Try to get party B back. */
|
|
|
|
ast_debug(1, "We're trying to callback %s/%s\n",
|
|
|
|
transferer_tech, transferer_name);
|
|
|
|
newchan = feature_request_and_dial(transferer, transferer_name_orig,
|
|
|
|
transferee, transferee, transferer_tech,
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_nativeformats(transferee), transferer_name,
|
2012-01-24 20:12:09 +00:00
|
|
|
atxfernoanswertimeout, &outstate, ast_channel_language(transferer));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_debug(2, "Dial party B result: newchan:%d, outstate:%d\n",
|
|
|
|
!!newchan, outstate);
|
2012-04-25 01:26:44 +00:00
|
|
|
if (newchan) {
|
|
|
|
/*
|
|
|
|
* We have recalled party B (newchan). We need to give this
|
|
|
|
* call leg the same feature flags as the original party B call
|
|
|
|
* leg.
|
|
|
|
*/
|
|
|
|
ast_channel_lock(transferer);
|
|
|
|
features_datastore = ast_channel_datastore_find(transferer,
|
|
|
|
&dial_features_info, NULL);
|
|
|
|
if (features_datastore && (dialfeatures = features_datastore->data)) {
|
|
|
|
struct ast_flags my_features = { 0 };
|
|
|
|
struct ast_flags peer_features = { 0 };
|
|
|
|
|
|
|
|
ast_copy_flags(&my_features, &dialfeatures->my_features,
|
|
|
|
AST_FLAGS_ALL);
|
|
|
|
ast_copy_flags(&peer_features, &dialfeatures->peer_features,
|
|
|
|
AST_FLAGS_ALL);
|
|
|
|
ast_channel_unlock(transferer);
|
|
|
|
add_features_datastore(newchan, &my_features, &peer_features);
|
|
|
|
} else {
|
|
|
|
ast_channel_unlock(transferer);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (ast_check_hangup(transferee)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
break;
|
|
|
|
}
|
2011-08-09 23:17:13 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
++tries;
|
|
|
|
if (atxfercallbackretries <= tries) {
|
|
|
|
/* No more callback tries remaining. */
|
|
|
|
break;
|
2007-05-01 22:24:51 +00:00
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
|
|
|
if (atxferloopdelay) {
|
2007-05-01 22:24:51 +00:00
|
|
|
/* Transfer failed, sleeping */
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_debug(1, "Sleeping for %d ms before retrying atxfer.\n",
|
|
|
|
atxferloopdelay);
|
2007-05-01 22:24:51 +00:00
|
|
|
ast_safe_sleep(transferee, atxferloopdelay);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (ast_check_hangup(transferee)) {
|
|
|
|
ast_party_connected_line_free(&connected_line);
|
|
|
|
return -1;
|
|
|
|
}
|
2007-05-01 22:24:51 +00:00
|
|
|
}
|
2006-04-18 13:05:48 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/* Retry dialing party C. */
|
|
|
|
ast_debug(1, "We're retrying to call %s/%s\n", "Local", xferto);
|
|
|
|
newchan = feature_request_and_dial(transferer, transferer_name_orig,
|
|
|
|
transferer, transferee, "Local",
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_nativeformats(transferee), xferto,
|
2012-01-24 20:12:09 +00:00
|
|
|
atxfernoanswertimeout, &outstate, ast_channel_language(transferer));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_debug(2, "Redial party C result: newchan:%d, outstate:%d\n",
|
|
|
|
!!newchan, outstate);
|
|
|
|
if (newchan || ast_check_hangup(transferee)) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2007-10-02 18:59:39 +00:00
|
|
|
}
|
2007-05-01 22:24:51 +00:00
|
|
|
ast_indicate(transferee, AST_CONTROL_UNHOLD);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (!newchan) {
|
|
|
|
/* No party C or could not callback party B. */
|
|
|
|
ast_party_connected_line_free(&connected_line);
|
2007-05-01 22:24:51 +00:00
|
|
|
return -1;
|
|
|
|
}
|
2006-04-18 13:05:48 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/* newchan is up, we should prepare transferee and bridge them */
|
|
|
|
if (ast_check_hangup(newchan)) {
|
2007-05-01 22:24:51 +00:00
|
|
|
ast_hangup(newchan);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_party_connected_line_free(&connected_line);
|
2007-05-01 22:24:51 +00:00
|
|
|
return -1;
|
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (check_compat(transferee, newchan)) {
|
|
|
|
ast_party_connected_line_free(&connected_line);
|
2007-05-01 22:24:51 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/*
|
|
|
|
* Both the transferer and transferee have hungup. If newchan
|
|
|
|
* is up, hang it up as it has no one to talk to.
|
|
|
|
*/
|
|
|
|
ast_debug(1, "Everyone is hungup.\n");
|
2010-06-22 15:46:22 +00:00
|
|
|
if (newchan) {
|
|
|
|
ast_hangup(newchan);
|
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_party_connected_line_free(&connected_line);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Initiate the channel transfer of party A to party C (or recalled party B). */
|
|
|
|
ast_cel_report_event(transferee, AST_CEL_ATTENDEDTRANSFER, NULL, NULL, newchan);
|
|
|
|
|
2012-01-24 20:12:09 +00:00
|
|
|
xferchan = ast_channel_alloc(0, AST_STATE_DOWN, 0, 0, "", "", "", ast_channel_linkedid(transferee), 0, "Transfered/%s", ast_channel_name(transferee));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (!xferchan) {
|
|
|
|
ast_hangup(newchan);
|
|
|
|
ast_party_connected_line_free(&connected_line);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Give party A a momentary ringback tone during transfer. */
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_visible_indication_set(xferchan, AST_CONTROL_RINGING);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
|
|
|
/* Make formats okay */
|
2012-02-24 00:32:20 +00:00
|
|
|
ast_format_copy(ast_channel_readformat(xferchan), ast_channel_readformat(transferee));
|
|
|
|
ast_format_copy(ast_channel_writeformat(xferchan), ast_channel_writeformat(transferee));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
|
|
|
ast_channel_masquerade(xferchan, transferee);
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_explicit_goto(xferchan, ast_channel_context(transferee), ast_channel_exten(transferee), ast_channel_priority(transferee));
|
|
|
|
ast_channel_state_set(xferchan, AST_STATE_UP);
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_clear_flag(ast_channel_flags(xferchan), AST_FLAGS_ALL);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
|
|
|
/* Do the masquerade manually to make sure that is is completed. */
|
|
|
|
ast_do_masquerade(xferchan);
|
|
|
|
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_state_set(newchan, AST_STATE_UP);
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_clear_flag(ast_channel_flags(newchan), AST_FLAGS_ALL);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
tobj = ast_calloc(1, sizeof(*tobj));
|
|
|
|
if (!tobj) {
|
|
|
|
ast_hangup(xferchan);
|
|
|
|
ast_hangup(newchan);
|
|
|
|
ast_party_connected_line_free(&connected_line);
|
2006-04-18 13:05:48 +00:00
|
|
|
return -1;
|
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
2012-04-25 01:26:44 +00:00
|
|
|
tobj->chan = newchan;
|
|
|
|
tobj->peer = xferchan;
|
|
|
|
tobj->bconfig = *config;
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_lock(newchan);
|
2012-04-25 01:26:44 +00:00
|
|
|
features_datastore = ast_channel_datastore_find(newchan, &dial_features_info, NULL);
|
|
|
|
if (features_datastore && (dialfeatures = features_datastore->data)) {
|
|
|
|
ast_copy_flags(&tobj->bconfig.features_callee, &dialfeatures->my_features,
|
|
|
|
AST_FLAGS_ALL);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
}
|
|
|
|
ast_channel_unlock(newchan);
|
|
|
|
|
|
|
|
ast_channel_lock(xferchan);
|
2012-04-25 01:26:44 +00:00
|
|
|
features_datastore = ast_channel_datastore_find(xferchan, &dial_features_info, NULL);
|
|
|
|
if (features_datastore && (dialfeatures = features_datastore->data)) {
|
|
|
|
ast_copy_flags(&tobj->bconfig.features_caller, &dialfeatures->my_features,
|
|
|
|
AST_FLAGS_ALL);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
}
|
|
|
|
ast_channel_unlock(xferchan);
|
|
|
|
|
|
|
|
if (tobj->bconfig.end_bridge_callback_data_fixup) {
|
|
|
|
tobj->bconfig.end_bridge_callback_data_fixup(&tobj->bconfig, tobj->peer, tobj->chan);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* xferchan is transferee, and newchan is the transfer target
|
|
|
|
* So...in a transfer, who is the caller and who is the callee?
|
|
|
|
*
|
|
|
|
* When the call is originally made, it is clear who is caller and callee.
|
|
|
|
* When a transfer occurs, it is my humble opinion that the transferee becomes
|
|
|
|
* the caller, and the transfer target is the callee.
|
|
|
|
*
|
|
|
|
* The problem is that these macros were set with the intention of the original
|
|
|
|
* caller and callee taking those roles. A transfer can totally mess things up,
|
|
|
|
* to be technical. What sucks even more is that you can't effectively change
|
|
|
|
* the macros in the dialplan during the call from the transferer to the transfer
|
|
|
|
* target because the transferee is stuck with whatever role he originally had.
|
|
|
|
*
|
|
|
|
* I think the answer here is just to make sure that it is well documented that
|
|
|
|
* during a transfer, the transferee is the "caller" and the transfer target
|
|
|
|
* is the "callee."
|
|
|
|
*
|
|
|
|
* This means that if party B calls party A, and party B transfers party A to
|
|
|
|
* party C, then A has switched roles for the call. Now party A will have the
|
|
|
|
* caller macro called on his channel instead of the callee macro.
|
|
|
|
*
|
|
|
|
* Luckily, the method by which the party B to party C bridge is
|
|
|
|
* launched above ensures that the transferee is the "chan" on
|
|
|
|
* the bridge and the transfer target is the "peer," so my idea
|
|
|
|
* for the roles post-transfer does not require extensive code
|
|
|
|
* changes.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Transfer party C connected line to party A */
|
|
|
|
ast_channel_lock(transferer);
|
|
|
|
/*
|
|
|
|
* Due to a limitation regarding when callerID is set on a Local channel,
|
|
|
|
* we use the transferer's connected line information here.
|
|
|
|
*/
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_party_connected_line_copy(&connected_line, ast_channel_connected(transferer));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_unlock(transferer);
|
|
|
|
connected_line.source = AST_CONNECTED_LINE_UPDATE_SOURCE_TRANSFER;
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(newchan, xferchan, &connected_line, 0) &&
|
|
|
|
ast_channel_connected_line_macro(newchan, xferchan, &connected_line, 1, 0)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_update_connected_line(xferchan, &connected_line, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Transfer party A connected line to party C */
|
|
|
|
ast_channel_lock(xferchan);
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_connected_line_copy_from_caller(&connected_line, ast_channel_caller(xferchan));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_unlock(xferchan);
|
|
|
|
connected_line.source = AST_CONNECTED_LINE_UPDATE_SOURCE_TRANSFER;
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(xferchan, newchan, &connected_line, 0) &&
|
|
|
|
ast_channel_connected_line_macro(xferchan, newchan, &connected_line, 0, 0)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_update_connected_line(newchan, &connected_line, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_stream_and_wait(newchan, xfersound, ""))
|
|
|
|
ast_log(LOG_WARNING, "Failed to play transfer sound!\n");
|
|
|
|
bridge_call_thread_launch(tobj);
|
|
|
|
|
|
|
|
ast_party_connected_line_free(&connected_line);
|
|
|
|
return -1;/* The transferee is masqueraded and the original bridged channels can be hungup. */
|
2005-01-05 19:56:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* add atxfer and automon as undefined so you can only use em if you configure them */
|
2007-05-01 22:24:51 +00:00
|
|
|
#define FEATURES_COUNT ARRAY_LEN(builtin_features)
|
2006-01-19 22:09:18 +00:00
|
|
|
|
2007-05-08 16:31:16 +00:00
|
|
|
AST_RWLOCK_DEFINE_STATIC(features_lock);
|
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
static struct ast_call_feature builtin_features[] = {
|
2006-08-29 21:20:43 +00:00
|
|
|
{ AST_FEATURE_REDIRECT, "Blind Transfer", "blindxfer", "#", "#", builtin_blindtransfer, AST_FEATURE_FLAG_NEEDSDTMF, "" },
|
|
|
|
{ AST_FEATURE_REDIRECT, "Attended Transfer", "atxfer", "", "", builtin_atxfer, AST_FEATURE_FLAG_NEEDSDTMF, "" },
|
|
|
|
{ AST_FEATURE_AUTOMON, "One Touch Monitor", "automon", "", "", builtin_automonitor, AST_FEATURE_FLAG_NEEDSDTMF, "" },
|
|
|
|
{ AST_FEATURE_DISCONNECT, "Disconnect Call", "disconnect", "*", "*", builtin_disconnect, AST_FEATURE_FLAG_NEEDSDTMF, "" },
|
|
|
|
{ AST_FEATURE_PARKCALL, "Park Call", "parkcall", "", "", builtin_parkcall, AST_FEATURE_FLAG_NEEDSDTMF, "" },
|
2007-11-30 21:19:57 +00:00
|
|
|
{ AST_FEATURE_AUTOMIXMON, "One Touch MixMonitor", "automixmon", "", "", builtin_automixmonitor, AST_FEATURE_FLAG_NEEDSDTMF, "" },
|
2005-01-04 04:01:40 +00:00
|
|
|
};
|
|
|
|
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2008-12-11 17:06:16 +00:00
|
|
|
static AST_RWLIST_HEAD_STATIC(feature_list, ast_call_feature);
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2006-01-19 22:09:18 +00:00
|
|
|
/*! \brief register new feature into feature_list*/
|
2005-08-23 02:22:33 +00:00
|
|
|
void ast_register_feature(struct ast_call_feature *feature)
|
|
|
|
{
|
|
|
|
if (!feature) {
|
|
|
|
ast_log(LOG_NOTICE,"You didn't pass a feature!\n");
|
2007-06-06 18:43:12 +00:00
|
|
|
return;
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2008-12-11 17:06:16 +00:00
|
|
|
AST_RWLIST_WRLOCK(&feature_list);
|
|
|
|
AST_RWLIST_INSERT_HEAD(&feature_list,feature,feature_entry);
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(2, "Registered Feature '%s'\n",feature->sname);
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/*!
|
2007-08-07 23:04:01 +00:00
|
|
|
* \brief Add new feature group
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param fgname feature group name.
|
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Add new feature group to the feature group list insert at head of list.
|
|
|
|
* \note This function MUST be called while feature_groups is locked.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2010-07-09 21:57:21 +00:00
|
|
|
static struct feature_group *register_group(const char *fgname)
|
2007-05-31 18:21:47 +00:00
|
|
|
{
|
|
|
|
struct feature_group *fg;
|
|
|
|
|
|
|
|
if (!fgname) {
|
|
|
|
ast_log(LOG_NOTICE, "You didn't pass a new group name!\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-07-09 21:57:21 +00:00
|
|
|
if (!(fg = ast_calloc_with_stringfields(1, struct feature_group, 128))) {
|
2007-05-31 18:21:47 +00:00
|
|
|
return NULL;
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
2007-05-31 18:21:47 +00:00
|
|
|
|
|
|
|
ast_string_field_set(fg, gname, fgname);
|
|
|
|
|
|
|
|
AST_LIST_INSERT_HEAD(&feature_groups, fg, entry);
|
|
|
|
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(2, "Registered group '%s'\n", fg->gname);
|
2007-05-31 18:21:47 +00:00
|
|
|
|
|
|
|
return fg;
|
|
|
|
}
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/*!
|
2007-08-07 23:04:01 +00:00
|
|
|
* \brief Add feature to group
|
|
|
|
* \param fg feature group
|
|
|
|
* \param exten
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param feature feature to add.
|
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Check fg and feature specified, add feature to list
|
2012-03-22 19:51:16 +00:00
|
|
|
* \note This function MUST be called while feature_groups is locked.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2010-07-09 21:57:21 +00:00
|
|
|
static void register_group_feature(struct feature_group *fg, const char *exten, struct ast_call_feature *feature)
|
2007-05-31 18:21:47 +00:00
|
|
|
{
|
|
|
|
struct feature_group_exten *fge;
|
|
|
|
|
|
|
|
if (!fg) {
|
|
|
|
ast_log(LOG_NOTICE, "You didn't pass a group!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!feature) {
|
|
|
|
ast_log(LOG_NOTICE, "You didn't pass a feature!\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-07-09 21:57:21 +00:00
|
|
|
if (!(fge = ast_calloc_with_stringfields(1, struct feature_group_exten, 128))) {
|
2008-07-17 18:14:42 +00:00
|
|
|
return;
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
2008-07-17 18:14:42 +00:00
|
|
|
|
|
|
|
ast_string_field_set(fge, exten, S_OR(exten, feature->exten));
|
2007-05-31 18:21:47 +00:00
|
|
|
|
|
|
|
fge->feature = feature;
|
|
|
|
|
2010-07-09 21:57:21 +00:00
|
|
|
AST_LIST_INSERT_HEAD(&fg->features, fge, entry);
|
2007-05-31 18:21:47 +00:00
|
|
|
|
2007-07-26 15:49:18 +00:00
|
|
|
ast_verb(2, "Registered feature '%s' for group '%s' at exten '%s'\n",
|
2010-07-09 21:57:21 +00:00
|
|
|
feature->sname, fg->gname, fge->exten);
|
2007-05-31 18:21:47 +00:00
|
|
|
}
|
|
|
|
|
2005-08-23 02:22:33 +00:00
|
|
|
void ast_unregister_feature(struct ast_call_feature *feature)
|
|
|
|
{
|
2008-12-11 17:06:16 +00:00
|
|
|
if (!feature) {
|
2006-04-16 18:37:01 +00:00
|
|
|
return;
|
2008-12-11 17:06:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
AST_RWLIST_WRLOCK(&feature_list);
|
|
|
|
AST_RWLIST_REMOVE(&feature_list, feature, feature_entry);
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(feature);
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
/*! \brief Remove all features in the list */
|
2005-08-23 14:40:03 +00:00
|
|
|
static void ast_unregister_features(void)
|
|
|
|
{
|
|
|
|
struct ast_call_feature *feature;
|
|
|
|
|
2008-12-11 17:06:16 +00:00
|
|
|
AST_RWLIST_WRLOCK(&feature_list);
|
|
|
|
while ((feature = AST_RWLIST_REMOVE_HEAD(&feature_list, feature_entry))) {
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(feature);
|
2008-12-11 17:06:16 +00:00
|
|
|
}
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2005-08-23 14:40:03 +00:00
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2007-05-04 17:49:20 +00:00
|
|
|
/*! \brief find a call feature by name */
|
2007-05-08 16:54:02 +00:00
|
|
|
static struct ast_call_feature *find_dynamic_feature(const char *name)
|
2005-08-23 02:22:33 +00:00
|
|
|
{
|
|
|
|
struct ast_call_feature *tmp;
|
|
|
|
|
2008-12-11 17:06:16 +00:00
|
|
|
AST_RWLIST_TRAVERSE(&feature_list, tmp, feature_entry) {
|
|
|
|
if (!strcasecmp(tmp->sname, name)) {
|
2005-09-07 21:36:30 +00:00
|
|
|
break;
|
2008-12-11 17:06:16 +00:00
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return tmp;
|
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*! \brief Remove all feature groups in the list */
|
2007-05-31 18:21:47 +00:00
|
|
|
static void ast_unregister_groups(void)
|
|
|
|
{
|
|
|
|
struct feature_group *fg;
|
|
|
|
struct feature_group_exten *fge;
|
|
|
|
|
|
|
|
AST_RWLIST_WRLOCK(&feature_groups);
|
|
|
|
while ((fg = AST_LIST_REMOVE_HEAD(&feature_groups, entry))) {
|
|
|
|
while ((fge = AST_LIST_REMOVE_HEAD(&fg->features, entry))) {
|
2007-11-04 19:44:31 +00:00
|
|
|
ast_string_field_free_memory(fge);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(fge);
|
2007-05-31 18:21:47 +00:00
|
|
|
}
|
|
|
|
|
2007-11-04 19:44:31 +00:00
|
|
|
ast_string_field_free_memory(fg);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(fg);
|
2007-05-31 18:21:47 +00:00
|
|
|
}
|
|
|
|
AST_RWLIST_UNLOCK(&feature_groups);
|
|
|
|
}
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/*!
|
|
|
|
* \brief Find a group by name
|
2007-08-07 23:04:01 +00:00
|
|
|
* \param name feature name
|
|
|
|
* \retval feature group on success.
|
|
|
|
* \retval NULL on failure.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2010-07-09 21:57:21 +00:00
|
|
|
static struct feature_group *find_group(const char *name)
|
|
|
|
{
|
2007-05-31 18:21:47 +00:00
|
|
|
struct feature_group *fg = NULL;
|
|
|
|
|
|
|
|
AST_LIST_TRAVERSE(&feature_groups, fg, entry) {
|
|
|
|
if (!strcasecmp(fg->gname, name))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return fg;
|
|
|
|
}
|
|
|
|
|
2007-05-08 16:41:35 +00:00
|
|
|
void ast_rdlock_call_features(void)
|
|
|
|
{
|
|
|
|
ast_rwlock_rdlock(&features_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ast_unlock_call_features(void)
|
|
|
|
{
|
|
|
|
ast_rwlock_unlock(&features_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct ast_call_feature *ast_find_call_feature(const char *name)
|
2007-05-04 18:47:19 +00:00
|
|
|
{
|
|
|
|
int x;
|
|
|
|
for (x = 0; x < FEATURES_COUNT; x++) {
|
2007-05-08 16:41:35 +00:00
|
|
|
if (!strcasecmp(name, builtin_features[x].sname))
|
2007-05-04 18:47:19 +00:00
|
|
|
return &builtin_features[x];
|
|
|
|
}
|
2011-12-23 20:42:21 +00:00
|
|
|
|
|
|
|
return find_dynamic_feature(name);
|
2007-05-04 18:47:19 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
2012-03-22 19:51:16 +00:00
|
|
|
* \brief exec an app by feature
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param chan,peer,config,code,sense,data
|
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Find a feature, determine which channel activated
|
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-23 18:13:49 +00:00
|
|
|
* \retval AST_FEATURE_RETURN_NO_HANGUP_PEER
|
2007-08-07 23:04:01 +00:00
|
|
|
* \retval -1 error.
|
|
|
|
* \retval -2 when an application cannot be found.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2009-05-21 21:13:09 +00:00
|
|
|
static int feature_exec_app(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense, void *data)
|
2005-08-23 02:22:33 +00:00
|
|
|
{
|
|
|
|
struct ast_app *app;
|
2007-08-23 20:20:17 +00:00
|
|
|
struct ast_call_feature *feature = data;
|
2006-08-29 21:20:43 +00:00
|
|
|
struct ast_channel *work, *idle;
|
2005-08-23 02:22:33 +00:00
|
|
|
int res;
|
|
|
|
|
|
|
|
if (!feature) { /* shouldn't ever happen! */
|
|
|
|
ast_log(LOG_NOTICE, "Found feature before, but at execing we've lost it??\n");
|
2012-03-22 19:51:16 +00:00
|
|
|
return -1;
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
2006-08-07 04:15:52 +00:00
|
|
|
|
|
|
|
if (sense == FEATURE_SENSE_CHAN) {
|
|
|
|
if (!ast_test_flag(feature, AST_FEATURE_FLAG_BYCALLER))
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_KEEPTRYING;
|
2006-08-29 21:20:43 +00:00
|
|
|
if (ast_test_flag(feature, AST_FEATURE_FLAG_ONSELF)) {
|
|
|
|
work = chan;
|
|
|
|
idle = peer;
|
|
|
|
} else {
|
|
|
|
work = peer;
|
|
|
|
idle = chan;
|
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
} else {
|
2006-08-07 04:15:52 +00:00
|
|
|
if (!ast_test_flag(feature, AST_FEATURE_FLAG_BYCALLEE))
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_KEEPTRYING;
|
2006-08-29 21:20:43 +00:00
|
|
|
if (ast_test_flag(feature, AST_FEATURE_FLAG_ONSELF)) {
|
|
|
|
work = peer;
|
|
|
|
idle = chan;
|
|
|
|
} else {
|
|
|
|
work = chan;
|
|
|
|
idle = peer;
|
|
|
|
}
|
2006-08-07 04:15:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!(app = pbx_findapp(feature->app))) {
|
2005-08-23 02:22:33 +00:00
|
|
|
ast_log(LOG_WARNING, "Could not find application (%s)\n", feature->app);
|
2006-01-05 23:08:55 +00:00
|
|
|
return -2;
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
2006-08-07 04:15:52 +00:00
|
|
|
|
2006-08-29 21:20:43 +00:00
|
|
|
ast_autoservice_start(idle);
|
2010-07-20 22:26:23 +00:00
|
|
|
ast_autoservice_ignore(idle, AST_FRAME_DTMF_END);
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2009-08-26 23:13:19 +00:00
|
|
|
if(work && idle) {
|
2012-01-09 22:15:50 +00:00
|
|
|
pbx_builtin_setvar_helper(work, "DYNAMIC_PEERNAME", ast_channel_name(idle));
|
|
|
|
pbx_builtin_setvar_helper(idle, "DYNAMIC_PEERNAME", ast_channel_name(work));
|
2009-08-26 23:13:19 +00:00
|
|
|
pbx_builtin_setvar_helper(work, "DYNAMIC_FEATURENAME", feature->sname);
|
|
|
|
pbx_builtin_setvar_helper(idle, "DYNAMIC_FEATURENAME", feature->sname);
|
|
|
|
}
|
|
|
|
|
2006-08-29 21:20:43 +00:00
|
|
|
if (!ast_strlen_zero(feature->moh_class))
|
|
|
|
ast_moh_start(idle, feature->moh_class, NULL);
|
|
|
|
|
2006-08-07 04:15:52 +00:00
|
|
|
res = pbx_exec(work, app, feature->app_args);
|
|
|
|
|
2006-08-29 21:20:43 +00:00
|
|
|
if (!ast_strlen_zero(feature->moh_class))
|
|
|
|
ast_moh_stop(idle);
|
|
|
|
|
|
|
|
ast_autoservice_stop(idle);
|
|
|
|
|
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-23 18:13:49 +00:00
|
|
|
if (res) {
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESSBREAK;
|
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-23 18:13:49 +00:00
|
|
|
}
|
2008-04-08 17:32:42 +00:00
|
|
|
return AST_FEATURE_RETURN_SUCCESS; /*! \todo XXX should probably return res */
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
|
|
|
|
2005-01-04 04:01:40 +00:00
|
|
|
static void unmap_features(void)
|
|
|
|
{
|
|
|
|
int x;
|
2007-05-08 16:31:16 +00:00
|
|
|
|
|
|
|
ast_rwlock_wrlock(&features_lock);
|
2005-07-25 17:31:53 +00:00
|
|
|
for (x = 0; x < FEATURES_COUNT; x++)
|
2005-01-04 04:01:40 +00:00
|
|
|
strcpy(builtin_features[x].exten, builtin_features[x].default_exten);
|
2007-05-08 16:31:16 +00:00
|
|
|
ast_rwlock_unlock(&features_lock);
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int remap_feature(const char *name, const char *value)
|
|
|
|
{
|
2007-05-08 16:54:02 +00:00
|
|
|
int x, res = -1;
|
2007-05-08 16:31:16 +00:00
|
|
|
|
|
|
|
ast_rwlock_wrlock(&features_lock);
|
2007-05-08 16:54:02 +00:00
|
|
|
for (x = 0; x < FEATURES_COUNT; x++) {
|
|
|
|
if (strcasecmp(builtin_features[x].sname, name))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ast_copy_string(builtin_features[x].exten, value, sizeof(builtin_features[x].exten));
|
2007-05-08 16:31:16 +00:00
|
|
|
res = 0;
|
2007-05-08 16:54:02 +00:00
|
|
|
break;
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
2007-05-08 16:31:16 +00:00
|
|
|
ast_rwlock_unlock(&features_lock);
|
|
|
|
|
2005-01-04 04:01:40 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2009-02-02 19:02:24 +00:00
|
|
|
/*!
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
* \brief Helper function for feature_interpret and ast_feature_detect
|
2010-06-08 14:38:18 +00:00
|
|
|
* \param chan,peer,config,code,sense,dynamic_features_buf,features,operation,feature
|
2009-02-02 19:02:24 +00:00
|
|
|
*
|
|
|
|
* Lock features list, browse for code, unlock list
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
* If a feature is found and the operation variable is set, that feature's
|
|
|
|
* operation is executed. The first feature found is copied to the feature parameter.
|
2009-02-02 19:02:24 +00:00
|
|
|
* \retval res on success.
|
|
|
|
* \retval -1 on failure.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
static int feature_interpret_helper(struct ast_channel *chan, struct ast_channel *peer,
|
2009-05-21 21:13:09 +00:00
|
|
|
struct ast_bridge_config *config, const char *code, int sense, char *dynamic_features_buf,
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
struct ast_flags *features, feature_interpret_op operation, struct ast_call_feature *feature)
|
2005-01-04 04:01:40 +00:00
|
|
|
{
|
|
|
|
int x;
|
2007-05-31 18:21:47 +00:00
|
|
|
struct feature_group *fg = NULL;
|
|
|
|
struct feature_group_exten *fge;
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
struct ast_call_feature *tmpfeature;
|
2007-05-08 16:31:16 +00:00
|
|
|
char *tmp, *tok;
|
2009-02-02 19:02:24 +00:00
|
|
|
int res = AST_FEATURE_RETURN_PASSDIGITS;
|
|
|
|
int feature_detected = 0;
|
|
|
|
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
if (!(peer && chan && config) && operation == FEATURE_INTERPRET_DO) {
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
return -1; /* can not run feature operation */
|
2009-02-02 19:02:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ast_rwlock_rdlock(&features_lock);
|
2007-05-08 16:31:16 +00:00
|
|
|
for (x = 0; x < FEATURES_COUNT; x++) {
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
if ((ast_test_flag(features, builtin_features[x].feature_mask)) &&
|
2005-01-04 04:01:40 +00:00
|
|
|
!ast_strlen_zero(builtin_features[x].exten)) {
|
|
|
|
/* Feature is up for consideration */
|
|
|
|
if (!strcmp(builtin_features[x].exten, code)) {
|
2009-02-04 21:17:53 +00:00
|
|
|
ast_debug(3, "Feature detected: fname=%s sname=%s exten=%s\n", builtin_features[x].fname, builtin_features[x].sname, builtin_features[x].exten);
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
if (operation == FEATURE_INTERPRET_CHECK) {
|
|
|
|
res = AST_FEATURE_RETURN_SUCCESS; /* We found something */
|
|
|
|
} else if (operation == FEATURE_INTERPRET_DO) {
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
res = builtin_features[x].operation(chan, peer, config, code, sense, NULL);
|
|
|
|
}
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
if (feature) {
|
2012-03-14 00:22:10 +00:00
|
|
|
memcpy(feature, &builtin_features[x], sizeof(*feature));
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
}
|
2009-02-02 19:02:24 +00:00
|
|
|
feature_detected = 1;
|
2005-01-04 04:01:40 +00:00
|
|
|
break;
|
|
|
|
} else if (!strncmp(builtin_features[x].exten, code, strlen(code))) {
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
if (res == AST_FEATURE_RETURN_PASSDIGITS) {
|
2008-04-08 17:32:42 +00:00
|
|
|
res = AST_FEATURE_RETURN_STOREDIGITS;
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-02-02 19:02:24 +00:00
|
|
|
ast_rwlock_unlock(&features_lock);
|
2005-08-23 02:22:33 +00:00
|
|
|
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
if (ast_strlen_zero(dynamic_features_buf) || feature_detected) {
|
2007-05-08 16:31:16 +00:00
|
|
|
return res;
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2009-03-13 17:26:43 +00:00
|
|
|
tmp = dynamic_features_buf;
|
2005-09-07 21:36:30 +00:00
|
|
|
|
2007-05-08 16:31:16 +00:00
|
|
|
while ((tok = strsep(&tmp, "#"))) {
|
2009-02-02 19:02:24 +00:00
|
|
|
AST_RWLIST_RDLOCK(&feature_groups);
|
2007-05-31 18:21:47 +00:00
|
|
|
|
|
|
|
fg = find_group(tok);
|
|
|
|
|
2007-09-17 16:58:23 +00:00
|
|
|
if (fg) {
|
|
|
|
AST_LIST_TRAVERSE(&fg->features, fge, entry) {
|
2010-07-09 21:57:21 +00:00
|
|
|
if (!strcmp(fge->exten, code)) {
|
|
|
|
if (operation) {
|
|
|
|
res = fge->feature->operation(chan, peer, config, code, sense, fge->feature);
|
|
|
|
}
|
2012-03-14 00:22:10 +00:00
|
|
|
memcpy(feature, fge->feature, sizeof(*feature));
|
2010-07-09 21:57:21 +00:00
|
|
|
if (res != AST_FEATURE_RETURN_KEEPTRYING) {
|
|
|
|
AST_RWLIST_UNLOCK(&feature_groups);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
res = AST_FEATURE_RETURN_PASSDIGITS;
|
|
|
|
} else if (!strncmp(fge->exten, code, strlen(code))) {
|
|
|
|
res = AST_FEATURE_RETURN_STOREDIGITS;
|
2007-09-17 16:58:23 +00:00
|
|
|
}
|
|
|
|
}
|
2010-07-09 21:57:21 +00:00
|
|
|
if (fge) {
|
2007-09-17 16:58:23 +00:00
|
|
|
break;
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
2007-05-31 18:21:47 +00:00
|
|
|
}
|
|
|
|
|
2009-02-02 19:02:24 +00:00
|
|
|
AST_RWLIST_UNLOCK(&feature_groups);
|
|
|
|
|
|
|
|
AST_RWLIST_RDLOCK(&feature_list);
|
|
|
|
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
if (!(tmpfeature = find_dynamic_feature(tok))) {
|
2009-02-02 19:02:24 +00:00
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2007-05-31 18:21:47 +00:00
|
|
|
continue;
|
|
|
|
}
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
|
2007-05-08 16:31:16 +00:00
|
|
|
/* Feature is up for consideration */
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
if (!strcmp(tmpfeature->exten, code)) {
|
|
|
|
ast_verb(3, " Feature Found: %s exten: %s\n",tmpfeature->sname, tok);
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
if (operation == FEATURE_INTERPRET_CHECK) {
|
|
|
|
res = AST_FEATURE_RETURN_SUCCESS; /* We found something */
|
|
|
|
} else if (operation == FEATURE_INTERPRET_DO) {
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
res = tmpfeature->operation(chan, peer, config, code, sense, tmpfeature);
|
|
|
|
}
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
if (feature) {
|
2012-03-14 00:22:10 +00:00
|
|
|
memcpy(feature, tmpfeature, sizeof(*feature));
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
}
|
2009-02-02 19:02:24 +00:00
|
|
|
if (res != AST_FEATURE_RETURN_KEEPTRYING) {
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2007-09-17 16:58:23 +00:00
|
|
|
break;
|
|
|
|
}
|
2008-04-08 17:32:42 +00:00
|
|
|
res = AST_FEATURE_RETURN_PASSDIGITS;
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
} else if (!strncmp(tmpfeature->exten, code, strlen(code)))
|
2008-04-08 17:32:42 +00:00
|
|
|
res = AST_FEATURE_RETURN_STOREDIGITS;
|
2007-05-08 16:31:16 +00:00
|
|
|
|
2009-02-02 19:02:24 +00:00
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
|
2005-01-04 04:01:40 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
/*!
|
|
|
|
* \brief Check the dynamic features
|
|
|
|
* \param chan,peer,config,code,sense
|
|
|
|
*
|
|
|
|
* \retval res on success.
|
|
|
|
* \retval -1 on failure.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2009-05-21 21:13:09 +00:00
|
|
|
static int feature_interpret(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config, const char *code, int sense) {
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
|
|
|
|
char dynamic_features_buf[128];
|
|
|
|
const char *peer_dynamic_features, *chan_dynamic_features;
|
|
|
|
struct ast_flags features;
|
|
|
|
struct ast_call_feature feature;
|
|
|
|
if (sense == FEATURE_SENSE_CHAN) {
|
|
|
|
ast_copy_flags(&features, &(config->features_caller), AST_FLAGS_ALL);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
ast_copy_flags(&features, &(config->features_callee), AST_FLAGS_ALL);
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_channel_lock(peer);
|
|
|
|
peer_dynamic_features = ast_strdupa(S_OR(pbx_builtin_getvar_helper(peer, "DYNAMIC_FEATURES"),""));
|
|
|
|
ast_channel_unlock(peer);
|
|
|
|
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
chan_dynamic_features = ast_strdupa(S_OR(pbx_builtin_getvar_helper(chan, "DYNAMIC_FEATURES"),""));
|
|
|
|
ast_channel_unlock(chan);
|
|
|
|
|
|
|
|
snprintf(dynamic_features_buf, sizeof(dynamic_features_buf), "%s%s%s", S_OR(chan_dynamic_features, ""), chan_dynamic_features && peer_dynamic_features ? "#" : "", S_OR(peer_dynamic_features,""));
|
|
|
|
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(3, "Feature interpret: chan=%s, peer=%s, code=%s, sense=%d, features=%d, dynamic=%s\n", ast_channel_name(chan), ast_channel_name(peer), code, sense, features.flags, dynamic_features_buf);
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
return feature_interpret_helper(chan, peer, config, code, sense, dynamic_features_buf, &features, FEATURE_INTERPRET_DO, &feature);
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-05-21 21:13:09 +00:00
|
|
|
int ast_feature_detect(struct ast_channel *chan, struct ast_flags *features, const char *code, struct ast_call_feature *feature) {
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
return feature_interpret_helper(chan, NULL, NULL, code, 0, NULL, features, FEATURE_INTERPRET_DETECT, feature);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Check if a feature exists */
|
|
|
|
static int feature_check(struct ast_channel *chan, struct ast_flags *features, char *code) {
|
2011-06-15 18:23:20 +00:00
|
|
|
char *chan_dynamic_features;
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
chan_dynamic_features = ast_strdupa(S_OR(pbx_builtin_getvar_helper(chan, "DYNAMIC_FEATURES"),""));
|
|
|
|
ast_channel_unlock(chan);
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
|
2011-06-15 18:23:20 +00:00
|
|
|
return feature_interpret_helper(chan, NULL, NULL, code, 0, chan_dynamic_features, features, FEATURE_INTERPRET_CHECK, NULL);
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
}
|
|
|
|
|
2012-01-13 18:52:53 +00:00
|
|
|
static void set_config_flags(struct ast_channel *chan, struct ast_bridge_config *config)
|
2005-01-04 04:01:40 +00:00
|
|
|
{
|
|
|
|
int x;
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
|
2007-05-08 16:31:16 +00:00
|
|
|
ast_clear_flag(config, AST_FLAGS_ALL);
|
|
|
|
|
|
|
|
ast_rwlock_rdlock(&features_lock);
|
2005-08-23 15:33:27 +00:00
|
|
|
for (x = 0; x < FEATURES_COUNT; x++) {
|
2007-05-08 16:31:16 +00:00
|
|
|
if (!ast_test_flag(builtin_features + x, AST_FEATURE_FLAG_NEEDSDTMF))
|
|
|
|
continue;
|
2005-09-07 21:36:30 +00:00
|
|
|
|
2007-05-08 16:31:16 +00:00
|
|
|
if (ast_test_flag(&(config->features_caller), builtin_features[x].feature_mask))
|
|
|
|
ast_set_flag(config, AST_BRIDGE_DTMF_CHANNEL_0);
|
|
|
|
|
|
|
|
if (ast_test_flag(&(config->features_callee), builtin_features[x].feature_mask))
|
|
|
|
ast_set_flag(config, AST_BRIDGE_DTMF_CHANNEL_1);
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
2007-05-08 16:31:16 +00:00
|
|
|
ast_rwlock_unlock(&features_lock);
|
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-19 16:28:33 +00:00
|
|
|
|
2012-01-13 18:52:53 +00:00
|
|
|
if (!(ast_test_flag(config, AST_BRIDGE_DTMF_CHANNEL_0) && ast_test_flag(config, AST_BRIDGE_DTMF_CHANNEL_1))) {
|
2005-12-03 19:25:33 +00:00
|
|
|
const char *dynamic_features = pbx_builtin_getvar_helper(chan, "DYNAMIC_FEATURES");
|
2005-09-07 21:36:30 +00:00
|
|
|
|
|
|
|
if (dynamic_features) {
|
|
|
|
char *tmp = ast_strdupa(dynamic_features);
|
|
|
|
char *tok;
|
|
|
|
struct ast_call_feature *feature;
|
|
|
|
|
|
|
|
/* while we have a feature */
|
2006-05-10 13:22:15 +00:00
|
|
|
while ((tok = strsep(&tmp, "#"))) {
|
2010-07-09 21:57:21 +00:00
|
|
|
struct feature_group *fg;
|
|
|
|
|
|
|
|
AST_RWLIST_RDLOCK(&feature_groups);
|
|
|
|
AST_RWLIST_TRAVERSE(&feature_groups, fg, entry) {
|
|
|
|
struct feature_group_exten *fge;
|
|
|
|
|
|
|
|
AST_LIST_TRAVERSE(&fg->features, fge, entry) {
|
|
|
|
if (ast_test_flag(fge->feature, AST_FEATURE_FLAG_BYCALLER)) {
|
|
|
|
ast_set_flag(config, AST_BRIDGE_DTMF_CHANNEL_0);
|
|
|
|
}
|
|
|
|
if (ast_test_flag(fge->feature, AST_FEATURE_FLAG_BYCALLEE)) {
|
|
|
|
ast_set_flag(config, AST_BRIDGE_DTMF_CHANNEL_1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_RWLIST_UNLOCK(&feature_groups);
|
|
|
|
|
2008-12-11 17:06:16 +00:00
|
|
|
AST_RWLIST_RDLOCK(&feature_list);
|
2007-05-08 16:54:02 +00:00
|
|
|
if ((feature = find_dynamic_feature(tok)) && ast_test_flag(feature, AST_FEATURE_FLAG_NEEDSDTMF)) {
|
2010-07-09 21:57:21 +00:00
|
|
|
if (ast_test_flag(feature, AST_FEATURE_FLAG_BYCALLER)) {
|
2006-04-16 18:37:01 +00:00
|
|
|
ast_set_flag(config, AST_BRIDGE_DTMF_CHANNEL_0);
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
|
|
|
if (ast_test_flag(feature, AST_FEATURE_FLAG_BYCALLEE)) {
|
2006-04-16 18:37:01 +00:00
|
|
|
ast_set_flag(config, AST_BRIDGE_DTMF_CHANNEL_1);
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
2005-09-07 21:36:30 +00:00
|
|
|
}
|
2008-12-11 17:06:16 +00:00
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2005-09-07 21:36:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Get feature and dial.
|
2007-09-05 16:31:39 +00:00
|
|
|
*
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
* \param caller Channel to represent as the calling channel for the dialed channel.
|
|
|
|
* \param caller_name Original caller channel name.
|
|
|
|
* \param requestor Channel to say is requesting the dial (usually the caller).
|
|
|
|
* \param transferee Channel that the dialed channel will be transferred to.
|
|
|
|
* \param type Channel technology type to dial.
|
|
|
|
* \param format Codec formats for dialed channel.
|
2012-02-01 19:53:38 +00:00
|
|
|
* \param addr destination of the call
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
* \param timeout Time limit for dialed channel to answer in ms. Must be greater than zero.
|
|
|
|
* \param outstate Status of dialed channel if unsuccessful.
|
|
|
|
* \param language Language of the caller.
|
2007-09-05 16:31:39 +00:00
|
|
|
*
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
* \note
|
|
|
|
* outstate can be:
|
|
|
|
* 0, AST_CONTROL_BUSY, AST_CONTROL_CONGESTION,
|
|
|
|
* AST_CONTROL_ANSWER, or AST_CONTROL_UNHOLD. If
|
|
|
|
* AST_CONTROL_UNHOLD then the caller channel cancelled the
|
|
|
|
* transfer or the dialed channel did not answer before the
|
|
|
|
* timeout.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* Request channel, set channel variables, initiate call,
|
|
|
|
* check if they want to disconnect, go into loop, check if timeout has elapsed,
|
|
|
|
* check if person to be transfered hung up, check for answer break loop,
|
|
|
|
* set cdr return channel.
|
|
|
|
*
|
|
|
|
* \retval Channel Connected channel for transfer.
|
|
|
|
* \retval NULL on failure to get third party connected.
|
|
|
|
*
|
|
|
|
* \note This is similar to __ast_request_and_dial() in channel.c
|
|
|
|
*/
|
|
|
|
static struct ast_channel *feature_request_and_dial(struct ast_channel *caller,
|
|
|
|
const char *caller_name, struct ast_channel *requestor,
|
2012-02-01 19:53:38 +00:00
|
|
|
struct ast_channel *transferee, const char *type, struct ast_format_cap *cap, const char *addr,
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
int timeout, int *outstate, const char *language)
|
2005-06-23 22:12:01 +00:00
|
|
|
{
|
|
|
|
int state = 0;
|
|
|
|
int cause = 0;
|
|
|
|
int to;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
int caller_hungup;
|
|
|
|
int transferee_hungup;
|
2005-06-23 22:12:01 +00:00
|
|
|
struct ast_channel *chan;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
struct ast_channel *monitor_chans[3];
|
2005-06-23 22:12:01 +00:00
|
|
|
struct ast_channel *active_channel;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
int res;
|
|
|
|
int ready = 0;
|
2008-12-11 19:40:18 +00:00
|
|
|
struct timeval started;
|
|
|
|
int x, len = 0;
|
|
|
|
char *disconnect_code = NULL, *dialed_code = NULL;
|
2011-02-03 16:22:10 +00:00
|
|
|
struct ast_format_cap *tmp_cap;
|
|
|
|
struct ast_format best_audio_fmt;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
struct ast_frame *f;
|
|
|
|
AST_LIST_HEAD_NOLOCK(, ast_frame) deferred_frames;
|
|
|
|
|
2011-02-03 16:22:10 +00:00
|
|
|
tmp_cap = ast_format_cap_alloc_nolock();
|
|
|
|
if (!tmp_cap) {
|
2011-08-10 19:08:22 +00:00
|
|
|
if (outstate) {
|
|
|
|
*outstate = 0;
|
|
|
|
}
|
2011-02-03 16:22:10 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
ast_best_codec(cap, &best_audio_fmt);
|
|
|
|
ast_format_cap_add(tmp_cap, &best_audio_fmt);
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
caller_hungup = ast_check_hangup(caller);
|
2008-02-27 17:31:31 +00:00
|
|
|
|
2012-02-01 19:53:38 +00:00
|
|
|
if (!(chan = ast_request(type, tmp_cap, requestor, addr, &cause))) {
|
|
|
|
ast_log(LOG_NOTICE, "Unable to request channel %s/%s\n", type, addr);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
switch (cause) {
|
2008-12-11 19:40:18 +00:00
|
|
|
case AST_CAUSE_BUSY:
|
|
|
|
state = AST_CONTROL_BUSY;
|
|
|
|
break;
|
|
|
|
case AST_CAUSE_CONGESTION:
|
|
|
|
state = AST_CONTROL_CONGESTION;
|
|
|
|
break;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
default:
|
|
|
|
state = 0;
|
|
|
|
break;
|
2008-12-11 19:40:18 +00:00
|
|
|
}
|
|
|
|
goto done;
|
|
|
|
}
|
2005-06-23 22:12:01 +00:00
|
|
|
|
2012-01-24 20:12:09 +00:00
|
|
|
ast_channel_language_set(chan, language);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_channel_inherit_variables(caller, chan);
|
|
|
|
pbx_builtin_setvar_helper(chan, "TRANSFERERNAME", caller_name);
|
|
|
|
|
2009-04-03 22:41:46 +00:00
|
|
|
ast_channel_lock(chan);
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_connected_line_copy_from_caller(ast_channel_connected(chan), ast_channel_caller(requestor));
|
2009-04-03 22:41:46 +00:00
|
|
|
ast_channel_unlock(chan);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
2012-02-01 19:53:38 +00:00
|
|
|
if (ast_call(chan, addr, timeout)) {
|
|
|
|
ast_log(LOG_NOTICE, "Unable to call channel %s/%s\n", type, addr);
|
2012-02-20 23:43:27 +00:00
|
|
|
switch (ast_channel_hangupcause(chan)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
case AST_CAUSE_BUSY:
|
|
|
|
state = AST_CONTROL_BUSY;
|
|
|
|
break;
|
|
|
|
case AST_CAUSE_CONGESTION:
|
|
|
|
state = AST_CONTROL_CONGESTION;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
state = 0;
|
|
|
|
break;
|
|
|
|
}
|
2008-12-11 20:21:44 +00:00
|
|
|
goto done;
|
2008-12-11 19:40:18 +00:00
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
2008-12-11 19:40:18 +00:00
|
|
|
/* support dialing of the featuremap disconnect code while performing an attended tranfer */
|
|
|
|
ast_rwlock_rdlock(&features_lock);
|
|
|
|
for (x = 0; x < FEATURES_COUNT; x++) {
|
|
|
|
if (strcasecmp(builtin_features[x].sname, "disconnect"))
|
|
|
|
continue;
|
2007-08-28 14:37:09 +00:00
|
|
|
|
2008-12-11 19:40:18 +00:00
|
|
|
disconnect_code = builtin_features[x].exten;
|
|
|
|
len = strlen(disconnect_code) + 1;
|
|
|
|
dialed_code = alloca(len);
|
|
|
|
memset(dialed_code, 0, len);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
ast_rwlock_unlock(&features_lock);
|
|
|
|
x = 0;
|
|
|
|
started = ast_tvnow();
|
|
|
|
to = timeout;
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
AST_LIST_HEAD_INIT_NOLOCK(&deferred_frames);
|
2007-08-28 14:37:09 +00:00
|
|
|
|
2008-12-11 19:40:18 +00:00
|
|
|
ast_poll_channel_add(caller, chan);
|
2006-04-16 20:09:01 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
transferee_hungup = 0;
|
2012-02-20 23:43:27 +00:00
|
|
|
while (!ast_check_hangup(transferee) && (ast_channel_state(chan) != AST_STATE_UP)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
int num_chans = 0;
|
|
|
|
|
|
|
|
monitor_chans[num_chans++] = transferee;
|
|
|
|
monitor_chans[num_chans++] = chan;
|
|
|
|
if (!caller_hungup) {
|
|
|
|
if (ast_check_hangup(caller)) {
|
|
|
|
caller_hungup = 1;
|
|
|
|
|
|
|
|
#if defined(ATXFER_NULL_TECH)
|
|
|
|
/* Change caller's name to ensure that it will remain unique. */
|
|
|
|
set_new_chan_name(caller);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get rid of caller's physical technology so it is free for
|
|
|
|
* other calls.
|
|
|
|
*/
|
2011-05-25 16:50:38 +00:00
|
|
|
set_kill_chan_tech(caller);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
#endif /* defined(ATXFER_NULL_TECH) */
|
|
|
|
} else {
|
|
|
|
/* caller is not hungup so monitor it. */
|
|
|
|
monitor_chans[num_chans++] = caller;
|
|
|
|
}
|
|
|
|
}
|
2005-06-23 22:12:01 +00:00
|
|
|
|
2008-12-11 19:40:18 +00:00
|
|
|
/* see if the timeout has been violated */
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (ast_tvdiff_ms(ast_tvnow(), started) > timeout) {
|
2008-12-11 19:40:18 +00:00
|
|
|
state = AST_CONTROL_UNHOLD;
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_NOTICE, "We exceeded our AT-timeout for %s\n", ast_channel_name(chan));
|
2008-12-11 19:40:18 +00:00
|
|
|
break; /*doh! timeout*/
|
|
|
|
}
|
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
active_channel = ast_waitfor_n(monitor_chans, num_chans, &to);
|
2008-12-11 19:40:18 +00:00
|
|
|
if (!active_channel)
|
|
|
|
continue;
|
2005-06-23 22:12:01 +00:00
|
|
|
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
f = NULL;
|
|
|
|
if (transferee == active_channel) {
|
|
|
|
struct ast_frame *dup_f;
|
|
|
|
|
|
|
|
f = ast_read(transferee);
|
|
|
|
if (f == NULL) { /*doh! where'd he go?*/
|
|
|
|
transferee_hungup = 1;
|
|
|
|
state = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (ast_is_deferrable_frame(f)) {
|
|
|
|
dup_f = ast_frisolate(f);
|
|
|
|
if (dup_f) {
|
|
|
|
if (dup_f == f) {
|
|
|
|
f = NULL;
|
|
|
|
}
|
|
|
|
AST_LIST_INSERT_HEAD(&deferred_frames, dup_f, frame_list);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (chan == active_channel) {
|
2012-01-24 20:12:09 +00:00
|
|
|
if (!ast_strlen_zero(ast_channel_call_forward(chan))) {
|
2011-08-09 23:17:13 +00:00
|
|
|
state = 0;
|
2011-12-16 23:58:44 +00:00
|
|
|
ast_autoservice_start(transferee);
|
2011-02-03 16:22:10 +00:00
|
|
|
chan = ast_call_forward(caller, chan, NULL, tmp_cap, NULL, &state);
|
2011-12-16 23:58:44 +00:00
|
|
|
ast_autoservice_stop(transferee);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (!chan) {
|
|
|
|
break;
|
2009-06-02 21:17:49 +00:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
2008-12-11 19:40:18 +00:00
|
|
|
f = ast_read(chan);
|
|
|
|
if (f == NULL) { /*doh! where'd he go?*/
|
2012-02-20 23:43:27 +00:00
|
|
|
switch (ast_channel_hangupcause(chan)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
case AST_CAUSE_BUSY:
|
|
|
|
state = AST_CONTROL_BUSY;
|
|
|
|
break;
|
|
|
|
case AST_CAUSE_CONGESTION:
|
|
|
|
state = AST_CONTROL_CONGESTION;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
state = 0;
|
|
|
|
break;
|
|
|
|
}
|
2008-12-11 19:40:18 +00:00
|
|
|
break;
|
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
|
|
|
if (f->frametype == AST_FRAME_CONTROL) {
|
2009-11-04 14:05:12 +00:00
|
|
|
if (f->subclass.integer == AST_CONTROL_RINGING) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_verb(3, "%s is ringing\n", ast_channel_name(chan));
|
2008-12-11 19:40:18 +00:00
|
|
|
ast_indicate(caller, AST_CONTROL_RINGING);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
} else if (f->subclass.integer == AST_CONTROL_BUSY) {
|
2009-11-04 14:05:12 +00:00
|
|
|
state = f->subclass.integer;
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_verb(3, "%s is busy\n", ast_channel_name(chan));
|
2008-12-11 19:40:18 +00:00
|
|
|
ast_indicate(caller, AST_CONTROL_BUSY);
|
|
|
|
ast_frfree(f);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
break;
|
2011-09-09 16:28:23 +00:00
|
|
|
} else if (f->subclass.integer == AST_CONTROL_INCOMPLETE) {
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_verb(3, "%s dialed incomplete extension %s; ignoring\n", ast_channel_name(chan), ast_channel_exten(chan));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
} else if (f->subclass.integer == AST_CONTROL_CONGESTION) {
|
|
|
|
state = f->subclass.integer;
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_verb(3, "%s is congested\n", ast_channel_name(chan));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_indicate(caller, AST_CONTROL_CONGESTION);
|
|
|
|
ast_frfree(f);
|
2008-12-11 19:40:18 +00:00
|
|
|
break;
|
2009-11-04 14:05:12 +00:00
|
|
|
} else if (f->subclass.integer == AST_CONTROL_ANSWER) {
|
2008-12-11 19:40:18 +00:00
|
|
|
/* This is what we are hoping for */
|
2009-11-04 14:05:12 +00:00
|
|
|
state = f->subclass.integer;
|
2008-12-11 19:40:18 +00:00
|
|
|
ast_frfree(f);
|
|
|
|
ready=1;
|
|
|
|
break;
|
2009-11-04 14:05:12 +00:00
|
|
|
} else if (f->subclass.integer == AST_CONTROL_CONNECTED_LINE) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (caller_hungup) {
|
|
|
|
struct ast_party_connected_line connected;
|
|
|
|
|
|
|
|
/* Just save it for the transfer. */
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_party_connected_line_set_init(&connected, ast_channel_connected(caller));
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
res = ast_connected_line_parse_data(f->data.ptr, f->datalen,
|
|
|
|
&connected);
|
|
|
|
if (!res) {
|
|
|
|
ast_channel_set_connected_line(caller, &connected, NULL);
|
|
|
|
}
|
|
|
|
ast_party_connected_line_free(&connected);
|
|
|
|
} else {
|
|
|
|
ast_autoservice_start(transferee);
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(chan, caller, f, 1) &&
|
|
|
|
ast_channel_connected_line_macro(chan, caller, f, 1, 1)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_indicate_data(caller, AST_CONTROL_CONNECTED_LINE,
|
|
|
|
f->data.ptr, f->datalen);
|
|
|
|
}
|
|
|
|
ast_autoservice_stop(transferee);
|
2009-06-01 20:57:31 +00:00
|
|
|
}
|
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 (f->subclass.integer == AST_CONTROL_REDIRECTING) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (!caller_hungup) {
|
|
|
|
ast_autoservice_start(transferee);
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_redirecting_sub(chan, caller, f, 1) &&
|
|
|
|
ast_channel_redirecting_macro(chan, caller, f, 1, 1)) {
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
ast_indicate_data(caller, AST_CONTROL_REDIRECTING,
|
|
|
|
f->data.ptr, f->datalen);
|
|
|
|
}
|
|
|
|
ast_autoservice_stop(transferee);
|
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
|
|
|
}
|
2011-12-16 23:58:44 +00:00
|
|
|
} else if (f->subclass.integer != -1
|
|
|
|
&& f->subclass.integer != AST_CONTROL_PROGRESS
|
|
|
|
&& f->subclass.integer != AST_CONTROL_PROCEEDING) {
|
2009-11-04 14:05:12 +00:00
|
|
|
ast_log(LOG_NOTICE, "Don't know what to do about control frame: %d\n", f->subclass.integer);
|
2008-12-11 19:40:18 +00:00
|
|
|
}
|
|
|
|
/* else who cares */
|
2009-10-20 17:47:34 +00:00
|
|
|
} else if (f->frametype == AST_FRAME_VOICE || f->frametype == AST_FRAME_VIDEO) {
|
|
|
|
ast_write(caller, f);
|
2008-12-11 19:40:18 +00:00
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
} else if (caller == active_channel) {
|
2008-12-11 19:40:18 +00:00
|
|
|
f = ast_read(caller);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
if (f) {
|
2008-12-11 19:40:18 +00:00
|
|
|
if (f->frametype == AST_FRAME_DTMF) {
|
2009-11-04 14:05:12 +00:00
|
|
|
dialed_code[x++] = f->subclass.integer;
|
2008-12-11 19:40:18 +00:00
|
|
|
dialed_code[x] = '\0';
|
|
|
|
if (strlen(dialed_code) == len) {
|
|
|
|
x = 0;
|
|
|
|
} else if (x && strncmp(dialed_code, disconnect_code, x)) {
|
|
|
|
x = 0;
|
|
|
|
dialed_code[x] = '\0';
|
2005-06-23 22:12:01 +00:00
|
|
|
}
|
2008-12-11 19:40:18 +00:00
|
|
|
if (*dialed_code && !strcmp(dialed_code, disconnect_code)) {
|
|
|
|
/* Caller Canceled the call */
|
|
|
|
state = AST_CONTROL_UNHOLD;
|
|
|
|
ast_frfree(f);
|
|
|
|
break;
|
2005-06-23 22:12:01 +00:00
|
|
|
}
|
2009-10-20 17:47:34 +00:00
|
|
|
} else if (f->frametype == AST_FRAME_VOICE || f->frametype == AST_FRAME_VIDEO) {
|
|
|
|
ast_write(chan, f);
|
2005-06-23 22:12:01 +00:00
|
|
|
}
|
2008-12-11 19:40:18 +00:00
|
|
|
}
|
2005-06-23 22:12:01 +00:00
|
|
|
}
|
2008-12-11 19:40:18 +00:00
|
|
|
if (f)
|
|
|
|
ast_frfree(f);
|
|
|
|
} /* end while */
|
|
|
|
|
|
|
|
ast_poll_channel_del(caller, chan);
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to free all the deferred frames, but we only need to
|
|
|
|
* queue the deferred frames if no hangup was received.
|
|
|
|
*/
|
|
|
|
ast_channel_lock(transferee);
|
|
|
|
transferee_hungup = (transferee_hungup || ast_check_hangup(transferee));
|
|
|
|
while ((f = AST_LIST_REMOVE_HEAD(&deferred_frames, frame_list))) {
|
|
|
|
if (!transferee_hungup) {
|
|
|
|
ast_queue_frame_head(transferee, f);
|
|
|
|
}
|
|
|
|
ast_frfree(f);
|
|
|
|
}
|
|
|
|
ast_channel_unlock(transferee);
|
|
|
|
|
2008-12-11 19:40:18 +00:00
|
|
|
done:
|
2005-06-23 22:12:01 +00:00
|
|
|
ast_indicate(caller, -1);
|
2012-02-20 23:43:27 +00:00
|
|
|
if (chan && (ready || ast_channel_state(chan) == AST_STATE_UP)) {
|
2011-01-25 23:31:40 +00:00
|
|
|
state = AST_CONTROL_ANSWER;
|
2008-12-11 19:40:18 +00:00
|
|
|
} else if (chan) {
|
2005-06-23 22:12:01 +00:00
|
|
|
ast_hangup(chan);
|
|
|
|
chan = NULL;
|
|
|
|
}
|
Merged revisions 302174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
Merged revisions 302173 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
Merged revisions 302172 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
Issues with DTMF triggered attended transfers.
Issue #17999
1) A calls B. B answers.
2) B using DTMF dial *2 (code in features.conf for attended transfer).
3) A hears MOH. B dial number C
4) C ringing. A hears MOH.
5) B hangup. A still hears MOH. C ringing.
6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
Problem: When A and B hangup, C is still ringing.
Issue #18395
SIP call limit of B is 1
1. A call B, B answered
2. B *2(atxfer) call C
3. B hangup, C ringing
4. Timeout waiting for C to answer
5. Recall to B fails because B has reached its call limit.
Because B reached its call limit, it cannot do anything until the transfer
it started completes.
Issue #17273
Same scenario as issue 18395 but party B is an FXS port. Party B cannot
do anything until the transfer it started completes. If B goes back off
hook before C answers, B hears ringback instead of the expected dialtone.
**********
Note for the issue #17273 and #18395 fix:
DTMF attended transfer works within the channel bridge. Unfortunately,
when either party A or B in the channel bridge hangs up, that channel is
not completely hung up until the transfer completes. This is a real
problem depending upon the channel technology involved.
For chan_dahdi, the channel is crippled until the hangup is complete.
Either the channel is not useable (analog) or the protocol disconnect
messages are held up (PRI/BRI/SS7) and the media is not released.
For chan_sip, a call limit of one is going to block that endpoint from any
further calls until the hangup is complete.
For party A this is a minor problem. The party A channel will only be in
this condition while party B is dialing and when party B and C are
conferring. The conversation between party B and C is expected to be a
short one. Party B is either asking a question of party C or announcing
party A. Also party A does not have much incentive to hangup at this
point.
For party B this can be a major problem during a blonde transfer. (A
blonde transfer is our term for an attended transfer that is converted
into a blind transfer. :)) Party B could be the operator. When party B
hangs up, he assumes that he is out of the original call entirely. The
party B channel will be in this condition while party C is ringing, while
attempting to recall party B, and while waiting between call attempts.
WARNING:
The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
replace the party B channel technology with a NULL channel driver to
complete hanging up the party B channel technology. The consequences of
this code is that the 'h' extension will not be able to access any channel
technology specific information like SIP statistics for the call.
ATXFER_NULL_TECH is not defined by default.
**********
(closes issue #17999)
Reported by: iskatel
Tested by: rmudgett
JIRA SWP-2246
(closes issue #17096)
Reported by: gelo
Tested by: rmudgett
JIRA SWP-1192
(closes issue #18395)
Reported by: shihchuan
Tested by: rmudgett
(closes issue #17273)
Reported by: grecco
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1047/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-01-18 18:17:01 +00:00
|
|
|
|
2011-02-03 16:22:10 +00:00
|
|
|
tmp_cap = ast_format_cap_destroy(tmp_cap);
|
|
|
|
|
2005-06-23 22:12:01 +00:00
|
|
|
if (outstate)
|
|
|
|
*outstate = state;
|
|
|
|
|
|
|
|
return chan;
|
|
|
|
}
|
|
|
|
|
2009-06-26 15:28:53 +00:00
|
|
|
void ast_channel_log(char *title, struct ast_channel *chan);
|
|
|
|
|
|
|
|
void ast_channel_log(char *title, struct ast_channel *chan) /* for debug, this is handy enough to justify keeping it in the source */
|
|
|
|
{
|
2012-01-13 18:52:53 +00:00
|
|
|
ast_log(LOG_NOTICE, "______ %s (%lx)______\n", title, (unsigned long) chan);
|
|
|
|
ast_log(LOG_NOTICE, "CHAN: name: %s; appl: %s; data: %s; contxt: %s; exten: %s; pri: %d;\n",
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_name(chan), ast_channel_appl(chan), ast_channel_data(chan), ast_channel_context(chan), ast_channel_exten(chan), ast_channel_priority(chan));
|
2012-01-13 18:52:53 +00:00
|
|
|
ast_log(LOG_NOTICE, "CHAN: acctcode: %s; dialcontext: %s; amaflags: %x; maccontxt: %s; macexten: %s; macpri: %d;\n",
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_accountcode(chan), ast_channel_dialcontext(chan), ast_channel_amaflags(chan), ast_channel_macrocontext(chan), ast_channel_macroexten(chan), ast_channel_macropriority(chan));
|
2012-01-13 18:52:53 +00:00
|
|
|
ast_log(LOG_NOTICE, "CHAN: masq: %p; masqr: %p; _bridge: %p; uniqueID: %s; linkedID:%s\n",
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_masq(chan), ast_channel_masqr(chan),
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_channel_internal_bridged_channel(chan), ast_channel_uniqueid(chan), ast_channel_linkedid(chan));
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_masqr(chan)) {
|
2012-01-13 18:52:53 +00:00
|
|
|
ast_log(LOG_NOTICE, "CHAN: masquerading as: %s; cdr: %p;\n",
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_name(ast_channel_masqr(chan)), ast_channel_cdr(ast_channel_masqr(chan)));
|
2012-01-13 18:52:53 +00:00
|
|
|
}
|
2012-03-13 18:20:34 +00:00
|
|
|
if (ast_channel_internal_bridged_channel(chan)) {
|
|
|
|
ast_log(LOG_NOTICE, "CHAN: Bridged to %s\n", ast_channel_name(ast_channel_internal_bridged_channel(chan)));
|
2012-01-13 18:52:53 +00:00
|
|
|
}
|
2009-06-26 15:28:53 +00:00
|
|
|
|
|
|
|
ast_log(LOG_NOTICE, "===== done ====\n");
|
|
|
|
}
|
|
|
|
|
Merged revisions 142575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-11 23:12:53 +00:00
|
|
|
/*!
|
|
|
|
* \brief return the first unlocked cdr in a possible chain
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
Merged revisions 142575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-11 23:12:53 +00:00
|
|
|
static struct ast_cdr *pick_unlocked_cdr(struct ast_cdr *cdr)
|
|
|
|
{
|
|
|
|
struct ast_cdr *cdr_orig = cdr;
|
|
|
|
while (cdr) {
|
|
|
|
if (!ast_test_flag(cdr,AST_CDR_FLAG_LOCKED))
|
|
|
|
return cdr;
|
|
|
|
cdr = cdr->next;
|
|
|
|
}
|
|
|
|
return cdr_orig; /* everybody LOCKED or some other weirdness, like a NULL */
|
|
|
|
}
|
|
|
|
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
static void set_bridge_features_on_config(struct ast_bridge_config *config, const char *features)
|
|
|
|
{
|
|
|
|
const char *feature;
|
|
|
|
|
|
|
|
if (ast_strlen_zero(features)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (feature = features; *feature; feature++) {
|
|
|
|
switch (*feature) {
|
|
|
|
case 'T' :
|
|
|
|
case 't' :
|
|
|
|
ast_set_flag(&(config->features_caller), AST_FEATURE_REDIRECT);
|
|
|
|
break;
|
|
|
|
case 'K' :
|
|
|
|
case 'k' :
|
|
|
|
ast_set_flag(&(config->features_caller), AST_FEATURE_PARKCALL);
|
|
|
|
break;
|
|
|
|
case 'H' :
|
|
|
|
case 'h' :
|
|
|
|
ast_set_flag(&(config->features_caller), AST_FEATURE_DISCONNECT);
|
|
|
|
break;
|
|
|
|
case 'W' :
|
|
|
|
case 'w' :
|
|
|
|
ast_set_flag(&(config->features_caller), AST_FEATURE_AUTOMON);
|
|
|
|
break;
|
|
|
|
default :
|
|
|
|
ast_log(LOG_WARNING, "Skipping unknown feature code '%c'\n", *feature);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void add_features_datastores(struct ast_channel *caller, struct ast_channel *callee, struct ast_bridge_config *config)
|
|
|
|
{
|
2012-04-25 01:26:44 +00:00
|
|
|
if (add_features_datastore(caller, &config->features_caller, &config->features_callee)) {
|
|
|
|
/*
|
|
|
|
* If we don't return here, then when we do a builtin_atxfer we
|
|
|
|
* will copy the disconnect flags over from the atxfer to the
|
|
|
|
* callee (Party C).
|
|
|
|
*/
|
2009-02-02 23:57:25 +00:00
|
|
|
return;
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
}
|
|
|
|
|
2012-04-25 01:26:44 +00:00
|
|
|
add_features_datastore(callee, &config->features_callee, &config->features_caller);
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
}
|
|
|
|
|
Merged revisions 315644 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r315644 | twilson | 2011-04-26 14:39:01 -0700 (Tue, 26 Apr 2011) | 32 lines
Merged revisions 315643 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r315643 | twilson | 2011-04-26 14:27:44 -0700 (Tue, 26 Apr 2011) | 25 lines
Merged revisions 315596 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r315596 | twilson | 2011-04-26 14:16:10 -0700 (Tue, 26 Apr 2011) | 18 lines
Allow transfer loops without allowing forwarding loops
We try to avoid the situation where two phones may be forwarded to each other
causing an infinite loop by storing each dialed interface in a channel
datastore and checking the list before dialing out. This works, but currently
breaks situations like A calls B, A transfers B to C, B transfers C to A, and A
transfers C to B. Since human interaction is happening here and not an
automated forwarding loop, it should be allowed.
This patch removes the dialed_interfaces datastore when a call is bridged (a
suggestion from the brilliant mmichelson). If a call is being bridged, it
should be safe to assume that we aren't stuck in a loop.
Since we are now handling this is the bridge code, the previous attempts at
handling it in app_dial and app_queue are removed.
Review: https://reviewboard.asterisk.org/r/1195/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-04-26 22:26:37 +00:00
|
|
|
static void clear_dialed_interfaces(struct ast_channel *chan)
|
|
|
|
{
|
|
|
|
struct ast_datastore *di_datastore;
|
|
|
|
|
|
|
|
ast_channel_lock(chan);
|
|
|
|
if ((di_datastore = ast_channel_datastore_find(chan, &dialed_interface_info, NULL))) {
|
|
|
|
if (option_debug) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_DEBUG, "Removing dialed interfaces datastore on %s since we're bridging\n", ast_channel_name(chan));
|
Merged revisions 315644 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r315644 | twilson | 2011-04-26 14:39:01 -0700 (Tue, 26 Apr 2011) | 32 lines
Merged revisions 315643 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r315643 | twilson | 2011-04-26 14:27:44 -0700 (Tue, 26 Apr 2011) | 25 lines
Merged revisions 315596 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r315596 | twilson | 2011-04-26 14:16:10 -0700 (Tue, 26 Apr 2011) | 18 lines
Allow transfer loops without allowing forwarding loops
We try to avoid the situation where two phones may be forwarded to each other
causing an infinite loop by storing each dialed interface in a channel
datastore and checking the list before dialing out. This works, but currently
breaks situations like A calls B, A transfers B to C, B transfers C to A, and A
transfers C to B. Since human interaction is happening here and not an
automated forwarding loop, it should be allowed.
This patch removes the dialed_interfaces datastore when a call is bridged (a
suggestion from the brilliant mmichelson). If a call is being bridged, it
should be safe to assume that we aren't stuck in a loop.
Since we are now handling this is the bridge code, the previous attempts at
handling it in app_dial and app_queue are removed.
Review: https://reviewboard.asterisk.org/r/1195/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-04-26 22:26:37 +00:00
|
|
|
}
|
|
|
|
if (!ast_channel_datastore_remove(chan, di_datastore)) {
|
|
|
|
ast_datastore_free(di_datastore);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ast_channel_unlock(chan);
|
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief bridge the call and set CDR
|
2011-08-09 23:17:13 +00:00
|
|
|
*
|
|
|
|
* \param chan The bridge considers this channel the caller.
|
|
|
|
* \param peer The bridge considers this channel the callee.
|
|
|
|
* \param config Configuration for this bridge.
|
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Set start time, check for two channels,check if monitor on
|
|
|
|
* check for feature activation, create new CDR
|
|
|
|
* \retval res on success.
|
|
|
|
* \retval -1 on failure to bridge.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2011-08-09 23:17:13 +00:00
|
|
|
int ast_bridge_call(struct ast_channel *chan, struct ast_channel *peer, struct ast_bridge_config *config)
|
2001-12-27 11:07:33 +00:00
|
|
|
{
|
|
|
|
/* Copy voice back and forth between the two channels. Give the peer
|
|
|
|
the ability to transfer calls with '#<extension' syntax. */
|
|
|
|
struct ast_frame *f;
|
|
|
|
struct ast_channel *who;
|
2005-01-04 04:01:40 +00:00
|
|
|
char chan_featurecode[FEATURE_MAX_LEN + 1]="";
|
|
|
|
char peer_featurecode[FEATURE_MAX_LEN + 1]="";
|
2011-05-20 17:04:53 +00:00
|
|
|
char orig_channame[AST_CHANNEL_NAME];
|
|
|
|
char orig_peername[AST_CHANNEL_NAME];
|
2001-12-27 11:07:33 +00:00
|
|
|
int res;
|
2004-08-06 13:54:07 +00:00
|
|
|
int diff;
|
2005-01-04 04:01:40 +00:00
|
|
|
int hasfeatures=0;
|
|
|
|
int hadfeatures=0;
|
2008-10-31 18:55:33 +00:00
|
|
|
int autoloopflag;
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
int sendingdtmfdigit = 0;
|
2010-12-09 21:26:19 +00:00
|
|
|
int we_disabled_peer_cdr = 0;
|
2001-12-27 11:07:33 +00:00
|
|
|
struct ast_option_header *aoh;
|
2008-07-03 17:16:44 +00:00
|
|
|
struct ast_cdr *bridge_cdr = NULL;
|
2012-02-20 23:43:27 +00:00
|
|
|
struct ast_cdr *chan_cdr = ast_channel_cdr(chan); /* the proper chan cdr, if there are forked cdrs */
|
|
|
|
struct ast_cdr *peer_cdr = ast_channel_cdr(peer); /* the proper chan cdr, if there are forked cdrs */
|
2008-09-23 16:52:32 +00:00
|
|
|
struct ast_cdr *new_chan_cdr = NULL; /* the proper chan cdr, if there are forked cdrs */
|
|
|
|
struct ast_cdr *new_peer_cdr = NULL; /* the proper chan cdr, if there are forked cdrs */
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
struct ast_silence_generator *silgen = NULL;
|
2011-05-13 16:30:29 +00:00
|
|
|
const char *h_context;
|
2004-09-17 03:49:57 +00:00
|
|
|
|
2012-01-13 18:52:53 +00:00
|
|
|
pbx_builtin_setvar_helper(chan, "BRIDGEPEER", ast_channel_name(peer));
|
|
|
|
pbx_builtin_setvar_helper(peer, "BRIDGEPEER", ast_channel_name(chan));
|
2008-12-15 14:40:24 +00:00
|
|
|
|
2012-02-23 20:14:54 +00:00
|
|
|
/* Clear any BLINDTRANSFER since the transfer has completed. */
|
|
|
|
pbx_builtin_setvar_helper(chan, "BLINDTRANSFER", NULL);
|
|
|
|
pbx_builtin_setvar_helper(peer, "BLINDTRANSFER", NULL);
|
|
|
|
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
set_bridge_features_on_config(config, pbx_builtin_getvar_helper(chan, "BRIDGE_FEATURES"));
|
|
|
|
add_features_datastores(chan, peer, config);
|
|
|
|
|
2008-12-15 14:40:24 +00:00
|
|
|
/* This is an interesting case. One example is if a ringing channel gets redirected to
|
|
|
|
* an extension that picks up a parked call. This will make sure that the call taken
|
|
|
|
* out of parking gets told that the channel it just got bridged to is still ringing. */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chan) == AST_STATE_RINGING && ast_channel_visible_indication(peer) != AST_CONTROL_RINGING) {
|
2008-12-15 14:40:24 +00:00
|
|
|
ast_indicate(peer, AST_CONTROL_RINGING);
|
|
|
|
}
|
2004-10-27 22:01:33 +00:00
|
|
|
|
2004-09-17 14:15:11 +00:00
|
|
|
if (monitor_ok) {
|
2005-12-03 19:25:33 +00:00
|
|
|
const char *monitor_exec;
|
|
|
|
struct ast_channel *src = NULL;
|
2009-04-08 21:00:39 +00:00
|
|
|
if (!monitor_app) {
|
2004-09-17 14:15:11 +00:00
|
|
|
if (!(monitor_app = pbx_findapp("Monitor")))
|
2004-09-17 03:49:57 +00:00
|
|
|
monitor_ok=0;
|
2004-09-17 14:15:11 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
if ((monitor_exec = pbx_builtin_getvar_helper(chan, "AUTO_MONITOR")))
|
2005-12-03 19:25:33 +00:00
|
|
|
src = chan;
|
2004-09-17 14:15:11 +00:00
|
|
|
else if ((monitor_exec = pbx_builtin_getvar_helper(peer, "AUTO_MONITOR")))
|
2005-12-03 19:25:33 +00:00
|
|
|
src = peer;
|
2006-01-17 18:20:33 +00:00
|
|
|
if (monitor_app && src) {
|
2005-12-03 19:25:33 +00:00
|
|
|
char *tmp = ast_strdupa(monitor_exec);
|
2006-05-10 13:22:15 +00:00
|
|
|
pbx_exec(src, monitor_app, tmp);
|
2005-12-03 19:25:33 +00:00
|
|
|
}
|
2004-09-17 03:49:57 +00:00
|
|
|
}
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
|
2012-01-13 18:52:53 +00:00
|
|
|
set_config_flags(chan, config);
|
2003-07-02 14:06:12 +00:00
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
/* Answer if need be */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chan) != AST_STATE_UP) {
|
Improve behavior of ast_answer() to not lose incoming frames
ast_answer(), when supplied a delay before returning to the caller, use ast_safe_sleep() to implement the delay. Unfortunately during this time any incoming frames are discarded, which is problematic for T.38 re-INVITES and other sorts of channel operations.
When a delay is not passed to ast_answer(), it still delays for up to 500 milliseconds, waiting for media to arrive. Again, though, it discards any control frames, or non-voice media frames.
This patch rectifies this situation, by storing all incoming frames during the delay period on a list, and then requeuing them onto the channel before returning to the caller.
http://reviewboard.digium.com/r/196/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-03-17 14:38:11 +00:00
|
|
|
if (ast_raw_answer(chan, 1)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
2007-03-30 14:37:21 +00:00
|
|
|
|
2009-06-26 15:28:53 +00:00
|
|
|
#ifdef FOR_DEBUG
|
|
|
|
/* show the two channels and cdrs involved in the bridge for debug & devel purposes */
|
|
|
|
ast_channel_log("Pre-bridge CHAN Channel info", chan);
|
|
|
|
ast_channel_log("Pre-bridge PEER Channel info", peer);
|
|
|
|
#endif
|
|
|
|
/* two channels are being marked as linked here */
|
|
|
|
ast_channel_set_linkgroup(chan,peer);
|
|
|
|
|
|
|
|
/* copy the userfield from the B-leg to A-leg if applicable */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_cdr(chan) && ast_channel_cdr(peer) && !ast_strlen_zero(ast_channel_cdr(peer)->userfield)) {
|
2009-06-26 15:28:53 +00:00
|
|
|
char tmp[256];
|
2011-12-16 21:10:19 +00:00
|
|
|
|
|
|
|
ast_channel_lock(chan);
|
2012-02-20 23:43:27 +00:00
|
|
|
if (!ast_strlen_zero(ast_channel_cdr(chan)->userfield)) {
|
|
|
|
snprintf(tmp, sizeof(tmp), "%s;%s", ast_channel_cdr(chan)->userfield, ast_channel_cdr(peer)->userfield);
|
2009-06-26 15:28:53 +00:00
|
|
|
ast_cdr_appenduserfield(chan, tmp);
|
2011-12-16 21:10:19 +00:00
|
|
|
} else {
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_cdr_setuserfield(chan, ast_channel_cdr(peer)->userfield);
|
2011-12-16 21:10:19 +00:00
|
|
|
}
|
|
|
|
ast_channel_unlock(chan);
|
2010-12-09 21:26:19 +00:00
|
|
|
/* Don't delete the CDR; just disable it. */
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_set_flag(ast_channel_cdr(peer), AST_CDR_FLAG_POST_DISABLED);
|
2010-12-09 21:26:19 +00:00
|
|
|
we_disabled_peer_cdr = 1;
|
2009-06-26 15:28:53 +00:00
|
|
|
}
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_copy_string(orig_channame,ast_channel_name(chan),sizeof(orig_channame));
|
|
|
|
ast_copy_string(orig_peername,ast_channel_name(peer),sizeof(orig_peername));
|
2011-05-03 20:45:32 +00:00
|
|
|
|
Merged revisions 142575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-11 23:12:53 +00:00
|
|
|
if (!chan_cdr || (chan_cdr && !ast_test_flag(chan_cdr, AST_CDR_FLAG_POST_DISABLED))) {
|
2011-12-16 21:10:19 +00:00
|
|
|
ast_channel_lock_both(chan, peer);
|
Merged revisions 142575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-11 23:12:53 +00:00
|
|
|
if (chan_cdr) {
|
|
|
|
ast_set_flag(chan_cdr, AST_CDR_FLAG_MAIN);
|
2008-07-03 17:16:44 +00:00
|
|
|
ast_cdr_update(chan);
|
2009-11-03 21:21:09 +00:00
|
|
|
bridge_cdr = ast_cdr_dup_unique_swap(chan_cdr);
|
2010-04-19 17:57:41 +00:00
|
|
|
/* rip any forked CDR's off of the chan_cdr and attach
|
|
|
|
* them to the bridge_cdr instead */
|
|
|
|
bridge_cdr->next = chan_cdr->next;
|
|
|
|
chan_cdr->next = NULL;
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_copy_string(bridge_cdr->lastapp, S_OR(ast_channel_appl(chan), ""), sizeof(bridge_cdr->lastapp));
|
|
|
|
ast_copy_string(bridge_cdr->lastdata, S_OR(ast_channel_data(chan), ""), sizeof(bridge_cdr->lastdata));
|
2009-11-20 21:01:10 +00:00
|
|
|
if (peer_cdr && !ast_strlen_zero(peer_cdr->userfield)) {
|
|
|
|
ast_copy_string(bridge_cdr->userfield, peer_cdr->userfield, sizeof(bridge_cdr->userfield));
|
|
|
|
}
|
2012-01-24 20:12:09 +00:00
|
|
|
ast_cdr_setaccount(peer, ast_channel_accountcode(chan));
|
2008-07-03 17:16:44 +00:00
|
|
|
} else {
|
|
|
|
/* better yet, in a xfer situation, find out why the chan cdr got zapped (pun unintentional) */
|
|
|
|
bridge_cdr = ast_cdr_alloc(); /* this should be really, really rare/impossible? */
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_copy_string(bridge_cdr->channel, ast_channel_name(chan), sizeof(bridge_cdr->channel));
|
|
|
|
ast_copy_string(bridge_cdr->dstchannel, ast_channel_name(peer), sizeof(bridge_cdr->dstchannel));
|
2012-01-24 20:12:09 +00:00
|
|
|
ast_copy_string(bridge_cdr->uniqueid, ast_channel_uniqueid(chan), sizeof(bridge_cdr->uniqueid));
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_copy_string(bridge_cdr->lastapp, S_OR(ast_channel_appl(chan), ""), sizeof(bridge_cdr->lastapp));
|
|
|
|
ast_copy_string(bridge_cdr->lastdata, S_OR(ast_channel_data(chan), ""), sizeof(bridge_cdr->lastdata));
|
2008-07-03 17:16:44 +00:00
|
|
|
ast_cdr_setcid(bridge_cdr, chan);
|
2012-02-20 23:43:27 +00:00
|
|
|
bridge_cdr->disposition = (ast_channel_state(chan) == AST_STATE_UP) ? AST_CDR_ANSWERED : AST_CDR_NULL;
|
|
|
|
bridge_cdr->amaflags = ast_channel_amaflags(chan) ? ast_channel_amaflags(chan) : ast_default_amaflags;
|
2012-01-24 20:12:09 +00:00
|
|
|
ast_copy_string(bridge_cdr->accountcode, ast_channel_accountcode(chan), sizeof(bridge_cdr->accountcode));
|
2008-07-03 17:16:44 +00:00
|
|
|
/* Destination information */
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_copy_string(bridge_cdr->dst, ast_channel_exten(chan), sizeof(bridge_cdr->dst));
|
|
|
|
ast_copy_string(bridge_cdr->dcontext, ast_channel_context(chan), sizeof(bridge_cdr->dcontext));
|
Merged revisions 142575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-11 23:12:53 +00:00
|
|
|
if (peer_cdr) {
|
|
|
|
bridge_cdr->start = peer_cdr->start;
|
|
|
|
ast_copy_string(bridge_cdr->userfield, peer_cdr->userfield, sizeof(bridge_cdr->userfield));
|
2008-07-03 17:16:44 +00:00
|
|
|
} else {
|
|
|
|
ast_cdr_start(bridge_cdr);
|
|
|
|
}
|
|
|
|
}
|
2011-12-16 21:10:19 +00:00
|
|
|
ast_channel_unlock(chan);
|
|
|
|
ast_channel_unlock(peer);
|
|
|
|
|
2011-02-04 16:55:39 +00:00
|
|
|
ast_debug(4, "bridge answer set, chan answer set\n");
|
Merged revisions 142575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-11 23:12:53 +00:00
|
|
|
/* peer_cdr->answer will be set when a macro runs on the peer;
|
Merged revisions 135799 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-08-05 23:45:32 +00:00
|
|
|
in that case, the bridge answer will be delayed while the
|
|
|
|
macro plays on the peer channel. The peer answered the call
|
|
|
|
before the macro started playing. To the phone system,
|
|
|
|
this is billable time for the call, even tho the caller
|
|
|
|
hears nothing but ringing while the macro does its thing. */
|
2009-06-25 21:04:55 +00:00
|
|
|
|
|
|
|
/* Another case where the peer cdr's time will be set, is when
|
|
|
|
A self-parks by pickup up phone and dialing 700, then B
|
2012-03-22 19:51:16 +00:00
|
|
|
picks up A by dialing its parking slot; there may be more
|
2009-06-25 21:04:55 +00:00
|
|
|
practical paths that get the same result, tho... in which
|
|
|
|
case you get the previous answer time from the Park... which
|
2012-03-22 19:51:16 +00:00
|
|
|
is before the bridge's start time, so I added in the
|
2009-06-25 21:04:55 +00:00
|
|
|
tvcmp check to the if below */
|
|
|
|
|
2009-08-20 20:29:32 +00:00
|
|
|
if (peer_cdr && !ast_tvzero(peer_cdr->answer) && ast_tvcmp(peer_cdr->answer, bridge_cdr->start) >= 0) {
|
2010-04-19 17:57:41 +00:00
|
|
|
ast_cdr_setanswer(bridge_cdr, peer_cdr->answer);
|
|
|
|
ast_cdr_setdisposition(bridge_cdr, peer_cdr->disposition);
|
2009-05-20 17:33:02 +00:00
|
|
|
if (chan_cdr) {
|
2010-04-19 17:57:41 +00:00
|
|
|
ast_cdr_setanswer(chan_cdr, peer_cdr->answer);
|
|
|
|
ast_cdr_setdisposition(chan_cdr, peer_cdr->disposition);
|
2009-05-20 17:33:02 +00:00
|
|
|
}
|
Merged revisions 135799 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-08-05 23:45:32 +00:00
|
|
|
} else {
|
|
|
|
ast_cdr_answer(bridge_cdr);
|
2009-05-20 17:33:02 +00:00
|
|
|
if (chan_cdr) {
|
|
|
|
ast_cdr_answer(chan_cdr); /* for the sake of cli status checks */
|
|
|
|
}
|
Merged revisions 135799 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-08-05 23:45:32 +00:00
|
|
|
}
|
2012-03-13 18:20:34 +00:00
|
|
|
if (ast_test_flag(ast_channel_flags(chan), AST_FLAG_BRIDGE_HANGUP_DONT) && (chan_cdr || peer_cdr)) {
|
2009-05-20 17:33:02 +00:00
|
|
|
if (chan_cdr) {
|
|
|
|
ast_set_flag(chan_cdr, AST_CDR_FLAG_BRIDGED);
|
|
|
|
}
|
Merged revisions 172030 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines
This patch fixes h-exten running misbehavior in manager-redirected
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-28 20:31:06 +00:00
|
|
|
if (peer_cdr) {
|
|
|
|
ast_set_flag(peer_cdr, AST_CDR_FLAG_BRIDGED);
|
|
|
|
}
|
Merged revisions 134883 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134883 | murf | 2008-07-31 13:23:42 -0600 (Thu, 31 Jul 2008) | 51 lines
(closes issue #11849)
Reported by: greyvoip
Tested by: murf
OK, a few days of debugging, a bunch of instrumentation
in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid
notebook pages of notes later, I have made the small
tweek necc. to get the start time right on the second
CDR when:
A Calls B
B answ.
A hits Xfer button on sip phone,
A dials C and hits the OK button,
A hangs up
C answers ringing phone
B and C converse
B and/or C hangs up
But does not harm the scenario where:
A Calls B
B answ.
B hits xfer button on sip phone,
B dials C and hits the OK button,
B hangs up
C answers ringing phone
A and C converse
A and/or C hangs up
The difference in start times on the second CDR is because
of a Masquerade on the B channel when the xfer number is
sent. It ends up replacing the CDR on the B channel with
a duplicate, which ends up getting tossed out. We keep
a pointer to the first CDR, and update *that* after the
bridge closes. But, only if the CDR has changed.
I hope this change is specific enough not to muck
up any current CDR-based apps. In my defence, I
assert that the previous information was wrong,
and this change fixes it, and possibly other
similar scenarios.
I wonder if I should be doing the same thing
for the channel, as I did for the peer, but
I can't think of a scenario this might affect.
I leave it, then, as an exersize for the users,
to find the scenario where the chan's CDR
changes and loses the proper start time.
........
and as to 1.4 to trunk; have I expressed my
feelings about code shifting from one file
to another? Good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134922 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-31 19:48:08 +00:00
|
|
|
}
|
2010-04-22 21:57:59 +00:00
|
|
|
/* the DIALED flag may be set if a dialed channel is transfered
|
|
|
|
* and then bridged to another channel. In order for the
|
|
|
|
* bridge CDR to be written, the DIALED flag must not be
|
|
|
|
* present. */
|
|
|
|
ast_clear_flag(bridge_cdr, AST_CDR_FLAG_DIALED);
|
2008-07-03 17:16:44 +00:00
|
|
|
}
|
2012-01-12 16:10:47 +00:00
|
|
|
ast_cel_report_event(chan, AST_CEL_BRIDGE_START, NULL, NULL, peer);
|
Merged revisions 315644 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r315644 | twilson | 2011-04-26 14:39:01 -0700 (Tue, 26 Apr 2011) | 32 lines
Merged revisions 315643 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r315643 | twilson | 2011-04-26 14:27:44 -0700 (Tue, 26 Apr 2011) | 25 lines
Merged revisions 315596 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r315596 | twilson | 2011-04-26 14:16:10 -0700 (Tue, 26 Apr 2011) | 18 lines
Allow transfer loops without allowing forwarding loops
We try to avoid the situation where two phones may be forwarded to each other
causing an infinite loop by storing each dialed interface in a channel
datastore and checking the list before dialing out. This works, but currently
breaks situations like A calls B, A transfers B to C, B transfers C to A, and A
transfers C to B. Since human interaction is happening here and not an
automated forwarding loop, it should be allowed.
This patch removes the dialed_interfaces datastore when a call is bridged (a
suggestion from the brilliant mmichelson). If a call is being bridged, it
should be safe to assume that we aren't stuck in a loop.
Since we are now handling this is the bridge code, the previous attempts at
handling it in app_dial and app_queue are removed.
Review: https://reviewboard.asterisk.org/r/1195/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-04-26 22:26:37 +00:00
|
|
|
|
|
|
|
/* If we are bridging a call, stop worrying about forwarding loops. We presume that if
|
|
|
|
* a call is being bridged, that the humans in charge know what they're doing. If they
|
|
|
|
* don't, well, what can we do about that? */
|
|
|
|
clear_dialed_interfaces(chan);
|
|
|
|
clear_dialed_interfaces(peer);
|
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
for (;;) {
|
2006-04-14 23:20:29 +00:00
|
|
|
struct ast_channel *other; /* used later */
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2005-07-25 17:31:53 +00:00
|
|
|
res = ast_channel_bridge(chan, peer, config, &f, &who);
|
2011-05-20 16:46:02 +00:00
|
|
|
|
2012-03-13 18:20:34 +00:00
|
|
|
if (ast_test_flag(ast_channel_flags(chan), AST_FLAG_ZOMBIE)
|
|
|
|
|| ast_test_flag(ast_channel_flags(peer), AST_FLAG_ZOMBIE)) {
|
2011-05-20 16:46:02 +00:00
|
|
|
/* Zombies are present time to leave! */
|
|
|
|
res = -1;
|
|
|
|
if (f) {
|
|
|
|
ast_frfree(f);
|
|
|
|
}
|
|
|
|
goto before_you_go;
|
|
|
|
}
|
|
|
|
|
Merged revisions 178804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
This patch prevents the feature detection timeout from being cut in half.
Because the ast_channel_bridge() call will return 0 and pass
a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
field in hte config struct is getting decremented twice, which
effectively cuts the digittimeout in half. I added conditions
to the if statement to only let DTMF_END frames to flow thru,
which solved the problem. Also, when the frame pointer is null,
let control flow thru-- this usually happens on timeouts. I added
a comment to the code to explain what's going on and why.
Many thanks to sodom for reporting this problem. Personnally, it always seemed
like something was wrong with the featuredigittimeout, but I never
could quite decide what... and was too busy to investigate.
This bug forced the issue, and now we know.
Sodom had other issues in 14515, but I couldn't reproduce them. If
he still has problems, and wants to get them solved, he is welcome
to reopen 14515.
(closes issue #14515)
Reported by: sodom
Patches:
14515.patch uploaded by murf (license 17)
Tested by: murf, sodom
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-26 17:22:11 +00:00
|
|
|
/* When frame is not set, we are probably involved in a situation
|
|
|
|
where we've timed out.
|
|
|
|
When frame is set, we'll come this code twice; once for DTMF_BEGIN
|
2012-03-22 19:51:16 +00:00
|
|
|
and also for DTMF_END. If we flow into the following 'if' for both, then
|
Merged revisions 178804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
This patch prevents the feature detection timeout from being cut in half.
Because the ast_channel_bridge() call will return 0 and pass
a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
field in hte config struct is getting decremented twice, which
effectively cuts the digittimeout in half. I added conditions
to the if statement to only let DTMF_END frames to flow thru,
which solved the problem. Also, when the frame pointer is null,
let control flow thru-- this usually happens on timeouts. I added
a comment to the code to explain what's going on and why.
Many thanks to sodom for reporting this problem. Personnally, it always seemed
like something was wrong with the featuredigittimeout, but I never
could quite decide what... and was too busy to investigate.
This bug forced the issue, and now we know.
Sodom had other issues in 14515, but I couldn't reproduce them. If
he still has problems, and wants to get them solved, he is welcome
to reopen 14515.
(closes issue #14515)
Reported by: sodom
Patches:
14515.patch uploaded by murf (license 17)
Tested by: murf, sodom
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-26 17:22:11 +00:00
|
|
|
our wait times are cut in half, as both will subtract from the
|
|
|
|
feature_timer. Not good!
|
|
|
|
*/
|
|
|
|
if (config->feature_timer && (!f || f->frametype == AST_FRAME_DTMF_END)) {
|
2009-04-08 21:00:39 +00:00
|
|
|
/* Update feature timer for next pass */
|
|
|
|
diff = ast_tvdiff_ms(ast_tvnow(), config->feature_start_time);
|
2009-02-17 22:08:00 +00:00
|
|
|
if (res == AST_BRIDGE_RETRY) {
|
|
|
|
/* The feature fully timed out but has not been updated. Skip
|
|
|
|
* the potential round error from the diff calculation and
|
|
|
|
* explicitly set to expired. */
|
|
|
|
config->feature_timer = -1;
|
|
|
|
} else {
|
|
|
|
config->feature_timer -= diff;
|
|
|
|
}
|
|
|
|
|
2005-01-04 04:01:40 +00:00
|
|
|
if (hasfeatures) {
|
2009-04-08 21:00:39 +00:00
|
|
|
if (config->feature_timer <= 0) {
|
2005-01-04 04:01:40 +00:00
|
|
|
/* Not *really* out of time, just out of time for
|
|
|
|
digits to come in for features. */
|
2007-06-14 19:39:12 +00:00
|
|
|
ast_debug(1, "Timed out for feature!\n");
|
2005-01-04 04:01:40 +00:00
|
|
|
if (!ast_strlen_zero(peer_featurecode)) {
|
2011-10-24 22:09:11 +00:00
|
|
|
ast_dtmf_stream(chan, peer, peer_featurecode, 0, f ? f->len : 0);
|
2005-01-04 04:01:40 +00:00
|
|
|
memset(peer_featurecode, 0, sizeof(peer_featurecode));
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(chan_featurecode)) {
|
2011-10-24 22:09:11 +00:00
|
|
|
ast_dtmf_stream(peer, chan, chan_featurecode, 0, f ? f->len : 0);
|
2005-01-04 04:01:40 +00:00
|
|
|
memset(chan_featurecode, 0, sizeof(chan_featurecode));
|
|
|
|
}
|
|
|
|
if (f)
|
|
|
|
ast_frfree(f);
|
|
|
|
hasfeatures = !ast_strlen_zero(chan_featurecode) || !ast_strlen_zero(peer_featurecode);
|
|
|
|
if (!hasfeatures) {
|
2009-04-08 21:00:39 +00:00
|
|
|
/* No more digits expected - reset the timer */
|
|
|
|
config->feature_timer = 0;
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
|
|
|
hadfeatures = hasfeatures;
|
|
|
|
/* Continue as we were */
|
|
|
|
continue;
|
Merged revisions 43779 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r43779 | russell | 2006-09-27 12:55:49 -0400 (Wed, 27 Sep 2006) | 50 lines
Merged revisions 43778 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43778 | russell | 2006-09-27 12:54:30 -0400 (Wed, 27 Sep 2006) | 42 lines
Fix a problem that occurred if a user entered a digit that matched a bridge
feature that was configured using multiple digits, and the digit that was
pressed timed out in the feature digit timeout period. For example, if blind
transfer is configured as '##', and a user presses just '#'. In this situation,
the call would lock up and no longer pass any frames.
(issue #7977 reported by festr, and issue #7982 reported by michaels and
valuable input provided by mneuhauser and kuj. Fixed by me, with testing help
and peer review from Joshua Colp).
There are a couple of issues involved in this fix:
1) When ast_generic_bridge determines that there has been a timeout, it returned
AST_BRIDGE_RETRY. Then, when ast_channel_bridge gets this result, it calls
ast_generic_bridge over again with the same timestamp for the next event.
This results in an endless loop of nothing until the call is terminated.
This is resolved by simply changing ast_generic_bridge to return
AST_BRIDGE_COMPLETE when it sees a timeout.
2) I also changed ast_channel_bridge such that if in the process of calculating
the time until the next event, it knows a timeout has already occured, to
immediately return AST_BRIDGE_COMPLETE instead of attempting to bridge the
channels anyway.
3) In the process of testing the previous two changes, I ran into a problem in
res_features where ast_channel_bridge would return because it determined
that there was a timeout. However, ast_bridge_call in res_features would
then determine by its own calculation that there was still 1 ms before the
timeout really occurs. It would then proceed, and since the bridge broke
out and did *not* return a frame, it interpreted this as the call was over
and hung up the channels.
The reason for this was because ast_bridge_call in res_features and
ast_channel_bridge in channel.c were using different times for their
calculations. channel.c uses the start_time on the bridge config, which
is the time that the feature digit was recieved. However, res_features
had another time, 'start', which was set right before calling
ast_channel_bridge. 'start' will always be slightly after start_time in the
bridge config, and sometimes enough to round up to one ms.
This is fixed by making ast_bridge_call use the same time as
ast_channel_bridge for the timeout calculation.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@43780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-09-27 16:57:44 +00:00
|
|
|
} else if (!f) {
|
|
|
|
/* The bridge returned without a frame and there is a feature in progress.
|
|
|
|
* However, we don't think the feature has quite yet timed out, so just
|
|
|
|
* go back into the bridge. */
|
|
|
|
continue;
|
2012-03-22 19:51:16 +00:00
|
|
|
}
|
2005-01-04 04:01:40 +00:00
|
|
|
} else {
|
2005-08-03 04:42:59 +00:00
|
|
|
if (config->feature_timer <=0) {
|
2005-01-04 04:01:40 +00:00
|
|
|
/* We ran out of time */
|
2005-08-03 04:42:59 +00:00
|
|
|
config->feature_timer = 0;
|
2005-01-04 04:01:40 +00:00
|
|
|
who = chan;
|
|
|
|
if (f)
|
|
|
|
ast_frfree(f);
|
|
|
|
f = NULL;
|
|
|
|
res = 0;
|
|
|
|
}
|
2004-08-06 13:54:07 +00:00
|
|
|
}
|
|
|
|
}
|
2001-12-27 11:07:33 +00:00
|
|
|
if (res < 0) {
|
2012-03-13 18:20:34 +00:00
|
|
|
if (!ast_test_flag(ast_channel_flags(chan), AST_FLAG_ZOMBIE) && !ast_test_flag(ast_channel_flags(peer), AST_FLAG_ZOMBIE) && !ast_check_hangup(chan) && !ast_check_hangup(peer)) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Bridge failed on channels %s and %s\n", ast_channel_name(chan), ast_channel_name(peer));
|
2009-04-08 21:00:39 +00:00
|
|
|
}
|
Merged revisions 135799 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-08-05 23:45:32 +00:00
|
|
|
goto before_you_go;
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2006-04-16 18:37:01 +00:00
|
|
|
if (!f || (f->frametype == AST_FRAME_CONTROL &&
|
2009-11-04 14:05:12 +00:00
|
|
|
(f->subclass.integer == AST_CONTROL_HANGUP || f->subclass.integer == AST_CONTROL_BUSY ||
|
|
|
|
f->subclass.integer == AST_CONTROL_CONGESTION))) {
|
2012-01-23 20:29:48 +00:00
|
|
|
/*
|
2012-01-23 20:31:11 +00:00
|
|
|
* If the bridge was broken for a hangup that isn't real,
|
2012-01-23 20:29:48 +00:00
|
|
|
* then don't run the h extension, because the channel isn't
|
|
|
|
* really hung up. This should really only happen with AST_SOFTHANGUP_ASYNCGOTO,
|
|
|
|
* but it doesn't hurt to check AST_SOFTHANGUP_UNBRIDGE either.
|
|
|
|
*/
|
|
|
|
ast_channel_lock(chan);
|
2012-03-01 22:09:18 +00:00
|
|
|
if (ast_channel_softhangup_internal_flag(chan) & (AST_SOFTHANGUP_ASYNCGOTO | AST_SOFTHANGUP_UNBRIDGE)) {
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_set_flag(ast_channel_flags(chan), AST_FLAG_BRIDGE_HANGUP_DONT);
|
2012-01-23 20:29:48 +00:00
|
|
|
}
|
|
|
|
ast_channel_unlock(chan);
|
2006-04-16 18:37:01 +00:00
|
|
|
res = -1;
|
|
|
|
break;
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2006-04-14 23:20:29 +00:00
|
|
|
/* many things should be sent to the 'other' channel */
|
|
|
|
other = (who == chan) ? peer : chan;
|
|
|
|
if (f->frametype == AST_FRAME_CONTROL) {
|
2009-11-04 14:05:12 +00:00
|
|
|
switch (f->subclass.integer) {
|
2007-07-05 20:51:08 +00:00
|
|
|
case AST_CONTROL_RINGING:
|
|
|
|
case AST_CONTROL_FLASH:
|
2011-02-07 23:33:44 +00:00
|
|
|
case AST_CONTROL_MCID:
|
2007-07-05 20:51:08 +00:00
|
|
|
case -1:
|
2009-11-04 14:05:12 +00:00
|
|
|
ast_indicate(other, f->subclass.integer);
|
2007-07-05 20:51:08 +00:00
|
|
|
break;
|
2009-06-01 20:57:31 +00:00
|
|
|
case AST_CONTROL_CONNECTED_LINE:
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(who, other, f, 1) &&
|
|
|
|
ast_channel_connected_line_macro(who, other, f, who != chan, 1)) {
|
|
|
|
ast_indicate_data(other, f->subclass.integer, f->data.ptr, f->datalen);
|
2009-06-01 20:57:31 +00:00
|
|
|
}
|
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
|
|
|
break;
|
|
|
|
case AST_CONTROL_REDIRECTING:
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_redirecting_sub(who, other, f, 1) &&
|
|
|
|
ast_channel_redirecting_macro(who, other, f, who != chan, 1)) {
|
|
|
|
ast_indicate_data(other, f->subclass.integer, f->data.ptr, f->datalen);
|
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
|
|
|
}
|
|
|
|
break;
|
Generic Advice of Charge.
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-02 18:10:15 +00:00
|
|
|
case AST_CONTROL_AOC:
|
2007-07-05 20:51:08 +00:00
|
|
|
case AST_CONTROL_HOLD:
|
|
|
|
case AST_CONTROL_UNHOLD:
|
2009-11-04 14:05:12 +00:00
|
|
|
ast_indicate_data(other, f->subclass.integer, f->data.ptr, f->datalen);
|
2007-07-05 20:51:08 +00:00
|
|
|
break;
|
|
|
|
case AST_CONTROL_OPTION:
|
2008-05-22 16:29:54 +00:00
|
|
|
aoh = f->data.ptr;
|
2011-06-23 18:26:09 +00:00
|
|
|
/* Forward option Requests, but only ones we know are safe
|
|
|
|
* These are ONLY sent by chan_iax2 and I'm not convinced that
|
|
|
|
* they are useful. I haven't deleted them entirely because I
|
|
|
|
* just am not sure of the ramifications of removing them. */
|
2007-07-05 20:51:08 +00:00
|
|
|
if (aoh && aoh->flag == AST_OPTION_FLAG_REQUEST) {
|
2012-03-22 19:51:16 +00:00
|
|
|
switch (ntohs(aoh->option)) {
|
2011-06-23 18:26:09 +00:00
|
|
|
case AST_OPTION_TONE_VERIFY:
|
|
|
|
case AST_OPTION_TDD:
|
|
|
|
case AST_OPTION_RELAXDTMF:
|
|
|
|
case AST_OPTION_AUDIO_MODE:
|
|
|
|
case AST_OPTION_DIGIT_DETECT:
|
|
|
|
case AST_OPTION_FAX_DETECT:
|
2012-03-22 19:51:16 +00:00
|
|
|
ast_channel_setoption(other, ntohs(aoh->option), aoh->data,
|
2011-06-23 18:26:09 +00:00
|
|
|
f->datalen - sizeof(struct ast_option_header), 0);
|
|
|
|
}
|
2007-07-05 20:51:08 +00:00
|
|
|
}
|
|
|
|
break;
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2006-08-31 01:59:02 +00:00
|
|
|
} else if (f->frametype == AST_FRAME_DTMF_BEGIN) {
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
struct ast_flags *cfg;
|
|
|
|
char dtmfcode[2] = { f->subclass.integer, };
|
|
|
|
size_t featurelen;
|
|
|
|
|
|
|
|
if (who == chan) {
|
|
|
|
featurelen = strlen(chan_featurecode);
|
|
|
|
cfg = &(config->features_caller);
|
|
|
|
} else {
|
|
|
|
featurelen = strlen(peer_featurecode);
|
|
|
|
cfg = &(config->features_callee);
|
|
|
|
}
|
|
|
|
/* Take a peek if this (possibly) matches a feature. If not, just pass this
|
|
|
|
* DTMF along untouched. If this is not the first digit of a multi-digit code
|
|
|
|
* then we need to fall through and stream the characters if it matches */
|
|
|
|
if (featurelen == 0
|
|
|
|
&& feature_check(chan, cfg, &dtmfcode[0]) == AST_FEATURE_RETURN_PASSDIGITS) {
|
|
|
|
if (option_debug > 3) {
|
|
|
|
ast_log(LOG_DEBUG, "Passing DTMF through, since it is not a feature code\n");
|
|
|
|
}
|
|
|
|
ast_write(other, f);
|
|
|
|
sendingdtmfdigit = 1;
|
|
|
|
} else {
|
|
|
|
/* If ast_opt_transmit_silence is set, then we need to make sure we are
|
|
|
|
* transmitting something while we hold on to the DTMF waiting for a
|
|
|
|
* feature. */
|
|
|
|
if (!silgen && ast_opt_transmit_silence) {
|
|
|
|
silgen = ast_channel_start_silence_generator(other);
|
|
|
|
}
|
|
|
|
if (option_debug > 3) {
|
|
|
|
ast_log(LOG_DEBUG, "Not passing DTMF through, since it may be a feature code\n");
|
|
|
|
}
|
|
|
|
}
|
2011-05-20 17:04:53 +00:00
|
|
|
} else if (f->frametype == AST_FRAME_DTMF_END) {
|
2005-01-04 04:01:40 +00:00
|
|
|
char *featurecode;
|
|
|
|
int sense;
|
2011-09-30 13:21:17 +00:00
|
|
|
unsigned int dtmfduration = f->len;
|
2005-07-25 17:31:53 +00:00
|
|
|
|
2005-01-04 04:01:40 +00:00
|
|
|
hadfeatures = hasfeatures;
|
|
|
|
/* This cannot overrun because the longest feature is one shorter than our buffer */
|
|
|
|
if (who == chan) {
|
|
|
|
sense = FEATURE_SENSE_CHAN;
|
|
|
|
featurecode = chan_featurecode;
|
|
|
|
} else {
|
|
|
|
sense = FEATURE_SENSE_PEER;
|
|
|
|
featurecode = peer_featurecode;
|
|
|
|
}
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
|
|
|
|
if (sendingdtmfdigit == 1) {
|
|
|
|
/* We let the BEGIN go through happily, so let's not bother with the END,
|
|
|
|
* since we already know it's not something we bother with */
|
|
|
|
ast_write(other, f);
|
|
|
|
sendingdtmfdigit = 0;
|
2009-04-08 21:00:39 +00:00
|
|
|
} else {
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
/*! append the event to featurecode. we rely on the string being zero-filled, and
|
2012-03-22 19:51:16 +00:00
|
|
|
* not overflowing it.
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
* \todo XXX how do we guarantee the latter ?
|
|
|
|
*/
|
|
|
|
featurecode[strlen(featurecode)] = f->subclass.integer;
|
|
|
|
/* Get rid of the frame before we start doing "stuff" with the channels */
|
|
|
|
ast_frfree(f);
|
|
|
|
f = NULL;
|
|
|
|
if (silgen) {
|
|
|
|
ast_channel_stop_silence_generator(other, silgen);
|
|
|
|
silgen = NULL;
|
|
|
|
}
|
2009-04-08 21:00:39 +00:00
|
|
|
config->feature_timer = 0;
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
res = feature_interpret(chan, peer, config, featurecode, sense);
|
|
|
|
switch(res) {
|
|
|
|
case AST_FEATURE_RETURN_PASSDIGITS:
|
2011-09-30 13:21:17 +00:00
|
|
|
ast_dtmf_stream(other, who, featurecode, 0, dtmfduration);
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
/* Fall through */
|
|
|
|
case AST_FEATURE_RETURN_SUCCESS:
|
|
|
|
memset(featurecode, 0, sizeof(chan_featurecode));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (res >= AST_FEATURE_RETURN_PASSDIGITS) {
|
|
|
|
res = 0;
|
|
|
|
} else {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
hasfeatures = !ast_strlen_zero(chan_featurecode) || !ast_strlen_zero(peer_featurecode);
|
|
|
|
if (hadfeatures && !hasfeatures) {
|
|
|
|
/* Feature completed or timed out */
|
|
|
|
config->feature_timer = 0;
|
|
|
|
} else if (hasfeatures) {
|
|
|
|
if (config->timelimit) {
|
2011-05-20 17:04:53 +00:00
|
|
|
/* No warning next time - we are waiting for feature code */
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
ast_set_flag(config, AST_FEATURE_WARNING_ACTIVE);
|
|
|
|
}
|
|
|
|
config->feature_start_time = ast_tvnow();
|
|
|
|
config->feature_timer = featuredigittimeout;
|
|
|
|
ast_debug(1, "Set feature timer to %ld ms\n", config->feature_timer);
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2005-01-04 04:01:40 +00:00
|
|
|
}
|
|
|
|
if (f)
|
|
|
|
ast_frfree(f);
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2012-01-12 16:10:47 +00:00
|
|
|
ast_cel_report_event(chan, AST_CEL_BRIDGE_END, NULL, NULL, peer);
|
Merged revisions 310902 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines
Merged revisions 310889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-03-16 17:29:16 +00:00
|
|
|
|
|
|
|
before_you_go:
|
|
|
|
/* Just in case something weird happened and we didn't clean up the silence generator... */
|
|
|
|
if (silgen) {
|
|
|
|
ast_channel_stop_silence_generator(who == chan ? peer : chan, silgen);
|
|
|
|
silgen = NULL;
|
|
|
|
}
|
Merged revisions 172030 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines
This patch fixes h-exten running misbehavior in manager-redirected
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-28 20:31:06 +00:00
|
|
|
|
2012-03-13 18:20:34 +00:00
|
|
|
if (ast_test_flag(ast_channel_flags(chan), AST_FLAG_BRIDGE_HANGUP_DONT)) {
|
|
|
|
ast_clear_flag(ast_channel_flags(chan), AST_FLAG_BRIDGE_HANGUP_DONT); /* its job is done */
|
Merged revisions 172030 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines
This patch fixes h-exten running misbehavior in manager-redirected
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-28 20:31:06 +00:00
|
|
|
if (bridge_cdr) {
|
|
|
|
ast_cdr_discard(bridge_cdr);
|
|
|
|
/* QUESTION: should we copy bridge_cdr fields to the peer before we throw it away? */
|
|
|
|
}
|
|
|
|
return res; /* if we shouldn't do the h-exten, we shouldn't do the bridge cdr, either! */
|
|
|
|
}
|
|
|
|
|
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-23 18:13:49 +00:00
|
|
|
if (config->end_bridge_callback) {
|
2008-11-09 01:27:00 +00:00
|
|
|
config->end_bridge_callback(config->end_bridge_callback_data);
|
2008-10-31 18:55:33 +00:00
|
|
|
}
|
2008-09-23 16:52:32 +00:00
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/* run the hangup exten on the chan object IFF it was NOT involved in a parking situation
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
* if it were, then chan belongs to a different thread now, and might have been hung up long
|
|
|
|
* ago.
|
|
|
|
*/
|
2011-05-13 16:30:29 +00:00
|
|
|
if (ast_test_flag(&config->features_caller, AST_FEATURE_NO_H_EXTEN)) {
|
|
|
|
h_context = NULL;
|
2012-02-13 17:27:06 +00:00
|
|
|
} else if (ast_exists_extension(chan, ast_channel_context(chan), "h", 1,
|
2012-02-29 16:52:47 +00:00
|
|
|
S_COR(ast_channel_caller(chan)->id.number.valid, ast_channel_caller(chan)->id.number.str, NULL))) {
|
2012-02-13 17:27:06 +00:00
|
|
|
h_context = ast_channel_context(chan);
|
|
|
|
} else if (!ast_strlen_zero(ast_channel_macrocontext(chan))
|
|
|
|
&& ast_exists_extension(chan, ast_channel_macrocontext(chan), "h", 1,
|
2012-02-29 16:52:47 +00:00
|
|
|
S_COR(ast_channel_caller(chan)->id.number.valid, ast_channel_caller(chan)->id.number.str, NULL))) {
|
2012-02-13 17:27:06 +00:00
|
|
|
h_context = ast_channel_macrocontext(chan);
|
2011-05-13 16:30:29 +00:00
|
|
|
} else {
|
|
|
|
h_context = NULL;
|
|
|
|
}
|
|
|
|
if (h_context) {
|
2008-11-21 23:40:46 +00:00
|
|
|
struct ast_cdr *swapper = NULL;
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
char savelastapp[AST_MAX_EXTENSION];
|
|
|
|
char savelastdata[AST_MAX_EXTENSION];
|
2011-05-13 16:30:29 +00:00
|
|
|
char save_context[AST_MAX_CONTEXT];
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
char save_exten[AST_MAX_EXTENSION];
|
|
|
|
int save_prio;
|
|
|
|
int found = 0; /* set if we find at least one match */
|
2008-10-09 23:15:33 +00:00
|
|
|
int spawn_error = 0;
|
2011-12-08 17:55:07 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure that the channel is marked as hungup since we are
|
|
|
|
* going to run the "h" exten on it.
|
|
|
|
*/
|
|
|
|
ast_softhangup(chan, AST_SOFTHANGUP_APPUNLOAD);
|
|
|
|
|
2012-03-13 18:20:34 +00:00
|
|
|
autoloopflag = ast_test_flag(ast_channel_flags(chan), AST_FLAG_IN_AUTOLOOP);
|
|
|
|
ast_set_flag(ast_channel_flags(chan), AST_FLAG_IN_AUTOLOOP);
|
2008-11-21 23:40:46 +00:00
|
|
|
if (bridge_cdr && ast_opt_end_cdr_before_h_exten) {
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
ast_cdr_end(bridge_cdr);
|
|
|
|
}
|
2011-05-09 19:09:16 +00:00
|
|
|
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
/* swap the bridge cdr and the chan cdr for a moment, and let the endbridge
|
|
|
|
dialplan code operate on it */
|
|
|
|
ast_channel_lock(chan);
|
2008-11-21 23:40:46 +00:00
|
|
|
if (bridge_cdr) {
|
2012-02-20 23:43:27 +00:00
|
|
|
swapper = ast_channel_cdr(chan);
|
2008-11-21 23:40:46 +00:00
|
|
|
ast_copy_string(savelastapp, bridge_cdr->lastapp, sizeof(bridge_cdr->lastapp));
|
|
|
|
ast_copy_string(savelastdata, bridge_cdr->lastdata, sizeof(bridge_cdr->lastdata));
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_cdr_set(chan, bridge_cdr);
|
2008-11-21 23:40:46 +00:00
|
|
|
}
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_copy_string(save_context, ast_channel_context(chan), sizeof(save_context));
|
|
|
|
ast_copy_string(save_exten, ast_channel_exten(chan), sizeof(save_exten));
|
2012-02-20 23:43:27 +00:00
|
|
|
save_prio = ast_channel_priority(chan);
|
2012-02-13 17:27:06 +00:00
|
|
|
if (h_context != ast_channel_context(chan)) {
|
|
|
|
ast_channel_context_set(chan, h_context);
|
2011-05-13 16:30:29 +00:00
|
|
|
}
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_exten_set(chan, "h");
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_priority_set(chan, 1);
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
ast_channel_unlock(chan);
|
2011-05-09 19:09:16 +00:00
|
|
|
|
2012-02-13 17:27:06 +00:00
|
|
|
while ((spawn_error = ast_spawn_extension(chan, ast_channel_context(chan), ast_channel_exten(chan),
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_priority(chan),
|
2012-02-29 16:52:47 +00:00
|
|
|
S_COR(ast_channel_caller(chan)->id.number.valid, ast_channel_caller(chan)->id.number.str, NULL),
|
2010-07-14 15:48:36 +00:00
|
|
|
&found, 1)) == 0) {
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_priority_set(chan, ast_channel_priority(chan) + 1);
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
}
|
2008-10-09 23:15:33 +00:00
|
|
|
if (found && spawn_error) {
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
/* Something bad happened, or a hangup has been requested. */
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_debug(1, "Spawn extension (%s,%s,%d) exited non-zero on '%s'\n", ast_channel_context(chan), ast_channel_exten(chan), ast_channel_priority(chan), ast_channel_name(chan));
|
|
|
|
ast_verb(2, "Spawn extension (%s, %s, %d) exited non-zero on '%s'\n", ast_channel_context(chan), ast_channel_exten(chan), ast_channel_priority(chan), ast_channel_name(chan));
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
}
|
2011-05-09 19:09:16 +00:00
|
|
|
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
/* swap it back */
|
|
|
|
ast_channel_lock(chan);
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_context_set(chan, save_context);
|
|
|
|
ast_channel_exten_set(chan, save_exten);
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_priority_set(chan, save_prio);
|
2009-03-03 18:28:46 +00:00
|
|
|
if (bridge_cdr) {
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_cdr(chan) == bridge_cdr) {
|
|
|
|
ast_channel_cdr_set(chan, swapper);
|
2009-03-03 18:28:46 +00:00
|
|
|
} else {
|
|
|
|
bridge_cdr = NULL;
|
|
|
|
}
|
|
|
|
}
|
2011-05-09 19:09:16 +00:00
|
|
|
/* An "h" exten has been run, so indicate that one has been run. */
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_set_flag(ast_channel_flags(chan), AST_FLAG_BRIDGE_HANGUP_RUN);
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
ast_channel_unlock(chan);
|
2011-05-09 19:09:16 +00:00
|
|
|
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
/* protect the lastapp/lastdata against the effects of the hangup/dialplan code */
|
2008-11-21 23:40:46 +00:00
|
|
|
if (bridge_cdr) {
|
|
|
|
ast_copy_string(bridge_cdr->lastapp, savelastapp, sizeof(bridge_cdr->lastapp));
|
|
|
|
ast_copy_string(bridge_cdr->lastdata, savelastdata, sizeof(bridge_cdr->lastdata));
|
|
|
|
}
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_set2_flag(ast_channel_flags(chan), autoloopflag, AST_FLAG_IN_AUTOLOOP);
|
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-09-12 04:50:48 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
/* obey the NoCDR() wishes. -- move the DISABLED flag to the bridge CDR if it was set on the channel during the bridge... */
|
2012-02-20 23:43:27 +00:00
|
|
|
new_chan_cdr = pick_unlocked_cdr(ast_channel_cdr(chan)); /* the proper chan cdr, if there are forked cdrs */
|
2012-03-13 20:43:19 +00:00
|
|
|
/* If the channel CDR has been modified during the call, record the changes in the bridge cdr,
|
|
|
|
* BUT, if we've gone through the h extension block above, the CDR got swapped so don't overwrite
|
|
|
|
* what was done in the h extension. What a mess. This is why you never touch CDR code. */
|
|
|
|
if (new_chan_cdr && bridge_cdr && !h_context) {
|
2012-02-27 16:08:28 +00:00
|
|
|
ast_cdr_copy_vars(bridge_cdr, new_chan_cdr);
|
|
|
|
ast_copy_string(bridge_cdr->userfield, new_chan_cdr->userfield, sizeof(bridge_cdr->userfield));
|
|
|
|
bridge_cdr->amaflags = new_chan_cdr->amaflags;
|
|
|
|
ast_copy_string(bridge_cdr->accountcode, new_chan_cdr->accountcode, sizeof(bridge_cdr->accountcode));
|
|
|
|
if (ast_test_flag(new_chan_cdr, AST_CDR_FLAG_POST_DISABLED)) {
|
|
|
|
ast_set_flag(bridge_cdr, AST_CDR_FLAG_POST_DISABLED);
|
|
|
|
}
|
|
|
|
}
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
|
|
|
|
/* we can post the bridge CDR at this point */
|
2008-11-21 21:47:16 +00:00
|
|
|
if (bridge_cdr) {
|
|
|
|
ast_cdr_end(bridge_cdr);
|
|
|
|
ast_cdr_detach(bridge_cdr);
|
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
/* do a specialized reset on the beginning channel
|
|
|
|
CDR's, if they still exist, so as not to mess up
|
|
|
|
issues in future bridges;
|
2012-03-22 19:51:16 +00:00
|
|
|
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
Here are the rules of the game:
|
|
|
|
1. The chan and peer channel pointers will not change
|
|
|
|
during the life of the bridge.
|
|
|
|
2. But, in transfers, the channel names will change.
|
|
|
|
between the time the bridge is started, and the
|
2012-03-22 19:51:16 +00:00
|
|
|
time the channel ends.
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
Usually, when a channel changes names, it will
|
|
|
|
also change CDR pointers.
|
|
|
|
3. Usually, only one of the two channels (chan or peer)
|
|
|
|
will change names.
|
|
|
|
4. Usually, if a channel changes names during a bridge,
|
|
|
|
it is because of a transfer. Usually, in these situations,
|
|
|
|
it is normal to see 2 bridges running simultaneously, and
|
|
|
|
it is not unusual to see the two channels that change
|
|
|
|
swapped between bridges.
|
|
|
|
5. After a bridge occurs, we have 2 or 3 channels' CDRs
|
|
|
|
to attend to; if the chan or peer changed names,
|
|
|
|
we have the before and after attached CDR's.
|
|
|
|
*/
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-23 18:13:49 +00:00
|
|
|
if (new_chan_cdr) {
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
struct ast_channel *chan_ptr = NULL;
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
if (strcasecmp(orig_channame, ast_channel_name(chan)) != 0) {
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
/* old channel */
|
2009-05-14 21:24:17 +00:00
|
|
|
if ((chan_ptr = ast_channel_get_by_name(orig_channame))) {
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
ast_channel_lock(chan_ptr);
|
|
|
|
if (!ast_bridged_channel(chan_ptr)) {
|
|
|
|
struct ast_cdr *cur;
|
2012-02-20 23:43:27 +00:00
|
|
|
for (cur = ast_channel_cdr(chan_ptr); cur; cur = cur->next) {
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
if (cur == chan_cdr) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (cur) {
|
|
|
|
ast_cdr_specialized_reset(chan_cdr, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ast_channel_unlock(chan_ptr);
|
|
|
|
chan_ptr = ast_channel_unref(chan_ptr);
|
|
|
|
}
|
|
|
|
/* new channel */
|
|
|
|
ast_cdr_specialized_reset(new_chan_cdr, 0);
|
|
|
|
} else {
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_cdr_specialized_reset(ast_channel_cdr(chan), 0); /* nothing changed, reset the chan cdr */
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
}
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-23 18:13:49 +00:00
|
|
|
{
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
struct ast_channel *chan_ptr = NULL;
|
2012-02-20 23:43:27 +00:00
|
|
|
new_peer_cdr = pick_unlocked_cdr(ast_channel_cdr(peer)); /* the proper chan cdr, if there are forked cdrs */
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
if (new_chan_cdr && ast_test_flag(new_chan_cdr, AST_CDR_FLAG_POST_DISABLED) && new_peer_cdr && !ast_test_flag(new_peer_cdr, AST_CDR_FLAG_POST_DISABLED))
|
|
|
|
ast_set_flag(new_peer_cdr, AST_CDR_FLAG_POST_DISABLED); /* DISABLED is viral-- it will propagate across a bridge */
|
2012-03-22 19:51:16 +00:00
|
|
|
if (strcasecmp(orig_peername, ast_channel_name(peer)) != 0) {
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
/* old channel */
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
if ((chan_ptr = ast_channel_get_by_name(orig_peername))) {
|
|
|
|
ast_channel_lock(chan_ptr);
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
if (!ast_bridged_channel(chan_ptr)) {
|
|
|
|
struct ast_cdr *cur;
|
2012-02-20 23:43:27 +00:00
|
|
|
for (cur = ast_channel_cdr(chan_ptr); cur; cur = cur->next) {
|
2008-09-23 16:52:32 +00:00
|
|
|
if (cur == peer_cdr) {
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
if (cur) {
|
|
|
|
ast_cdr_specialized_reset(peer_cdr, 0);
|
|
|
|
}
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
}
|
|
|
|
ast_channel_unlock(chan_ptr);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
chan_ptr = ast_channel_unref(chan_ptr);
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
}
|
|
|
|
/* new channel */
|
2009-08-19 15:32:18 +00:00
|
|
|
if (new_peer_cdr) {
|
|
|
|
ast_cdr_specialized_reset(new_peer_cdr, 0);
|
|
|
|
}
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
} else {
|
2010-12-09 21:26:19 +00:00
|
|
|
if (we_disabled_peer_cdr) {
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_clear_flag(ast_channel_cdr(peer), AST_CDR_FLAG_POST_DISABLED);
|
2010-12-09 21:26:19 +00:00
|
|
|
}
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_cdr_specialized_reset(ast_channel_cdr(peer), 0); /* nothing changed, reset the peer cdr */
|
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-10-29 05:01:00 +00:00
|
|
|
}
|
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2007-02-18 15:01:07 +00:00
|
|
|
/*! \brief Output parking event to manager */
|
|
|
|
static void post_manager_event(const char *s, struct parkeduser *pu)
|
2006-04-21 16:04:25 +00:00
|
|
|
{
|
|
|
|
manager_event(EVENT_FLAG_CALL, s,
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
"Exten: %s\r\n"
|
2006-04-21 16:04:25 +00:00
|
|
|
"Channel: %s\r\n"
|
2008-04-21 23:42:45 +00:00
|
|
|
"Parkinglot: %s\r\n"
|
2006-10-02 20:35:16 +00:00
|
|
|
"CallerIDNum: %s\r\n"
|
2008-08-22 21:52:20 +00:00
|
|
|
"CallerIDName: %s\r\n"
|
2011-05-25 17:14:11 +00:00
|
|
|
"ConnectedLineNum: %s\r\n"
|
|
|
|
"ConnectedLineName: %s\r\n"
|
2011-01-19 18:55:43 +00:00
|
|
|
"UniqueID: %s\r\n",
|
2012-03-22 19:51:16 +00:00
|
|
|
pu->parkingexten,
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(pu->chan),
|
2008-04-21 23:42:45 +00:00
|
|
|
pu->parkinglot->name,
|
2012-02-29 16:52:47 +00:00
|
|
|
S_COR(ast_channel_caller(pu->chan)->id.number.valid, ast_channel_caller(pu->chan)->id.number.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_caller(pu->chan)->id.name.valid, ast_channel_caller(pu->chan)->id.name.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_connected(pu->chan)->id.number.valid, ast_channel_connected(pu->chan)->id.number.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_connected(pu->chan)->id.name.valid, ast_channel_connected(pu->chan)->id.name.str, "<unknown>"),
|
2012-01-24 20:12:09 +00:00
|
|
|
ast_channel_uniqueid(pu->chan)
|
2006-04-21 16:04:25 +00:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
static char *callback_dialoptions(struct ast_flags *features_callee, struct ast_flags *features_caller, char *options, size_t len)
|
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
enum {
|
|
|
|
OPT_CALLEE_REDIRECT = 't',
|
|
|
|
OPT_CALLER_REDIRECT = 'T',
|
|
|
|
OPT_CALLEE_AUTOMON = 'w',
|
|
|
|
OPT_CALLER_AUTOMON = 'W',
|
|
|
|
OPT_CALLEE_DISCONNECT = 'h',
|
|
|
|
OPT_CALLER_DISCONNECT = 'H',
|
|
|
|
OPT_CALLEE_PARKCALL = 'k',
|
|
|
|
OPT_CALLER_PARKCALL = 'K',
|
|
|
|
};
|
|
|
|
|
|
|
|
memset(options, 0, len);
|
|
|
|
if (ast_test_flag(features_caller, AST_FEATURE_REDIRECT) && i < len) {
|
|
|
|
options[i++] = OPT_CALLER_REDIRECT;
|
|
|
|
}
|
|
|
|
if (ast_test_flag(features_caller, AST_FEATURE_AUTOMON) && i < len) {
|
|
|
|
options[i++] = OPT_CALLER_AUTOMON;
|
|
|
|
}
|
|
|
|
if (ast_test_flag(features_caller, AST_FEATURE_DISCONNECT) && i < len) {
|
|
|
|
options[i++] = OPT_CALLER_DISCONNECT;
|
|
|
|
}
|
|
|
|
if (ast_test_flag(features_caller, AST_FEATURE_PARKCALL) && i < len) {
|
|
|
|
options[i++] = OPT_CALLER_PARKCALL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_test_flag(features_callee, AST_FEATURE_REDIRECT) && i < len) {
|
|
|
|
options[i++] = OPT_CALLEE_REDIRECT;
|
|
|
|
}
|
|
|
|
if (ast_test_flag(features_callee, AST_FEATURE_AUTOMON) && i < len) {
|
|
|
|
options[i++] = OPT_CALLEE_AUTOMON;
|
|
|
|
}
|
|
|
|
if (ast_test_flag(features_callee, AST_FEATURE_DISCONNECT) && i < len) {
|
|
|
|
options[i++] = OPT_CALLEE_DISCONNECT;
|
|
|
|
}
|
|
|
|
if (ast_test_flag(features_callee, AST_FEATURE_PARKCALL) && i < len) {
|
|
|
|
options[i++] = OPT_CALLEE_PARKCALL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Run management on a parked call.
|
|
|
|
*
|
|
|
|
* \note The parkinglot parkings list is locked on entry.
|
|
|
|
*
|
|
|
|
* \retval TRUE if the parking completed.
|
|
|
|
*/
|
|
|
|
static int manage_parked_call(struct parkeduser *pu, const struct pollfd *pfds, int nfds, struct pollfd **new_pfds, int *new_nfds, int *ms)
|
2001-12-27 11:07:33 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_channel *chan = pu->chan; /* shorthand */
|
|
|
|
int tms; /* timeout for this item */
|
|
|
|
int x; /* fd index in channel */
|
|
|
|
int parking_complete = 0;
|
2004-12-09 22:39:14 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
tms = ast_tvdiff_ms(ast_tvnow(), pu->start);
|
|
|
|
if (tms > pu->parkingtime) {
|
|
|
|
/*
|
|
|
|
* Call has been parked too long.
|
|
|
|
* Stop entertaining the caller.
|
|
|
|
*/
|
|
|
|
switch (pu->hold_method) {
|
|
|
|
case AST_CONTROL_HOLD:
|
2008-04-21 23:42:45 +00:00
|
|
|
ast_indicate(pu->chan, AST_CONTROL_UNHOLD);
|
2011-08-16 17:23:08 +00:00
|
|
|
break;
|
|
|
|
case AST_CONTROL_RINGING:
|
|
|
|
ast_indicate(pu->chan, -1);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
pu->hold_method = 0;
|
2010-07-21 13:02:46 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Get chan, exten from derived kludge */
|
|
|
|
if (pu->peername[0]) {
|
|
|
|
char *peername;
|
|
|
|
char *dash;
|
|
|
|
char *peername_flat; /* using something like DAHDI/52 for an extension name is NOT a good idea */
|
|
|
|
int i;
|
2008-03-01 01:30:37 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
peername = ast_strdupa(pu->peername);
|
|
|
|
dash = strrchr(peername, '-');
|
|
|
|
if (dash) {
|
|
|
|
*dash = '\0';
|
|
|
|
}
|
2008-03-01 01:30:37 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
peername_flat = ast_strdupa(peername);
|
|
|
|
for (i = 0; peername_flat[i]; i++) {
|
|
|
|
if (peername_flat[i] == '/') {
|
|
|
|
peername_flat[i] = '_';
|
|
|
|
}
|
|
|
|
}
|
2008-03-01 01:30:37 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!ast_context_find_or_create(NULL, NULL, parking_con_dial, registrar)) {
|
|
|
|
ast_log(LOG_ERROR,
|
|
|
|
"Parking dial context '%s' does not exist and unable to create\n",
|
|
|
|
parking_con_dial);
|
|
|
|
} else {
|
|
|
|
char returnexten[AST_MAX_EXTENSION];
|
2012-01-20 20:47:42 +00:00
|
|
|
char comebackdialtime[AST_MAX_EXTENSION];
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_datastore *features_datastore;
|
|
|
|
struct ast_dial_features *dialfeatures;
|
2009-01-16 22:16:23 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!strncmp(peername, "Parked/", 7)) {
|
|
|
|
peername += 7;
|
|
|
|
}
|
2008-03-01 01:30:37 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_lock(chan);
|
|
|
|
features_datastore = ast_channel_datastore_find(chan, &dial_features_info,
|
|
|
|
NULL);
|
|
|
|
if (features_datastore && (dialfeatures = features_datastore->data)) {
|
|
|
|
char buf[MAX_DIAL_FEATURE_OPTIONS] = {0,};
|
|
|
|
|
2012-01-20 20:47:42 +00:00
|
|
|
snprintf(returnexten, sizeof(returnexten), "%s,%u,%s", peername,
|
|
|
|
pu->parkinglot->cfg.comebackdialtime,
|
2012-04-25 01:26:44 +00:00
|
|
|
callback_dialoptions(&dialfeatures->peer_features,
|
|
|
|
&dialfeatures->my_features, buf, sizeof(buf)));
|
2011-08-16 17:23:08 +00:00
|
|
|
} else { /* Existing default */
|
|
|
|
ast_log(LOG_NOTICE, "Dial features not found on %s, using default!\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(chan));
|
2012-01-20 20:47:42 +00:00
|
|
|
snprintf(returnexten, sizeof(returnexten), "%s,%u,t", peername,
|
|
|
|
pu->parkinglot->cfg.comebackdialtime);
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_unlock(chan);
|
|
|
|
|
2012-01-20 20:47:42 +00:00
|
|
|
snprintf(comebackdialtime, sizeof(comebackdialtime), "%u",
|
|
|
|
pu->parkinglot->cfg.comebackdialtime);
|
|
|
|
pbx_builtin_setvar_helper(chan, "COMEBACKDIALTIME", comebackdialtime);
|
|
|
|
|
|
|
|
pbx_builtin_setvar_helper(chan, "PARKER", peername);
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_add_extension(parking_con_dial, 1, peername_flat, 1, NULL, NULL,
|
|
|
|
"Dial", ast_strdup(returnexten), ast_free_ptr, registrar)) {
|
|
|
|
ast_log(LOG_ERROR,
|
|
|
|
"Could not create parking return dial exten: %s@%s\n",
|
|
|
|
peername_flat, parking_con_dial);
|
2004-12-09 22:39:14 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
if (pu->options_specified) {
|
|
|
|
/*
|
|
|
|
* Park() was called with overriding return arguments, respect
|
|
|
|
* those arguments.
|
|
|
|
*/
|
2008-04-21 23:42:45 +00:00
|
|
|
set_c_e_p(chan, pu->context, pu->exten, pu->priority);
|
2012-01-20 20:47:42 +00:00
|
|
|
} else if (pu->parkinglot->cfg.comebacktoorigin) {
|
2011-08-16 17:23:08 +00:00
|
|
|
set_c_e_p(chan, parking_con_dial, peername_flat, 1);
|
|
|
|
} else {
|
|
|
|
char parkingslot[AST_MAX_EXTENSION];
|
|
|
|
|
|
|
|
snprintf(parkingslot, sizeof(parkingslot), "%d", pu->parkingnum);
|
|
|
|
pbx_builtin_setvar_helper(chan, "PARKINGSLOT", parkingslot);
|
2011-12-14 21:08:20 +00:00
|
|
|
pbx_builtin_setvar_helper(chan, "PARKEDLOT", pu->parkinglot->name);
|
2012-01-20 20:47:42 +00:00
|
|
|
set_c_e_p(chan, pu->parkinglot->cfg.comebackcontext, peername_flat, 1);
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* They've been waiting too long, send them back to where they
|
|
|
|
* came. Theoretically they should have their original
|
|
|
|
* extensions and such, but we copy to be on the safe side.
|
|
|
|
*/
|
|
|
|
set_c_e_p(chan, pu->context, pu->exten, pu->priority);
|
|
|
|
}
|
|
|
|
post_manager_event("ParkedCallTimeOut", pu);
|
|
|
|
ast_cel_report_event(pu->chan, AST_CEL_PARK_END, NULL, "ParkedCallTimeOut", NULL);
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_verb(2, "Timeout for %s parked on %d (%s). Returning to %s,%s,%d\n",
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_name(pu->chan), pu->parkingnum, pu->parkinglot->name, ast_channel_context(pu->chan),
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_exten(pu->chan), ast_channel_priority(pu->chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
/* Start up the PBX, or hang them up */
|
|
|
|
if (ast_pbx_start(chan)) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Unable to restart the PBX for user on '%s', hanging them up...\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(pu->chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_hangup(chan);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* And take them out of the parking lot */
|
|
|
|
parking_complete = 1;
|
|
|
|
} else { /* still within parking time, process descriptors */
|
|
|
|
for (x = 0; x < AST_MAX_FDS; x++) {
|
|
|
|
struct ast_frame *f;
|
|
|
|
int y;
|
|
|
|
|
2012-03-01 22:09:18 +00:00
|
|
|
if (!ast_channel_fd_isset(chan, x)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
continue; /* nothing on this descriptor */
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2010-09-02 05:02:54 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
for (y = 0; y < nfds; y++) {
|
2012-03-01 22:09:18 +00:00
|
|
|
if (pfds[y].fd == ast_channel_fd(chan, x)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Found poll record! */
|
|
|
|
break;
|
2010-09-02 05:02:54 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
if (y == nfds) {
|
|
|
|
/* Not found */
|
|
|
|
continue;
|
|
|
|
}
|
2005-02-26 07:54:28 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!(pfds[y].revents & (POLLIN | POLLERR | POLLPRI))) {
|
|
|
|
/* Next x */
|
|
|
|
continue;
|
|
|
|
}
|
2010-09-02 05:02:54 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (pfds[y].revents & POLLPRI) {
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_set_flag(ast_channel_flags(chan), AST_FLAG_EXCEPTION);
|
2011-08-16 17:23:08 +00:00
|
|
|
} else {
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_clear_flag(ast_channel_flags(chan), AST_FLAG_EXCEPTION);
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_fdno_set(chan, x);
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
/* See if they need servicing */
|
|
|
|
f = ast_read(pu->chan);
|
|
|
|
/* Hangup? */
|
|
|
|
if (!f || (f->frametype == AST_FRAME_CONTROL
|
|
|
|
&& f->subclass.integer == AST_CONTROL_HANGUP)) {
|
|
|
|
if (f) {
|
|
|
|
ast_frfree(f);
|
2010-09-02 05:02:54 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
post_manager_event("ParkedCallGiveUp", pu);
|
|
|
|
ast_cel_report_event(pu->chan, AST_CEL_PARK_END, NULL, "ParkedCallGiveUp",
|
|
|
|
NULL);
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* There's a problem, hang them up */
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_verb(2, "%s got tired of being parked\n", ast_channel_name(chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_hangup(chan);
|
|
|
|
|
|
|
|
/* And take them out of the parking lot */
|
|
|
|
parking_complete = 1;
|
|
|
|
break;
|
|
|
|
} else {
|
|
|
|
/* XXX Maybe we could do something with packets, like dial "0" for operator or something XXX */
|
|
|
|
ast_frfree(f);
|
|
|
|
if (pu->hold_method == AST_CONTROL_HOLD
|
|
|
|
&& pu->moh_trys < 3
|
2012-02-20 23:43:27 +00:00
|
|
|
&& !ast_channel_generatordata(chan)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(1,
|
|
|
|
"MOH on parked call stopped by outside source. Restarting on channel %s.\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_indicate_data(chan, AST_CONTROL_HOLD,
|
|
|
|
S_OR(pu->parkinglot->cfg.mohclass, NULL),
|
|
|
|
(!ast_strlen_zero(pu->parkinglot->cfg.mohclass)
|
|
|
|
? strlen(pu->parkinglot->cfg.mohclass) + 1 : 0));
|
|
|
|
pu->moh_trys++;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
goto std; /* XXX Ick: jumping into an else statement??? XXX */
|
|
|
|
}
|
|
|
|
} /* End for */
|
|
|
|
if (x >= AST_MAX_FDS) {
|
|
|
|
std: for (x = 0; x < AST_MAX_FDS; x++) { /* mark fds for next round */
|
2012-03-01 22:09:18 +00:00
|
|
|
if (ast_channel_fd_isset(chan, x)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
void *tmp = ast_realloc(*new_pfds,
|
|
|
|
(*new_nfds + 1) * sizeof(struct pollfd));
|
|
|
|
|
|
|
|
if (!tmp) {
|
|
|
|
continue;
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
*new_pfds = tmp;
|
2012-03-01 22:09:18 +00:00
|
|
|
(*new_pfds)[*new_nfds].fd = ast_channel_fd(chan, x);
|
2011-08-16 17:23:08 +00:00
|
|
|
(*new_pfds)[*new_nfds].events = POLLIN | POLLERR | POLLPRI;
|
|
|
|
(*new_pfds)[*new_nfds].revents = 0;
|
|
|
|
(*new_nfds)++;
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
/* Keep track of our shortest wait */
|
|
|
|
if (tms < *ms || *ms < 0) {
|
|
|
|
*ms = tms;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return parking_complete;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Run management on parkinglots, called once per parkinglot */
|
|
|
|
static void manage_parkinglot(struct ast_parkinglot *curlot, const struct pollfd *pfds, int nfds, struct pollfd **new_pfds, int *new_nfds, int *ms)
|
|
|
|
{
|
|
|
|
struct parkeduser *pu;
|
|
|
|
struct ast_context *con;
|
|
|
|
|
|
|
|
/* Lock parkings list */
|
|
|
|
AST_LIST_LOCK(&curlot->parkings);
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(&curlot->parkings, pu, list) {
|
|
|
|
if (pu->notquiteyet) { /* Pretend this one isn't here yet */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (manage_parked_call(pu, pfds, nfds, new_pfds, new_nfds, ms)) {
|
|
|
|
/* Parking is complete for this call so remove it from the parking lot. */
|
|
|
|
con = ast_context_find(pu->parkinglot->cfg.parking_con);
|
|
|
|
if (con) {
|
|
|
|
if (ast_context_remove_extension2(con, pu->parkingexten, 1, NULL, 0)) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Whoa, failed to remove the parking extension %s@%s!\n",
|
|
|
|
pu->parkingexten, pu->parkinglot->cfg.parking_con);
|
2010-09-02 05:02:54 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
notify_metermaids(pu->parkingexten, pu->parkinglot->cfg.parking_con,
|
|
|
|
AST_DEVICE_NOT_INUSE);
|
|
|
|
} else {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Whoa, parking lot '%s' context '%s' does not exist.\n",
|
|
|
|
pu->parkinglot->name, pu->parkinglot->cfg.parking_con);
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_LIST_REMOVE_CURRENT(list);
|
|
|
|
parkinglot_unref(pu->parkinglot);
|
|
|
|
ast_free(pu);
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
|
|
|
AST_LIST_UNLOCK(&curlot->parkings);
|
|
|
|
}
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/*!
|
|
|
|
* \brief Take care of parked calls and unpark them if needed
|
2008-04-21 23:42:45 +00:00
|
|
|
* \param ignore unused var.
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2008-04-21 23:42:45 +00:00
|
|
|
* Start inf loop, lock parking lot, check if any parked channels have gone above timeout
|
|
|
|
* if so, remove channel from parking lot and return it to the extension that parked it.
|
|
|
|
* Check if parked channel decided to hangup, wait until next FD via select().
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2008-04-21 23:42:45 +00:00
|
|
|
static void *do_parking_thread(void *ignore)
|
|
|
|
{
|
2010-09-13 23:15:50 +00:00
|
|
|
struct pollfd *pfds = NULL, *new_pfds = NULL;
|
|
|
|
int nfds = 0, new_nfds = 0;
|
2008-04-21 23:42:45 +00:00
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
struct ao2_iterator iter;
|
|
|
|
struct ast_parkinglot *curlot;
|
2010-09-02 05:02:54 +00:00
|
|
|
int ms = -1; /* poll2 timeout, uninitialized */
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-09 23:17:13 +00:00
|
|
|
iter = ao2_iterator_init(parkinglots, 0);
|
2008-04-21 23:42:45 +00:00
|
|
|
while ((curlot = ao2_iterator_next(&iter))) {
|
2010-09-13 23:15:50 +00:00
|
|
|
manage_parkinglot(curlot, pfds, nfds, &new_pfds, &new_nfds, &ms);
|
2008-04-21 23:42:45 +00:00
|
|
|
ao2_ref(curlot, -1);
|
|
|
|
}
|
2010-09-02 05:02:54 +00:00
|
|
|
ao2_iterator_destroy(&iter);
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2010-09-13 23:15:50 +00:00
|
|
|
/* Recycle */
|
|
|
|
ast_free(pfds);
|
|
|
|
pfds = new_pfds;
|
|
|
|
nfds = new_nfds;
|
|
|
|
new_pfds = NULL;
|
|
|
|
new_nfds = 0;
|
|
|
|
|
2010-09-02 05:02:54 +00:00
|
|
|
/* Wait for something to happen */
|
|
|
|
ast_poll(pfds, nfds, ms);
|
2001-12-27 11:07:33 +00:00
|
|
|
pthread_testcancel();
|
|
|
|
}
|
2010-09-02 05:02:54 +00:00
|
|
|
/* If this WERE reached, we'd need to free(pfds) */
|
2001-12-27 11:07:33 +00:00
|
|
|
return NULL; /* Never reached */
|
|
|
|
}
|
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/*! \brief Find parkinglot by name */
|
2011-08-16 17:23:08 +00:00
|
|
|
static struct ast_parkinglot *find_parkinglot(const char *name)
|
2008-04-21 23:42:45 +00:00
|
|
|
{
|
2010-09-15 19:23:56 +00:00
|
|
|
struct ast_parkinglot *parkinglot;
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2010-09-15 19:23:56 +00:00
|
|
|
if (ast_strlen_zero(name)) {
|
|
|
|
return NULL;
|
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2010-09-15 19:23:56 +00:00
|
|
|
parkinglot = ao2_find(parkinglots, (void *) name, 0);
|
|
|
|
if (parkinglot) {
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(1, "Found Parking lot: %s\n", parkinglot->name);
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
|
|
|
return parkinglot;
|
|
|
|
}
|
|
|
|
|
2010-02-17 18:29:48 +00:00
|
|
|
/*! \brief Copy parkinglot and store it with new name */
|
2011-08-16 17:23:08 +00:00
|
|
|
static struct ast_parkinglot *copy_parkinglot(const char *name, const struct ast_parkinglot *parkinglot)
|
|
|
|
{
|
2010-02-17 18:29:48 +00:00
|
|
|
struct ast_parkinglot *copylot;
|
|
|
|
|
2010-09-15 19:23:56 +00:00
|
|
|
if ((copylot = find_parkinglot(name))) { /* Parkinglot with that name already exists */
|
2011-08-16 17:23:08 +00:00
|
|
|
ao2_ref(copylot, -1);
|
2010-02-17 18:29:48 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
copylot = create_parkinglot(name);
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!copylot) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-02-17 18:29:48 +00:00
|
|
|
ast_debug(1, "Building parking lot %s\n", name);
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Copy the source parking lot configuration. */
|
|
|
|
copylot->cfg = parkinglot->cfg;
|
2010-02-17 18:29:48 +00:00
|
|
|
|
|
|
|
return copylot;
|
|
|
|
}
|
|
|
|
|
2008-04-25 18:18:27 +00:00
|
|
|
AST_APP_OPTIONS(park_call_options, BEGIN_OPTIONS
|
|
|
|
AST_APP_OPTION('r', AST_PARK_OPT_RINGING),
|
|
|
|
AST_APP_OPTION('R', AST_PARK_OPT_RANDOMIZE),
|
2008-08-29 17:53:32 +00:00
|
|
|
AST_APP_OPTION('s', AST_PARK_OPT_SILENCE),
|
2008-04-25 18:18:27 +00:00
|
|
|
END_OPTIONS );
|
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
/*! \brief Park a call */
|
2009-05-21 21:13:09 +00:00
|
|
|
static int park_call_exec(struct ast_channel *chan, const char *data)
|
2004-08-03 06:31:20 +00:00
|
|
|
{
|
2012-02-23 20:14:54 +00:00
|
|
|
struct ast_park_call_args args = { 0, };
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_flags flags = { 0 };
|
2008-01-04 22:57:56 +00:00
|
|
|
char orig_exten[AST_MAX_EXTENSION];
|
2011-08-16 17:23:08 +00:00
|
|
|
int orig_priority;
|
|
|
|
int res;
|
|
|
|
const char *pl_name;
|
|
|
|
char *parse;
|
|
|
|
struct park_app_args app_args;
|
2008-01-04 22:57:56 +00:00
|
|
|
|
2012-02-23 20:14:54 +00:00
|
|
|
/*
|
|
|
|
* Cache the original channel name because we are going to
|
|
|
|
* masquerade the channel. Prefer the BLINDTRANSFER channel
|
|
|
|
* name over this channel name. BLINDTRANSFER could be set if
|
|
|
|
* the parking access extension did not get detected and we are
|
|
|
|
* executing the Park application from the dialplan.
|
|
|
|
*
|
|
|
|
* The orig_chan_name is used to return the call to the
|
|
|
|
* originator on parking timeout.
|
|
|
|
*/
|
|
|
|
args.orig_chan_name = ast_strdupa(S_OR(
|
|
|
|
pbx_builtin_getvar_helper(chan, "BLINDTRANSFER"), ast_channel_name(chan)));
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Answer if call is not up */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chan) != AST_STATE_UP) {
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_answer(chan)) {
|
|
|
|
return -1;
|
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Sleep to allow VoIP streams to settle down */
|
|
|
|
if (ast_safe_sleep(chan, 1000)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
2008-04-25 18:18:27 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Process the dialplan application options. */
|
2008-11-26 03:18:01 +00:00
|
|
|
parse = ast_strdupa(data);
|
|
|
|
AST_STANDARD_APP_ARGS(app_args, parse);
|
2008-04-25 18:18:27 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!ast_strlen_zero(app_args.timeout)) {
|
|
|
|
if (sscanf(app_args.timeout, "%30d", &args.timeout) != 1) {
|
|
|
|
ast_log(LOG_WARNING, "Invalid timeout '%s' provided\n", app_args.timeout);
|
|
|
|
args.timeout = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(app_args.return_con)) {
|
|
|
|
args.return_con = app_args.return_con;
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(app_args.return_ext)) {
|
|
|
|
args.return_ext = app_args.return_ext;
|
|
|
|
}
|
|
|
|
if (!ast_strlen_zero(app_args.return_pri)) {
|
|
|
|
if (sscanf(app_args.return_pri, "%30d", &args.return_pri) != 1) {
|
|
|
|
ast_log(LOG_WARNING, "Invalid priority '%s' specified\n", app_args.return_pri);
|
|
|
|
args.return_pri = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_app_parse_options(park_call_options, &flags, NULL, app_args.options);
|
|
|
|
args.flags = flags.flags;
|
2008-01-04 22:57:56 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*
|
|
|
|
* Setup the exten/priority to be s/1 since we don't know where
|
|
|
|
* this call should return.
|
|
|
|
*/
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_copy_string(orig_exten, ast_channel_exten(chan), sizeof(orig_exten));
|
2012-02-20 23:43:27 +00:00
|
|
|
orig_priority = ast_channel_priority(chan);
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_exten_set(chan, "s");
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_priority_set(chan, 1);
|
2008-04-25 18:18:27 +00:00
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
/* Park the call */
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!ast_strlen_zero(app_args.pl_name)) {
|
|
|
|
pl_name = app_args.pl_name;
|
|
|
|
} else {
|
|
|
|
pl_name = findparkinglotname(chan);
|
|
|
|
}
|
|
|
|
if (ast_strlen_zero(pl_name)) {
|
|
|
|
/* Parking lot is not specified, so use the default parking lot. */
|
|
|
|
args.parkinglot = parkinglot_addref(default_parkinglot);
|
|
|
|
} else {
|
|
|
|
args.parkinglot = find_parkinglot(pl_name);
|
|
|
|
if (!args.parkinglot && parkeddynamic) {
|
|
|
|
args.parkinglot = create_dynamic_parkinglot(pl_name, chan);
|
2008-04-25 18:18:27 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
if (args.parkinglot) {
|
2011-10-18 21:15:45 +00:00
|
|
|
res = masq_park_call(chan, chan, &args);
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot_unref(args.parkinglot);
|
|
|
|
} else {
|
|
|
|
/* Parking failed because the parking lot does not exist. */
|
2011-09-07 19:35:18 +00:00
|
|
|
if (!ast_test_flag(&args, AST_PARK_OPT_SILENCE)) {
|
|
|
|
ast_stream_and_wait(chan, "pbx-parkingfailed", "");
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
res = -1;
|
|
|
|
}
|
|
|
|
if (res) {
|
|
|
|
/* Park failed, try to continue in the dialplan. */
|
2012-02-13 17:27:06 +00:00
|
|
|
ast_channel_exten_set(chan, orig_exten);
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_priority_set(chan, orig_priority);
|
2011-08-16 17:23:08 +00:00
|
|
|
res = 0;
|
|
|
|
} else {
|
|
|
|
/* Park succeeded. */
|
2011-10-20 22:03:35 +00:00
|
|
|
res = -1;
|
2008-01-04 22:57:56 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2008-01-04 22:57:56 +00:00
|
|
|
return res;
|
2004-08-03 06:31:20 +00:00
|
|
|
}
|
|
|
|
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
/*! \brief Pickup parked call */
|
2011-08-16 17:23:08 +00:00
|
|
|
static int parked_call_exec(struct ast_channel *chan, const char *data)
|
2001-12-27 11:07:33 +00:00
|
|
|
{
|
2006-08-21 02:11:39 +00:00
|
|
|
int res = 0;
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_channel *peer = NULL;
|
2007-07-09 02:29:00 +00:00
|
|
|
struct parkeduser *pu;
|
2004-08-03 06:31:20 +00:00
|
|
|
struct ast_context *con;
|
2011-08-16 17:23:08 +00:00
|
|
|
char *parse;
|
|
|
|
const char *pl_name;
|
2007-11-13 20:30:13 +00:00
|
|
|
int park = 0;
|
2004-04-26 23:22:34 +00:00
|
|
|
struct ast_bridge_config config;
|
2010-09-15 19:23:56 +00:00
|
|
|
struct ast_parkinglot *parkinglot;
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_DECLARE_APP_ARGS(app_args,
|
|
|
|
AST_APP_ARG(pl_space); /*!< Parking lot space to retrieve if present. */
|
|
|
|
AST_APP_ARG(pl_name); /*!< Parking lot name to use if present. */
|
|
|
|
AST_APP_ARG(dummy); /*!< Place to put any remaining args string. */
|
|
|
|
);
|
|
|
|
|
|
|
|
parse = ast_strdupa(data);
|
|
|
|
AST_STANDARD_APP_ARGS(app_args, parse);
|
2004-04-26 23:22:34 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!ast_strlen_zero(app_args.pl_space)) {
|
|
|
|
if (sscanf(app_args.pl_space, "%30u", &park) != 1) {
|
|
|
|
ast_log(LOG_WARNING, "Specified parking extension not a number: %s\n",
|
|
|
|
app_args.pl_space);
|
|
|
|
park = -1;
|
|
|
|
}
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
2007-07-09 02:29:00 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!ast_strlen_zero(app_args.pl_name)) {
|
|
|
|
pl_name = app_args.pl_name;
|
|
|
|
} else {
|
|
|
|
pl_name = findparkinglotname(chan);
|
|
|
|
}
|
|
|
|
if (ast_strlen_zero(pl_name)) {
|
|
|
|
/* Parking lot is not specified, so use the default parking lot. */
|
|
|
|
parkinglot = parkinglot_addref(default_parkinglot);
|
|
|
|
} else {
|
|
|
|
parkinglot = find_parkinglot(pl_name);
|
|
|
|
if (!parkinglot) {
|
|
|
|
/* It helps to answer the channel if not already up. :) */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chan) != AST_STATE_UP) {
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_answer(chan);
|
|
|
|
}
|
|
|
|
if (ast_stream_and_wait(chan, "pbx-invalidpark", "")) {
|
|
|
|
ast_log(LOG_WARNING, "ast_streamfile of %s failed on %s\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
"pbx-invalidpark", ast_channel_name(chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Channel %s tried to retrieve parked call from unknown parking lot '%s'\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(chan), pl_name);
|
2011-08-16 17:23:08 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
|
|
|
AST_LIST_LOCK(&parkinglot->parkings);
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(&parkinglot->parkings, pu, list) {
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((ast_strlen_zero(app_args.pl_space) || pu->parkingnum == park)
|
2012-02-20 23:43:27 +00:00
|
|
|
&& !pu->notquiteyet && !ast_channel_pbx(pu->chan)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/* The parking space has a call and can be picked up now. */
|
2007-11-08 05:28:47 +00:00
|
|
|
AST_LIST_REMOVE_CURRENT(list);
|
2001-12-27 11:07:33 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2009-04-10 03:55:27 +00:00
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
2001-12-27 11:07:33 +00:00
|
|
|
if (pu) {
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Found a parked call to pickup. */
|
2001-12-27 11:07:33 +00:00
|
|
|
peer = pu->chan;
|
2011-08-16 17:23:08 +00:00
|
|
|
con = ast_context_find(parkinglot->cfg.parking_con);
|
2004-08-03 06:31:20 +00:00
|
|
|
if (con) {
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_context_remove_extension2(con, pu->parkingexten, 1, NULL, 0)) {
|
2004-08-03 06:31:20 +00:00
|
|
|
ast_log(LOG_WARNING, "Whoa, failed to remove the extension!\n");
|
2011-08-16 17:23:08 +00:00
|
|
|
} else {
|
|
|
|
notify_metermaids(pu->parkingexten, parkinglot->cfg.parking_con, AST_DEVICE_NOT_INUSE);
|
|
|
|
}
|
|
|
|
} else {
|
2004-08-03 06:31:20 +00:00
|
|
|
ast_log(LOG_WARNING, "Whoa, no parking context?\n");
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2005-02-26 07:54:28 +00:00
|
|
|
|
2009-06-26 15:28:53 +00:00
|
|
|
ast_cel_report_event(pu->chan, AST_CEL_PARK_END, NULL, "UnParkedCall", chan);
|
2009-11-13 20:42:03 +00:00
|
|
|
ast_manager_event(pu->chan, EVENT_FLAG_CALL, "UnParkedCall",
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
"Exten: %s\r\n"
|
2005-02-26 07:54:28 +00:00
|
|
|
"Channel: %s\r\n"
|
2012-02-06 17:33:41 +00:00
|
|
|
"Parkinglot: %s\r\n"
|
2005-02-26 07:54:28 +00:00
|
|
|
"From: %s\r\n"
|
2006-10-02 20:35:16 +00:00
|
|
|
"CallerIDNum: %s\r\n"
|
2011-05-25 17:14:11 +00:00
|
|
|
"CallerIDName: %s\r\n"
|
|
|
|
"ConnectedLineNum: %s\r\n"
|
2012-02-06 17:33:41 +00:00
|
|
|
"ConnectedLineName: %s\r\n"
|
|
|
|
"Uniqueid: %s\r\n",
|
|
|
|
pu->parkingexten, ast_channel_name(pu->chan), pu->parkinglot->name,
|
|
|
|
ast_channel_name(chan),
|
2012-02-29 16:52:47 +00:00
|
|
|
S_COR(ast_channel_caller(pu->chan)->id.number.valid, ast_channel_caller(pu->chan)->id.number.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_caller(pu->chan)->id.name.valid, ast_channel_caller(pu->chan)->id.name.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_connected(pu->chan)->id.number.valid, ast_channel_connected(pu->chan)->id.number.str, "<unknown>"),
|
|
|
|
S_COR(ast_channel_connected(pu->chan)->id.name.valid, ast_channel_connected(pu->chan)->id.name.str, "<unknown>"),
|
2012-02-06 17:33:41 +00:00
|
|
|
ast_channel_uniqueid(pu->chan)
|
2005-02-26 07:54:28 +00:00
|
|
|
);
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Stop entertaining the caller. */
|
|
|
|
switch (pu->hold_method) {
|
|
|
|
case AST_CONTROL_HOLD:
|
|
|
|
ast_indicate(pu->chan, AST_CONTROL_UNHOLD);
|
|
|
|
break;
|
|
|
|
case AST_CONTROL_RINGING:
|
|
|
|
ast_indicate(pu->chan, -1);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
pu->hold_method = 0;
|
|
|
|
|
|
|
|
parkinglot_unref(pu->parkinglot);
|
2007-06-06 21:20:11 +00:00
|
|
|
ast_free(pu);
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_LIST_UNLOCK(&parkinglot->parkings);
|
|
|
|
|
|
|
|
if (peer) {
|
|
|
|
/* Update connected line between retrieving call and parked call. */
|
|
|
|
struct ast_party_connected_line connected;
|
|
|
|
|
|
|
|
ast_party_connected_line_init(&connected);
|
|
|
|
|
|
|
|
/* Send our caller-id to peer. */
|
|
|
|
ast_channel_lock(chan);
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_connected_line_copy_from_caller(&connected, ast_channel_caller(chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_unlock(chan);
|
|
|
|
connected.source = AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER;
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(chan, peer, &connected, 0) &&
|
|
|
|
ast_channel_connected_line_macro(chan, peer, &connected, 0, 0)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_update_connected_line(peer, &connected, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get caller-id from peer.
|
|
|
|
*
|
|
|
|
* Update the retrieving call before it is answered if possible
|
|
|
|
* for best results. Some phones do not support updating the
|
|
|
|
* connected line information after connection.
|
|
|
|
*/
|
|
|
|
ast_channel_lock(peer);
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_connected_line_copy_from_caller(&connected, ast_channel_caller(peer));
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_unlock(peer);
|
|
|
|
connected.source = AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER;
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(peer, chan, &connected, 0) &&
|
|
|
|
ast_channel_connected_line_macro(peer, chan, &connected, 1, 0)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_update_connected_line(chan, &connected, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_party_connected_line_free(&connected);
|
|
|
|
}
|
|
|
|
|
2003-02-02 19:37:23 +00:00
|
|
|
/* JK02: it helps to answer the channel if not already up */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chan) != AST_STATE_UP) {
|
2003-02-02 19:37:23 +00:00
|
|
|
ast_answer(chan);
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
if (peer) {
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
struct ast_datastore *features_datastore;
|
2012-04-25 01:26:44 +00:00
|
|
|
struct ast_dial_features *dialfeatures;
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
|
2006-01-08 00:25:31 +00:00
|
|
|
/* Play a courtesy to the source(s) configured to prefix the bridge connecting */
|
2004-08-31 13:32:11 +00:00
|
|
|
if (!ast_strlen_zero(courtesytone)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
static const char msg[] = "courtesy tone";
|
|
|
|
|
|
|
|
switch (parkedplay) {
|
|
|
|
case 0:/* Courtesy tone to pickup chan */
|
|
|
|
res = play_message_to_chans(chan, peer, -1, msg, courtesytone);
|
|
|
|
break;
|
|
|
|
case 1:/* Courtesy tone to parked chan */
|
|
|
|
res = play_message_to_chans(chan, peer, 1, msg, courtesytone);
|
|
|
|
break;
|
|
|
|
case 2:/* Courtesy tone to both chans */
|
|
|
|
res = play_message_to_chans(chan, peer, 0, msg, courtesytone);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
res = 0;
|
|
|
|
break;
|
2008-03-04 23:04:29 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (res) {
|
2006-04-16 20:32:14 +00:00
|
|
|
ast_hangup(peer);
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot_unref(parkinglot);
|
2006-04-16 20:32:14 +00:00
|
|
|
return -1;
|
2004-08-31 13:32:11 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2006-05-03 21:39:24 +00:00
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
res = ast_channel_make_compatible(chan, peer);
|
|
|
|
if (res < 0) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Could not make channels %s and %s compatible for bridge\n", ast_channel_name(chan), ast_channel_name(peer));
|
2001-12-27 11:07:33 +00:00
|
|
|
ast_hangup(peer);
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot_unref(parkinglot);
|
2001-12-27 11:07:33 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
/* This runs sorta backwards, since we give the incoming channel control, as if it
|
|
|
|
were the person called. */
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_verb(3, "Channel %s connected to parked call %d\n", ast_channel_name(chan), park);
|
2004-04-26 23:22:34 +00:00
|
|
|
|
2012-01-09 22:15:50 +00:00
|
|
|
pbx_builtin_setvar_helper(chan, "PARKEDCHANNEL", ast_channel_name(peer));
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_cdr_setdestchan(ast_channel_cdr(chan), ast_channel_name(peer));
|
2005-07-25 17:31:53 +00:00
|
|
|
memset(&config, 0, sizeof(struct ast_bridge_config));
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
|
|
|
|
/* Get datastore for peer and apply it's features to the callee side of the bridge config */
|
|
|
|
ast_channel_lock(peer);
|
2012-04-25 01:26:44 +00:00
|
|
|
features_datastore = ast_channel_datastore_find(peer, &dial_features_info, NULL);
|
|
|
|
if (features_datastore && (dialfeatures = features_datastore->data)) {
|
|
|
|
ast_copy_flags(&config.features_callee, &dialfeatures->my_features,
|
|
|
|
AST_FLAGS_ALL);
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_unlock(peer);
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcalltransfers == AST_FEATURE_FLAG_BYCALLEE) || (parkinglot->cfg.parkedcalltransfers == AST_FEATURE_FLAG_BYBOTH)) {
|
2007-01-16 17:50:25 +00:00
|
|
|
ast_set_flag(&(config.features_callee), AST_FEATURE_REDIRECT);
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcalltransfers == AST_FEATURE_FLAG_BYCALLER) || (parkinglot->cfg.parkedcalltransfers == AST_FEATURE_FLAG_BYBOTH)) {
|
2007-01-16 17:50:25 +00:00
|
|
|
ast_set_flag(&(config.features_caller), AST_FEATURE_REDIRECT);
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcallreparking == AST_FEATURE_FLAG_BYCALLEE) || (parkinglot->cfg.parkedcallreparking == AST_FEATURE_FLAG_BYBOTH)) {
|
2007-02-16 17:41:27 +00:00
|
|
|
ast_set_flag(&(config.features_callee), AST_FEATURE_PARKCALL);
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcallreparking == AST_FEATURE_FLAG_BYCALLER) || (parkinglot->cfg.parkedcallreparking == AST_FEATURE_FLAG_BYBOTH)) {
|
2007-02-16 17:41:27 +00:00
|
|
|
ast_set_flag(&(config.features_caller), AST_FEATURE_PARKCALL);
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcallhangup == AST_FEATURE_FLAG_BYCALLEE) || (parkinglot->cfg.parkedcallhangup == AST_FEATURE_FLAG_BYBOTH)) {
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
ast_set_flag(&(config.features_callee), AST_FEATURE_DISCONNECT);
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcallhangup == AST_FEATURE_FLAG_BYCALLER) || (parkinglot->cfg.parkedcallhangup == AST_FEATURE_FLAG_BYBOTH)) {
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
ast_set_flag(&(config.features_caller), AST_FEATURE_DISCONNECT);
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcallrecording == AST_FEATURE_FLAG_BYCALLEE) || (parkinglot->cfg.parkedcallrecording == AST_FEATURE_FLAG_BYBOTH)) {
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
ast_set_flag(&(config.features_callee), AST_FEATURE_AUTOMON);
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((parkinglot->cfg.parkedcallrecording == AST_FEATURE_FLAG_BYCALLER) || (parkinglot->cfg.parkedcallrecording == AST_FEATURE_FLAG_BYBOTH)) {
|
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-01-30 21:29:12 +00:00
|
|
|
ast_set_flag(&(config.features_caller), AST_FEATURE_AUTOMON);
|
|
|
|
}
|
|
|
|
|
2005-07-25 17:31:53 +00:00
|
|
|
res = ast_bridge_call(chan, peer, &config);
|
2004-04-26 23:22:34 +00:00
|
|
|
|
2012-01-09 22:15:50 +00:00
|
|
|
pbx_builtin_setvar_helper(chan, "PARKEDCHANNEL", ast_channel_name(peer));
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_cdr_setdestchan(ast_channel_cdr(chan), ast_channel_name(peer));
|
2007-01-23 20:36:08 +00:00
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
/* Simulate the PBX hanging up */
|
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-12-23 18:13:49 +00:00
|
|
|
ast_hangup(peer);
|
2001-12-27 11:07:33 +00:00
|
|
|
} else {
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_stream_and_wait(chan, "pbx-invalidpark", "")) {
|
|
|
|
ast_log(LOG_WARNING, "ast_streamfile of %s failed on %s\n", "pbx-invalidpark",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
ast_verb(3, "Channel %s tried to retrieve nonexistent parked call %d\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(chan), park);
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot_unref(parkinglot);
|
2009-05-06 22:17:27 +00:00
|
|
|
return -1;
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
|
|
|
|
2011-05-20 17:04:53 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \brief Unreference parkinglot object.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2012-03-22 19:51:16 +00:00
|
|
|
static void parkinglot_unref(struct ast_parkinglot *parkinglot)
|
2008-04-21 23:42:45 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(3, "Multiparking: %s refcount now %d\n", parkinglot->name,
|
|
|
|
ao2_ref(parkinglot, 0) - 1);
|
|
|
|
ao2_ref(parkinglot, -1);
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct ast_parkinglot *parkinglot_addref(struct ast_parkinglot *parkinglot)
|
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
int refcount;
|
|
|
|
|
|
|
|
refcount = ao2_ref(parkinglot, +1);
|
2010-09-15 19:23:56 +00:00
|
|
|
ast_debug(3, "Multiparking: %s refcount now %d\n", parkinglot->name, refcount + 1);
|
2008-04-21 23:42:45 +00:00
|
|
|
return parkinglot;
|
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! \brief Destroy a parking lot */
|
|
|
|
static void parkinglot_destroy(void *obj)
|
|
|
|
{
|
|
|
|
struct ast_parkinglot *doomed = obj;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No need to destroy parked calls here because any parked call
|
|
|
|
* holds a parking lot reference. Therefore the parkings list
|
|
|
|
* must be empty.
|
|
|
|
*/
|
|
|
|
ast_assert(AST_LIST_EMPTY(&doomed->parkings));
|
|
|
|
AST_LIST_HEAD_DESTROY(&doomed->parkings);
|
|
|
|
}
|
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/*! \brief Allocate parking lot structure */
|
2010-02-17 18:29:48 +00:00
|
|
|
static struct ast_parkinglot *create_parkinglot(const char *name)
|
2008-04-21 23:42:45 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct ast_parkinglot *newlot;
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_strlen_zero(name)) { /* No name specified */
|
2008-04-21 23:42:45 +00:00
|
|
|
return NULL;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
|
|
|
newlot = ao2_alloc(sizeof(*newlot), parkinglot_destroy);
|
|
|
|
if (!newlot)
|
|
|
|
return NULL;
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
ast_copy_string(newlot->name, name, sizeof(newlot->name));
|
2011-08-16 17:23:08 +00:00
|
|
|
newlot->cfg.is_invalid = 1;/* No config is set yet. */
|
2009-09-02 20:21:51 +00:00
|
|
|
AST_LIST_HEAD_INIT(&newlot->parkings);
|
2008-04-21 23:42:45 +00:00
|
|
|
|
|
|
|
return newlot;
|
|
|
|
}
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \brief Add parking hints for all defined parking spaces.
|
|
|
|
* \param context Dialplan context to add the hints.
|
|
|
|
* \param start Starting space in parkinglot.
|
|
|
|
* \param stop Ending space in parkinglot.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2011-08-16 17:23:08 +00:00
|
|
|
static void park_add_hints(const char *context, int start, int stop)
|
2010-09-15 19:23:56 +00:00
|
|
|
{
|
|
|
|
int numext;
|
|
|
|
char device[AST_MAX_EXTENSION];
|
|
|
|
char exten[10];
|
|
|
|
|
|
|
|
for (numext = start; numext <= stop; numext++) {
|
|
|
|
snprintf(exten, sizeof(exten), "%d", numext);
|
|
|
|
snprintf(device, sizeof(device), "park:%s@%s", exten, context);
|
|
|
|
ast_add_extension(context, 1, exten, PRIORITY_HINT, NULL, NULL, device, NULL, NULL, registrar);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Default configuration for default parking lot. */
|
|
|
|
static const struct parkinglot_cfg parkinglot_cfg_default_default = {
|
|
|
|
.mohclass = "default",
|
|
|
|
.parkext = DEFAULT_PARK_EXTENSION,
|
|
|
|
.parking_con = "parkedcalls",
|
|
|
|
.parking_start = 701,
|
|
|
|
.parking_stop = 750,
|
|
|
|
.parkingtime = DEFAULT_PARK_TIME,
|
2012-01-20 20:47:42 +00:00
|
|
|
.comebackdialtime = DEFAULT_COMEBACK_DIAL_TIME,
|
|
|
|
.comebackcontext = DEFAULT_COMEBACK_CONTEXT,
|
|
|
|
.comebacktoorigin = DEFAULT_COMEBACK_TO_ORIGIN,
|
2011-08-16 17:23:08 +00:00
|
|
|
};
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*! Default configuration for normal parking lots. */
|
|
|
|
static const struct parkinglot_cfg parkinglot_cfg_default = {
|
|
|
|
.parkext = DEFAULT_PARK_EXTENSION,
|
|
|
|
.parkingtime = DEFAULT_PARK_TIME,
|
2012-01-20 20:47:42 +00:00
|
|
|
.comebackdialtime = DEFAULT_COMEBACK_DIAL_TIME,
|
|
|
|
.comebackcontext = DEFAULT_COMEBACK_CONTEXT,
|
|
|
|
.comebacktoorigin = DEFAULT_COMEBACK_TO_ORIGIN,
|
2011-08-16 17:23:08 +00:00
|
|
|
};
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Set parking lot feature flag configuration value.
|
|
|
|
*
|
|
|
|
* \param pl_name Parking lot name for diagnostic messages.
|
|
|
|
* \param param Parameter value to set.
|
|
|
|
* \param var Current configuration variable item.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void parkinglot_feature_flag_cfg(const char *pl_name, int *param, struct ast_variable *var)
|
|
|
|
{
|
|
|
|
ast_debug(1, "Setting parking lot %s %s to %s\n", pl_name, var->name, var->value);
|
|
|
|
if (!strcasecmp(var->value, "both")) {
|
|
|
|
*param = AST_FEATURE_FLAG_BYBOTH;
|
|
|
|
} else if (!strcasecmp(var->value, "caller")) {
|
|
|
|
*param = AST_FEATURE_FLAG_BYCALLER;
|
|
|
|
} else if (!strcasecmp(var->value, "callee")) {
|
|
|
|
*param = AST_FEATURE_FLAG_BYCALLEE;
|
|
|
|
}
|
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Read parking lot configuration.
|
|
|
|
*
|
|
|
|
* \param pl_name Parking lot name for diagnostic messages.
|
|
|
|
* \param cfg Parking lot config to update that is already initialized with defaults.
|
|
|
|
* \param var Config variable list.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on error.
|
|
|
|
*/
|
|
|
|
static int parkinglot_config_read(const char *pl_name, struct parkinglot_cfg *cfg, struct ast_variable *var)
|
|
|
|
{
|
|
|
|
int error = 0;
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
while (var) {
|
|
|
|
if (!strcasecmp(var->name, "context")) {
|
|
|
|
ast_copy_string(cfg->parking_con, var->value, sizeof(cfg->parking_con));
|
|
|
|
} else if (!strcasecmp(var->name, "parkext")) {
|
|
|
|
ast_copy_string(cfg->parkext, var->value, sizeof(cfg->parkext));
|
|
|
|
} else if (!strcasecmp(var->name, "parkext_exclusive")) {
|
|
|
|
cfg->parkext_exclusive = ast_true(var->value);
|
|
|
|
} else if (!strcasecmp(var->name, "parkinghints")) {
|
|
|
|
cfg->parkaddhints = ast_true(var->value);
|
|
|
|
} else if (!strcasecmp(var->name, "parkedmusicclass")) {
|
|
|
|
ast_copy_string(cfg->mohclass, var->value, sizeof(cfg->mohclass));
|
|
|
|
} else if (!strcasecmp(var->name, "parkingtime")) {
|
|
|
|
int parkingtime = 0;
|
2010-02-17 18:29:48 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if ((sscanf(var->value, "%30d", &parkingtime) != 1) || parkingtime < 1) {
|
|
|
|
ast_log(LOG_WARNING, "%s is not a valid parkingtime\n", var->value);
|
|
|
|
error = -1;
|
2008-04-21 23:42:45 +00:00
|
|
|
} else {
|
2011-08-16 17:23:08 +00:00
|
|
|
cfg->parkingtime = parkingtime * 1000;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
} else if (!strcasecmp(var->name, "parkpos")) {
|
|
|
|
int start = 0;
|
|
|
|
int end = 0;
|
|
|
|
|
|
|
|
if (sscanf(var->value, "%30d-%30d", &start, &end) != 2) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Format for parking positions is a-b, where a and b are numbers at line %d of %s\n",
|
|
|
|
var->lineno, var->file);
|
|
|
|
error = -1;
|
|
|
|
} else if (end < start || start <= 0 || end <= 0) {
|
|
|
|
ast_log(LOG_WARNING, "Parking range is invalid. Must be a <= b, at line %d of %s\n",
|
|
|
|
var->lineno, var->file);
|
|
|
|
error = -1;
|
|
|
|
} else {
|
|
|
|
cfg->parking_start = start;
|
|
|
|
cfg->parking_stop = end;
|
2010-09-11 17:31:42 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
} else if (!strcasecmp(var->name, "findslot")) {
|
|
|
|
cfg->parkfindnext = (!strcasecmp(var->value, "next"));
|
|
|
|
} else if (!strcasecmp(var->name, "parkedcalltransfers")) {
|
|
|
|
parkinglot_feature_flag_cfg(pl_name, &cfg->parkedcalltransfers, var);
|
|
|
|
} else if (!strcasecmp(var->name, "parkedcallreparking")) {
|
|
|
|
parkinglot_feature_flag_cfg(pl_name, &cfg->parkedcallreparking, var);
|
|
|
|
} else if (!strcasecmp(var->name, "parkedcallhangup")) {
|
|
|
|
parkinglot_feature_flag_cfg(pl_name, &cfg->parkedcallhangup, var);
|
|
|
|
} else if (!strcasecmp(var->name, "parkedcallrecording")) {
|
|
|
|
parkinglot_feature_flag_cfg(pl_name, &cfg->parkedcallrecording, var);
|
2012-01-20 20:47:42 +00:00
|
|
|
} else if (!strcasecmp(var->name, "comebackcontext")) {
|
|
|
|
ast_copy_string(cfg->comebackcontext, var->value, sizeof(cfg->comebackcontext));
|
|
|
|
} else if (!strcasecmp(var->name, "comebacktoorigin")) {
|
|
|
|
cfg->comebacktoorigin = ast_true(var->value);
|
|
|
|
} else if (!strcasecmp(var->name, "comebackdialtime")) {
|
|
|
|
if ((sscanf(var->value, "%30u", &cfg->comebackdialtime) != 1)
|
|
|
|
|| (cfg->comebackdialtime < 1)) {
|
|
|
|
ast_log(LOG_WARNING, "%s is not a valid comebackdialtime\n", var->value);
|
|
|
|
cfg->parkingtime = DEFAULT_COMEBACK_DIAL_TIME;
|
|
|
|
}
|
2010-09-11 17:31:42 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
var = var->next;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for configuration errors */
|
|
|
|
if (ast_strlen_zero(cfg->parking_con)) {
|
|
|
|
ast_log(LOG_WARNING, "Parking lot %s needs context\n", pl_name);
|
|
|
|
error = -1;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_strlen_zero(cfg->parkext)) {
|
|
|
|
ast_log(LOG_WARNING, "Parking lot %s needs parkext\n", pl_name);
|
|
|
|
error = -1;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!cfg->parking_start) {
|
|
|
|
ast_log(LOG_WARNING, "Parking lot %s needs parkpos\n", pl_name);
|
|
|
|
error = -1;
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
2012-01-20 20:47:42 +00:00
|
|
|
if (!cfg->comebacktoorigin && ast_strlen_zero(cfg->comebackcontext)) {
|
|
|
|
ast_log(LOG_WARNING, "Parking lot %s has comebacktoorigin set false"
|
|
|
|
"but has no comebackcontext.\n",
|
|
|
|
pl_name);
|
|
|
|
error = -1;
|
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (error) {
|
|
|
|
cfg->is_invalid = 1;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Activate the given parkinglot.
|
|
|
|
*
|
|
|
|
* \param parkinglot Parking lot to activate.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* Insert into the dialplan the context, parking lot access
|
|
|
|
* extension, and optional dialplan hints.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on error.
|
|
|
|
*/
|
|
|
|
static int parkinglot_activate(struct ast_parkinglot *parkinglot)
|
|
|
|
{
|
|
|
|
int disabled = 0;
|
|
|
|
char app_data[5 + AST_MAX_CONTEXT];
|
|
|
|
|
|
|
|
/* Create Park option list. Must match with struct park_app_args options. */
|
|
|
|
if (parkinglot->cfg.parkext_exclusive) {
|
|
|
|
/* Specify the parking lot this parking extension parks calls. */
|
|
|
|
snprintf(app_data, sizeof(app_data), ",,,,,%s", parkinglot->name);
|
|
|
|
} else {
|
|
|
|
/* The dialplan must specify which parking lot to use. */
|
|
|
|
app_data[0] = '\0';
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Create context */
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!ast_context_find_or_create(NULL, NULL, parkinglot->cfg.parking_con, registrar)) {
|
|
|
|
ast_log(LOG_ERROR, "Parking context '%s' does not exist and unable to create\n",
|
|
|
|
parkinglot->cfg.parking_con);
|
|
|
|
disabled = 1;
|
2008-04-21 23:42:45 +00:00
|
|
|
|
|
|
|
/* Add a parking extension into the context */
|
2011-08-16 17:23:08 +00:00
|
|
|
} else if (ast_add_extension(parkinglot->cfg.parking_con, 1, parkinglot->cfg.parkext,
|
|
|
|
1, NULL, NULL, parkcall, ast_strdup(app_data), ast_free_ptr, registrar)) {
|
|
|
|
ast_log(LOG_ERROR, "Could not create parking lot %s access exten %s@%s\n",
|
|
|
|
parkinglot->name, parkinglot->cfg.parkext, parkinglot->cfg.parking_con);
|
|
|
|
disabled = 1;
|
|
|
|
} else {
|
|
|
|
/* Add parking hints */
|
|
|
|
if (parkinglot->cfg.parkaddhints) {
|
|
|
|
park_add_hints(parkinglot->cfg.parking_con, parkinglot->cfg.parking_start,
|
|
|
|
parkinglot->cfg.parking_stop);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX Not sure why we should need to notify the metermaids for
|
|
|
|
* this exten. It was originally done for the default parking
|
|
|
|
* lot entry exten only but should be done for all entry extens
|
|
|
|
* if we do it for one.
|
|
|
|
*/
|
|
|
|
/* Notify metermaids about parking lot entry exten state. */
|
|
|
|
notify_metermaids(parkinglot->cfg.parkext, parkinglot->cfg.parking_con,
|
|
|
|
AST_DEVICE_INUSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
parkinglot->disabled = disabled;
|
|
|
|
return disabled ? -1 : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*! \brief Build parkinglot from configuration and chain it in if it doesn't already exist */
|
|
|
|
static struct ast_parkinglot *build_parkinglot(const char *pl_name, struct ast_variable *var)
|
|
|
|
{
|
|
|
|
struct ast_parkinglot *parkinglot;
|
|
|
|
const struct parkinglot_cfg *cfg_defaults;
|
|
|
|
struct parkinglot_cfg new_cfg;
|
|
|
|
int cfg_error;
|
|
|
|
int oldparkinglot = 0;
|
|
|
|
|
|
|
|
parkinglot = find_parkinglot(pl_name);
|
|
|
|
if (parkinglot) {
|
|
|
|
oldparkinglot = 1;
|
|
|
|
} else {
|
|
|
|
parkinglot = create_parkinglot(pl_name);
|
|
|
|
if (!parkinglot) {
|
|
|
|
return NULL;
|
(closes issue #13202)
Reported by: falves11
Tested by: murf
falves11 ==
The changes I introduce here seem to clear up the problem
for me. However, if they do not for you, please reopen this
bug, and we'll keep digging.
The root of this problem seems to be a subtle memory corruption
introduced when creating an extension with an empty extension
name. While valgrind cannot detect it outside of DEBUG_MALLOC
mode, when compiled with DEBUG_MALLOC, this is certain death.
The code in main/features.c is a puzzle to me. On the initial
module load, the code is attempting to add the parking extension
before the features.conf file has even been opened!
I just wrapped the offending call with an if() that will not
try to add the extension if the extension name is empty. THis
seems to solve the corruption, and let the "memory show allocations"
work as one would expect.
But, really, adding an extension with an empty name is a seriously
bad thing to allow, as it will mess up all the pattern matching
algorithms, etc. So, I added a statement to the add_extension2 code to return
a -1 if this is attempted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-08-02 04:51:29 +00:00
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!strcmp(parkinglot->name, DEFAULT_PARKINGLOT)) {
|
|
|
|
cfg_defaults = &parkinglot_cfg_default_default;
|
|
|
|
} else {
|
|
|
|
cfg_defaults = &parkinglot_cfg_default;
|
|
|
|
}
|
|
|
|
new_cfg = *cfg_defaults;
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(1, "Building parking lot %s\n", parkinglot->name);
|
|
|
|
|
|
|
|
ao2_lock(parkinglot);
|
|
|
|
|
|
|
|
/* Do some config stuff */
|
|
|
|
cfg_error = parkinglot_config_read(parkinglot->name, &new_cfg, var);
|
|
|
|
if (oldparkinglot) {
|
|
|
|
if (cfg_error) {
|
|
|
|
/* Bad configuration read. Keep using the original config. */
|
|
|
|
ast_log(LOG_WARNING, "Changes to parking lot %s are discarded.\n",
|
|
|
|
parkinglot->name);
|
|
|
|
cfg_error = 0;
|
|
|
|
} else if (!AST_LIST_EMPTY(&parkinglot->parkings)
|
|
|
|
&& memcmp(&new_cfg, &parkinglot->cfg, sizeof(parkinglot->cfg))) {
|
|
|
|
/* Try reloading later when parking lot is empty. */
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Parking lot %s has parked calls. Parking lot changes discarded.\n",
|
|
|
|
parkinglot->name);
|
|
|
|
force_reload_load = 1;
|
|
|
|
} else {
|
|
|
|
/* Accept the new config */
|
|
|
|
parkinglot->cfg = new_cfg;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Load the initial parking lot config. */
|
|
|
|
parkinglot->cfg = new_cfg;
|
|
|
|
}
|
|
|
|
parkinglot->the_mark = 0;
|
2010-09-15 19:23:56 +00:00
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
ao2_unlock(parkinglot);
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (cfg_error) {
|
|
|
|
/* Only new parking lots could have config errors here. */
|
|
|
|
ast_log(LOG_WARNING, "New parking lot %s is discarded.\n", parkinglot->name);
|
2010-09-15 19:23:56 +00:00
|
|
|
parkinglot_unref(parkinglot);
|
2008-04-21 23:42:45 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Move it into the list, if it wasn't already there */
|
|
|
|
if (!oldparkinglot) {
|
|
|
|
ao2_link(parkinglots, parkinglot);
|
|
|
|
}
|
|
|
|
parkinglot_unref(parkinglot);
|
|
|
|
|
|
|
|
return parkinglot;
|
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Process an applicationmap section config line.
|
|
|
|
*
|
|
|
|
* \param var Config variable line.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void process_applicationmap_line(struct ast_variable *var)
|
|
|
|
{
|
|
|
|
char *tmp_val = ast_strdupa(var->value);
|
|
|
|
char *activateon;
|
|
|
|
struct ast_call_feature *feature;
|
|
|
|
AST_DECLARE_APP_ARGS(args,
|
|
|
|
AST_APP_ARG(exten);
|
|
|
|
AST_APP_ARG(activatedby);
|
|
|
|
AST_APP_ARG(app);
|
|
|
|
AST_APP_ARG(app_args);
|
|
|
|
AST_APP_ARG(moh_class);
|
|
|
|
);
|
|
|
|
|
|
|
|
AST_STANDARD_APP_ARGS(args, tmp_val);
|
|
|
|
if (strchr(args.app, '(')) {
|
|
|
|
/* New syntax */
|
|
|
|
args.moh_class = args.app_args;
|
|
|
|
args.app_args = strchr(args.app, '(');
|
|
|
|
*args.app_args++ = '\0';
|
|
|
|
if (args.app_args[strlen(args.app_args) - 1] == ')') {
|
|
|
|
args.app_args[strlen(args.app_args) - 1] = '\0';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
activateon = strsep(&args.activatedby, "/");
|
|
|
|
|
|
|
|
/*! \todo XXX var_name or app_args ? */
|
|
|
|
if (ast_strlen_zero(args.app)
|
|
|
|
|| ast_strlen_zero(args.exten)
|
|
|
|
|| ast_strlen_zero(activateon)
|
|
|
|
|| ast_strlen_zero(var->name)) {
|
|
|
|
ast_log(LOG_NOTICE,
|
|
|
|
"Please check the feature Mapping Syntax, either extension, name, or app aren't provided %s %s %s %s\n",
|
|
|
|
args.app, args.exten, activateon, var->name);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
AST_RWLIST_RDLOCK(&feature_list);
|
|
|
|
if (find_dynamic_feature(var->name)) {
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
|
|
|
ast_log(LOG_WARNING, "Dynamic Feature '%s' specified more than once!\n",
|
|
|
|
var->name);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
|
|
|
|
|
|
|
if (!(feature = ast_calloc(1, sizeof(*feature)))) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_copy_string(feature->sname, var->name, FEATURE_SNAME_LEN);
|
|
|
|
ast_copy_string(feature->app, args.app, FEATURE_APP_LEN);
|
|
|
|
ast_copy_string(feature->exten, args.exten, FEATURE_EXTEN_LEN);
|
|
|
|
|
|
|
|
if (args.app_args) {
|
|
|
|
ast_copy_string(feature->app_args, args.app_args, FEATURE_APP_ARGS_LEN);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (args.moh_class) {
|
|
|
|
ast_copy_string(feature->moh_class, args.moh_class, FEATURE_MOH_LEN);
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_copy_string(feature->exten, args.exten, sizeof(feature->exten));
|
|
|
|
feature->operation = feature_exec_app;
|
|
|
|
ast_set_flag(feature, AST_FEATURE_FLAG_NEEDSDTMF);
|
|
|
|
|
|
|
|
/* Allow caller and callee to be specified for backwards compatability */
|
|
|
|
if (!strcasecmp(activateon, "self") || !strcasecmp(activateon, "caller")) {
|
|
|
|
ast_set_flag(feature, AST_FEATURE_FLAG_ONSELF);
|
|
|
|
} else if (!strcasecmp(activateon, "peer") || !strcasecmp(activateon, "callee")) {
|
|
|
|
ast_set_flag(feature, AST_FEATURE_FLAG_ONPEER);
|
|
|
|
} else {
|
|
|
|
ast_log(LOG_NOTICE, "Invalid 'ActivateOn' specification for feature '%s',"
|
|
|
|
" must be 'self', or 'peer'\n", var->name);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_strlen_zero(args.activatedby)) {
|
|
|
|
ast_set_flag(feature, AST_FEATURE_FLAG_BYBOTH);
|
|
|
|
} else if (!strcasecmp(args.activatedby, "caller")) {
|
|
|
|
ast_set_flag(feature, AST_FEATURE_FLAG_BYCALLER);
|
|
|
|
} else if (!strcasecmp(args.activatedby, "callee")) {
|
|
|
|
ast_set_flag(feature, AST_FEATURE_FLAG_BYCALLEE);
|
|
|
|
} else if (!strcasecmp(args.activatedby, "both")) {
|
|
|
|
ast_set_flag(feature, AST_FEATURE_FLAG_BYBOTH);
|
|
|
|
} else {
|
|
|
|
ast_log(LOG_NOTICE, "Invalid 'ActivatedBy' specification for feature '%s',"
|
|
|
|
" must be 'caller', or 'callee', or 'both'\n", var->name);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_register_feature(feature);
|
|
|
|
|
|
|
|
ast_verb(2, "Mapping Feature '%s' to app '%s(%s)' with code '%s'\n",
|
|
|
|
var->name, args.app, args.app_args, args.exten);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int process_config(struct ast_config *cfg)
|
2008-01-23 23:09:11 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct ast_variable *var = NULL;
|
|
|
|
struct feature_group *fg = NULL;
|
2012-03-22 19:51:16 +00:00
|
|
|
char *ctg;
|
|
|
|
static const char * const categories[] = {
|
2008-01-23 23:09:11 +00:00
|
|
|
/* Categories in features.conf that are not
|
|
|
|
* to be parsed as group categories
|
|
|
|
*/
|
|
|
|
"general",
|
|
|
|
"featuremap",
|
|
|
|
"applicationmap"
|
|
|
|
};
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Set general features global defaults. */
|
|
|
|
featuredigittimeout = DEFAULT_FEATURE_DIGIT_TIMEOUT;
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Set global call pickup defaults. */
|
2008-01-23 23:09:11 +00:00
|
|
|
strcpy(pickup_ext, "*8");
|
2009-02-26 18:41:28 +00:00
|
|
|
pickupsound[0] = '\0';
|
|
|
|
pickupfailsound[0] = '\0';
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Set global call transfer defaults. */
|
|
|
|
strcpy(xfersound, "beep");
|
|
|
|
strcpy(xferfailsound, "beeperr");
|
2008-01-23 23:09:11 +00:00
|
|
|
transferdigittimeout = DEFAULT_TRANSFER_DIGIT_TIMEOUT;
|
|
|
|
atxfernoanswertimeout = DEFAULT_NOANSWER_TIMEOUT_ATTENDED_TRANSFER;
|
|
|
|
atxferloopdelay = DEFAULT_ATXFER_LOOP_DELAY;
|
|
|
|
atxferdropcall = DEFAULT_ATXFER_DROP_CALL;
|
|
|
|
atxfercallbackretries = DEFAULT_ATXFER_CALLBACK_RETRIES;
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Set global call parking defaults. */
|
|
|
|
courtesytone[0] = '\0';
|
|
|
|
parkedplay = 0;
|
|
|
|
adsipark = 0;
|
|
|
|
parkeddynamic = 0;
|
2011-04-07 13:42:13 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
var = ast_variable_browse(cfg, "general");
|
|
|
|
build_parkinglot(DEFAULT_PARKINGLOT, var);
|
2011-04-07 13:42:13 +00:00
|
|
|
for (; var; var = var->next) {
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!strcasecmp(var->name, "parkeddynamic")) {
|
2010-02-17 18:29:48 +00:00
|
|
|
parkeddynamic = ast_true(var->value);
|
2008-01-23 23:09:11 +00:00
|
|
|
} else if (!strcasecmp(var->name, "adsipark")) {
|
|
|
|
adsipark = ast_true(var->value);
|
|
|
|
} else if (!strcasecmp(var->name, "transferdigittimeout")) {
|
2009-08-10 19:20:57 +00:00
|
|
|
if ((sscanf(var->value, "%30d", &transferdigittimeout) != 1) || (transferdigittimeout < 1)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_log(LOG_WARNING, "%s is not a valid transferdigittimeout\n", var->value);
|
|
|
|
transferdigittimeout = DEFAULT_TRANSFER_DIGIT_TIMEOUT;
|
2011-08-09 23:17:13 +00:00
|
|
|
} else {
|
2008-01-23 23:09:11 +00:00
|
|
|
transferdigittimeout = transferdigittimeout * 1000;
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
} else if (!strcasecmp(var->name, "featuredigittimeout")) {
|
2009-08-10 19:20:57 +00:00
|
|
|
if ((sscanf(var->value, "%30d", &featuredigittimeout) != 1) || (featuredigittimeout < 1)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_log(LOG_WARNING, "%s is not a valid featuredigittimeout\n", var->value);
|
|
|
|
featuredigittimeout = DEFAULT_FEATURE_DIGIT_TIMEOUT;
|
|
|
|
}
|
|
|
|
} else if (!strcasecmp(var->name, "atxfernoanswertimeout")) {
|
2009-08-10 19:20:57 +00:00
|
|
|
if ((sscanf(var->value, "%30d", &atxfernoanswertimeout) != 1) || (atxfernoanswertimeout < 1)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_log(LOG_WARNING, "%s is not a valid atxfernoanswertimeout\n", var->value);
|
|
|
|
atxfernoanswertimeout = DEFAULT_NOANSWER_TIMEOUT_ATTENDED_TRANSFER;
|
2011-08-09 23:17:13 +00:00
|
|
|
} else {
|
2008-01-23 23:09:11 +00:00
|
|
|
atxfernoanswertimeout = atxfernoanswertimeout * 1000;
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
} else if (!strcasecmp(var->name, "atxferloopdelay")) {
|
2009-08-10 19:20:57 +00:00
|
|
|
if ((sscanf(var->value, "%30u", &atxferloopdelay) != 1)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_log(LOG_WARNING, "%s is not a valid atxferloopdelay\n", var->value);
|
|
|
|
atxferloopdelay = DEFAULT_ATXFER_LOOP_DELAY;
|
2011-08-09 23:17:13 +00:00
|
|
|
} else {
|
2008-01-23 23:09:11 +00:00
|
|
|
atxferloopdelay *= 1000;
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
} else if (!strcasecmp(var->name, "atxferdropcall")) {
|
|
|
|
atxferdropcall = ast_true(var->value);
|
|
|
|
} else if (!strcasecmp(var->name, "atxfercallbackretries")) {
|
2011-01-03 23:18:20 +00:00
|
|
|
if ((sscanf(var->value, "%30u", &atxfercallbackretries) != 1)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_log(LOG_WARNING, "%s is not a valid atxfercallbackretries\n", var->value);
|
|
|
|
atxfercallbackretries = DEFAULT_ATXFER_CALLBACK_RETRIES;
|
|
|
|
}
|
|
|
|
} else if (!strcasecmp(var->name, "courtesytone")) {
|
|
|
|
ast_copy_string(courtesytone, var->value, sizeof(courtesytone));
|
|
|
|
} else if (!strcasecmp(var->name, "parkedplay")) {
|
2011-08-09 23:17:13 +00:00
|
|
|
if (!strcasecmp(var->value, "both")) {
|
2008-01-23 23:09:11 +00:00
|
|
|
parkedplay = 2;
|
2011-08-09 23:17:13 +00:00
|
|
|
} else if (!strcasecmp(var->value, "parked")) {
|
2008-01-23 23:09:11 +00:00
|
|
|
parkedplay = 1;
|
2011-08-09 23:17:13 +00:00
|
|
|
} else {
|
2008-01-23 23:09:11 +00:00
|
|
|
parkedplay = 0;
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
} else if (!strcasecmp(var->name, "xfersound")) {
|
|
|
|
ast_copy_string(xfersound, var->value, sizeof(xfersound));
|
|
|
|
} else if (!strcasecmp(var->name, "xferfailsound")) {
|
|
|
|
ast_copy_string(xferfailsound, var->value, sizeof(xferfailsound));
|
|
|
|
} else if (!strcasecmp(var->name, "pickupexten")) {
|
|
|
|
ast_copy_string(pickup_ext, var->value, sizeof(pickup_ext));
|
2009-02-26 18:41:28 +00:00
|
|
|
} else if (!strcasecmp(var->name, "pickupsound")) {
|
|
|
|
ast_copy_string(pickupsound, var->value, sizeof(pickupsound));
|
|
|
|
} else if (!strcasecmp(var->name, "pickupfailsound")) {
|
|
|
|
ast_copy_string(pickupfailsound, var->value, sizeof(pickupfailsound));
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
unmap_features();
|
|
|
|
for (var = ast_variable_browse(cfg, "featuremap"); var; var = var->next) {
|
2011-08-09 23:17:13 +00:00
|
|
|
if (remap_feature(var->name, var->value)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_log(LOG_NOTICE, "Unknown feature '%s'\n", var->name);
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
|
|
|
|
2011-08-09 23:17:13 +00:00
|
|
|
/* Map a key combination to an application */
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_unregister_features();
|
|
|
|
for (var = ast_variable_browse(cfg, "applicationmap"); var; var = var->next) {
|
2011-08-16 17:23:08 +00:00
|
|
|
process_applicationmap_line(var);
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ast_unregister_groups();
|
|
|
|
AST_RWLIST_WRLOCK(&feature_groups);
|
|
|
|
|
|
|
|
ctg = NULL;
|
|
|
|
while ((ctg = ast_category_browse(cfg, ctg))) {
|
2008-04-21 23:42:45 +00:00
|
|
|
/* Is this a parkinglot definition ? */
|
|
|
|
if (!strncasecmp(ctg, "parkinglot_", strlen("parkinglot_"))) {
|
|
|
|
ast_debug(2, "Found configuration section %s, assume parking context\n", ctg);
|
2011-08-09 23:17:13 +00:00
|
|
|
if (!build_parkinglot(ctg, ast_variable_browse(cfg, ctg))) {
|
2008-04-21 23:42:45 +00:00
|
|
|
ast_log(LOG_ERROR, "Could not build parking lot %s. Configuration error.\n", ctg);
|
2011-08-09 23:17:13 +00:00
|
|
|
} else {
|
2008-04-21 23:42:45 +00:00
|
|
|
ast_debug(1, "Configured parking context %s\n", ctg);
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2011-02-04 16:55:39 +00:00
|
|
|
continue;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-09 23:17:13 +00:00
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
/* No, check if it's a group */
|
2008-01-23 23:09:11 +00:00
|
|
|
for (i = 0; i < ARRAY_LEN(categories); i++) {
|
2011-08-09 23:17:13 +00:00
|
|
|
if (!strcasecmp(categories[i], ctg)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
break;
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
2011-08-09 23:17:13 +00:00
|
|
|
if (i < ARRAY_LEN(categories)) {
|
2008-01-23 23:09:11 +00:00
|
|
|
continue;
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
|
2011-08-09 23:17:13 +00:00
|
|
|
if (!(fg = register_group(ctg))) {
|
2008-01-23 23:09:11 +00:00
|
|
|
continue;
|
2011-08-09 23:17:13 +00:00
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
|
|
|
|
for (var = ast_variable_browse(cfg, ctg); var; var = var->next) {
|
|
|
|
struct ast_call_feature *feature;
|
|
|
|
|
2008-12-11 17:06:16 +00:00
|
|
|
AST_RWLIST_RDLOCK(&feature_list);
|
2012-03-22 19:51:16 +00:00
|
|
|
if (!(feature = find_dynamic_feature(var->name)) &&
|
2008-12-11 17:06:16 +00:00
|
|
|
!(feature = ast_find_call_feature(var->name))) {
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2008-01-23 23:09:11 +00:00
|
|
|
ast_log(LOG_WARNING, "Feature '%s' was not found.\n", var->name);
|
|
|
|
continue;
|
|
|
|
}
|
2008-12-11 17:06:16 +00:00
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
2008-01-23 23:09:11 +00:00
|
|
|
|
|
|
|
register_group_feature(fg, var->value, feature);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
AST_RWLIST_UNLOCK(&feature_groups);
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Destroy the given dialplan usage context.
|
|
|
|
*
|
|
|
|
* \param doomed Parking lot usage context to destroy.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void destroy_dialplan_usage_context(struct parking_dp_context *doomed)
|
|
|
|
{
|
|
|
|
struct parking_dp_ramp *ramp;
|
|
|
|
struct parking_dp_spaces *spaces;
|
|
|
|
|
|
|
|
while ((ramp = AST_LIST_REMOVE_HEAD(&doomed->access_extens, node))) {
|
|
|
|
ast_free(ramp);
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
while ((spaces = AST_LIST_REMOVE_HEAD(&doomed->spaces, node))) {
|
|
|
|
ast_free(spaces);
|
|
|
|
}
|
|
|
|
while ((spaces = AST_LIST_REMOVE_HEAD(&doomed->hints, node))) {
|
|
|
|
ast_free(spaces);
|
|
|
|
}
|
|
|
|
ast_free(doomed);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Destroy the given dialplan usage map.
|
|
|
|
*
|
|
|
|
* \param doomed Parking lot usage map to destroy.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void destroy_dialplan_usage_map(struct parking_dp_map *doomed)
|
|
|
|
{
|
|
|
|
struct parking_dp_context *item;
|
2008-01-23 23:09:11 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
while ((item = AST_LIST_REMOVE_HEAD(doomed, node))) {
|
|
|
|
destroy_dialplan_usage_context(item);
|
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \internal
|
|
|
|
* \brief Create a new parking lot ramp dialplan usage node.
|
2008-01-23 23:09:11 +00:00
|
|
|
*
|
2011-08-16 17:23:08 +00:00
|
|
|
* \param exten Parking lot access ramp extension.
|
|
|
|
* \param exclusive TRUE if the parking lot access ramp extension is exclusive.
|
|
|
|
*
|
|
|
|
* \retval New usage ramp node on success.
|
|
|
|
* \retval NULL on error.
|
2008-01-23 23:09:11 +00:00
|
|
|
*/
|
2011-08-16 17:23:08 +00:00
|
|
|
static struct parking_dp_ramp *build_dialplan_useage_ramp(const char *exten, int exclusive)
|
2003-07-02 14:06:12 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct parking_dp_ramp *ramp_node;
|
2003-07-02 14:06:12 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ramp_node = ast_calloc(1, sizeof(*ramp_node) + strlen(exten));
|
|
|
|
if (!ramp_node) {
|
2007-06-06 14:45:29 +00:00
|
|
|
return NULL;
|
2008-03-04 23:04:29 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
ramp_node->exclusive = exclusive;
|
|
|
|
strcpy(ramp_node->exten, exten);
|
|
|
|
return ramp_node;
|
|
|
|
}
|
2007-06-06 14:45:29 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Add parking lot access ramp to the context ramp usage map.
|
|
|
|
*
|
|
|
|
* \param ramp_map Current parking lot context ramp usage map.
|
|
|
|
* \param exten Parking lot access ramp extension to add.
|
|
|
|
* \param exclusive TRUE if the parking lot access ramp extension is exclusive.
|
|
|
|
* \param lot Parking lot supplying reference data.
|
|
|
|
* \param complain TRUE if to complain of parking lot ramp conflicts.
|
|
|
|
*
|
|
|
|
* \retval 0 on success. The ramp_map is updated.
|
|
|
|
* \retval -1 on failure.
|
|
|
|
*/
|
|
|
|
static int usage_context_add_ramp(struct parking_dp_ramp_map *ramp_map, const char *exten, int exclusive, struct ast_parkinglot *lot, int complain)
|
|
|
|
{
|
|
|
|
struct parking_dp_ramp *cur_ramp;
|
|
|
|
struct parking_dp_ramp *new_ramp;
|
|
|
|
int cmp;
|
2007-06-06 14:45:29 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Make sure that exclusive is only 0 or 1 */
|
|
|
|
if (exclusive) {
|
|
|
|
exclusive = 1;
|
2003-07-02 14:06:12 +00:00
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(ramp_map, cur_ramp, node) {
|
|
|
|
cmp = strcmp(exten, cur_ramp->exten);
|
|
|
|
if (cmp > 0) {
|
|
|
|
/* The parking lot ramp goes after this node. */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (cmp == 0) {
|
|
|
|
/* The ramp is already in the map. */
|
|
|
|
if (complain && (cur_ramp->exclusive || exclusive)) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Parking lot '%s' parkext %s@%s used by another parking lot.\n",
|
|
|
|
lot->name, exten, lot->cfg.parking_con);
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
return 0;
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
/* The new parking lot ramp goes before this node. */
|
|
|
|
new_ramp = build_dialplan_useage_ramp(exten, exclusive);
|
|
|
|
if (!new_ramp) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
AST_LIST_INSERT_BEFORE_CURRENT(new_ramp, node);
|
|
|
|
return 0;
|
2010-07-09 21:57:21 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
2010-07-09 21:57:21 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* New parking lot access ramp goes on the end. */
|
|
|
|
new_ramp = build_dialplan_useage_ramp(exten, exclusive);
|
|
|
|
if (!new_ramp) {
|
|
|
|
return -1;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_LIST_INSERT_TAIL(ramp_map, new_ramp, node);
|
|
|
|
return 0;
|
|
|
|
}
|
2003-07-02 14:06:12 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Create a new parking lot spaces dialplan usage node.
|
|
|
|
*
|
|
|
|
* \param start First parking lot space to add.
|
|
|
|
* \param stop Last parking lot space to add.
|
|
|
|
*
|
|
|
|
* \retval New usage ramp node on success.
|
|
|
|
* \retval NULL on error.
|
|
|
|
*/
|
|
|
|
static struct parking_dp_spaces *build_dialplan_useage_spaces(int start, int stop)
|
|
|
|
{
|
|
|
|
struct parking_dp_spaces *spaces_node;
|
|
|
|
|
|
|
|
spaces_node = ast_calloc(1, sizeof(*spaces_node));
|
|
|
|
if (!spaces_node) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
spaces_node->start = start;
|
|
|
|
spaces_node->stop = stop;
|
|
|
|
return spaces_node;
|
2007-06-06 14:45:29 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Add parking lot spaces to the context space usage map.
|
|
|
|
*
|
|
|
|
* \param space_map Current parking lot context space usage map.
|
|
|
|
* \param start First parking lot space to add.
|
|
|
|
* \param stop Last parking lot space to add.
|
|
|
|
* \param lot Parking lot supplying reference data.
|
|
|
|
* \param complain TRUE if to complain of parking lot spaces conflicts.
|
|
|
|
*
|
|
|
|
* \retval 0 on success. The space_map is updated.
|
|
|
|
* \retval -1 on failure.
|
|
|
|
*/
|
|
|
|
static int usage_context_add_spaces(struct parking_dp_space_map *space_map, int start, int stop, struct ast_parkinglot *lot, int complain)
|
2010-09-15 19:23:56 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct parking_dp_spaces *cur_node;
|
|
|
|
struct parking_dp_spaces *expand_node;
|
|
|
|
struct parking_dp_spaces *new_node;
|
|
|
|
|
|
|
|
expand_node = NULL;
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(space_map, cur_node, node) {
|
|
|
|
/* NOTE: stop + 1 to combine immediately adjacent nodes into one. */
|
|
|
|
if (expand_node) {
|
|
|
|
/* The previous node is expanding to possibly eat following nodes. */
|
|
|
|
if (expand_node->stop + 1 < cur_node->start) {
|
|
|
|
/* Current node is completely after expanding node. */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (complain
|
|
|
|
&& ((cur_node->start <= start && start <= cur_node->stop)
|
|
|
|
|| (cur_node->start <= stop && stop <= cur_node->stop)
|
|
|
|
|| (start < cur_node->start && cur_node->stop < stop))) {
|
|
|
|
/* Only complain once per range add. */
|
|
|
|
complain = 0;
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Parking lot '%s' parkpos %d-%d@%s overlaps another parking lot.\n",
|
|
|
|
lot->name, start, stop, lot->cfg.parking_con);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Current node is eaten by the expanding node. */
|
|
|
|
if (expand_node->stop < cur_node->stop) {
|
|
|
|
expand_node->stop = cur_node->stop;
|
|
|
|
}
|
|
|
|
AST_LIST_REMOVE_CURRENT(node);
|
|
|
|
ast_free(cur_node);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cur_node->stop + 1 < start) {
|
|
|
|
/* New range is completely after current node. */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (stop + 1 < cur_node->start) {
|
|
|
|
/* New range is completely before current node. */
|
|
|
|
new_node = build_dialplan_useage_spaces(start, stop);
|
|
|
|
if (!new_node) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
AST_LIST_INSERT_BEFORE_CURRENT(new_node, node);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (complain
|
|
|
|
&& ((cur_node->start <= start && start <= cur_node->stop)
|
|
|
|
|| (cur_node->start <= stop && stop <= cur_node->stop)
|
|
|
|
|| (start < cur_node->start && cur_node->stop < stop))) {
|
|
|
|
/* Only complain once per range add. */
|
|
|
|
complain = 0;
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Parking lot '%s' parkpos %d-%d@%s overlaps another parking lot.\n",
|
|
|
|
lot->name, start, stop, lot->cfg.parking_con);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Current node range overlaps or is immediately adjacent to new range. */
|
|
|
|
if (start < cur_node->start) {
|
|
|
|
/* Expand the current node in the front. */
|
|
|
|
cur_node->start = start;
|
|
|
|
}
|
|
|
|
if (stop <= cur_node->stop) {
|
|
|
|
/* Current node is not expanding in the rear. */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
cur_node->stop = stop;
|
|
|
|
expand_node = cur_node;
|
|
|
|
}
|
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
|
|
|
|
|
|
|
if (expand_node) {
|
|
|
|
/*
|
|
|
|
* The previous node expanded and either ate all following nodes
|
|
|
|
* or it was the last node.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* New range goes on the end. */
|
|
|
|
new_node = build_dialplan_useage_spaces(start, stop);
|
|
|
|
if (!new_node) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
AST_LIST_INSERT_TAIL(space_map, new_node, node);
|
2010-09-15 19:23:56 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Add parking lot spaces to the context dialplan usage node.
|
|
|
|
*
|
|
|
|
* \param ctx_node Usage node to add parking lot spaces.
|
|
|
|
* \param lot Parking lot to add data to ctx_node.
|
|
|
|
* \param complain TRUE if to complain of parking lot ramp and spaces conflicts.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on error.
|
|
|
|
*/
|
|
|
|
static int dialplan_usage_add_parkinglot_data(struct parking_dp_context *ctx_node, struct ast_parkinglot *lot, int complain)
|
2010-09-15 19:23:56 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
if (usage_context_add_ramp(&ctx_node->access_extens, lot->cfg.parkext,
|
|
|
|
lot->cfg.parkext_exclusive, lot, complain)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (usage_context_add_spaces(&ctx_node->spaces, lot->cfg.parking_start,
|
|
|
|
lot->cfg.parking_stop, lot, complain)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (lot->cfg.parkaddhints
|
|
|
|
&& usage_context_add_spaces(&ctx_node->hints, lot->cfg.parking_start,
|
|
|
|
lot->cfg.parking_stop, lot, 0)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
2010-09-15 19:23:56 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Create a new parking lot context dialplan usage node.
|
|
|
|
*
|
|
|
|
* \param lot Parking lot to create a new dialplan usage from.
|
|
|
|
*
|
|
|
|
* \retval New usage context node on success.
|
|
|
|
* \retval NULL on error.
|
|
|
|
*/
|
|
|
|
static struct parking_dp_context *build_dialplan_useage_context(struct ast_parkinglot *lot)
|
2007-06-06 14:45:29 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct parking_dp_context *ctx_node;
|
2008-01-23 23:09:11 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ctx_node = ast_calloc(1, sizeof(*ctx_node) + strlen(lot->cfg.parking_con));
|
|
|
|
if (!ctx_node) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (dialplan_usage_add_parkinglot_data(ctx_node, lot, 0)) {
|
|
|
|
destroy_dialplan_usage_context(ctx_node);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
strcpy(ctx_node->context, lot->cfg.parking_con);
|
|
|
|
return ctx_node;
|
2003-07-02 14:06:12 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Add the given parking lot dialplan usage to the dialplan usage map.
|
|
|
|
*
|
|
|
|
* \param usage_map Parking lot usage map to add the given parking lot.
|
|
|
|
* \param lot Parking lot to add dialplan usage.
|
|
|
|
* \param complain TRUE if to complain of parking lot ramp and spaces conflicts.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on error.
|
|
|
|
*/
|
|
|
|
static int dialplan_usage_add_parkinglot(struct parking_dp_map *usage_map, struct ast_parkinglot *lot, int complain)
|
2008-01-23 23:09:11 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct parking_dp_context *cur_ctx;
|
|
|
|
struct parking_dp_context *new_ctx;
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(usage_map, cur_ctx, node) {
|
|
|
|
cmp = strcmp(lot->cfg.parking_con, cur_ctx->context);
|
|
|
|
if (cmp > 0) {
|
|
|
|
/* The parking lot context goes after this node. */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (cmp == 0) {
|
|
|
|
/* This is the node we will add parking lot spaces to the map. */
|
|
|
|
return dialplan_usage_add_parkinglot_data(cur_ctx, lot, complain);
|
|
|
|
}
|
|
|
|
/* The new parking lot context goes before this node. */
|
|
|
|
new_ctx = build_dialplan_useage_context(lot);
|
|
|
|
if (!new_ctx) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
AST_LIST_INSERT_BEFORE_CURRENT(new_ctx, node);
|
|
|
|
return 0;
|
2008-03-04 23:04:29 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
2003-07-02 14:06:12 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* New parking lot context goes on the end. */
|
|
|
|
new_ctx = build_dialplan_useage_context(lot);
|
|
|
|
if (!new_ctx) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
AST_LIST_INSERT_TAIL(usage_map, new_ctx, node);
|
|
|
|
return 0;
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
2005-07-25 17:31:53 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \internal
|
|
|
|
* \brief Build the dialplan usage map of the current parking lot container.
|
|
|
|
*
|
|
|
|
* \param usage_map Parking lot usage map. Must already be initialized.
|
|
|
|
* \param complain TRUE if to complain of parking lot ramp and spaces conflicts.
|
|
|
|
*
|
|
|
|
* \retval 0 on success. The usage_map is filled in.
|
|
|
|
* \retval -1 on failure. Built usage_map is incomplete.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2011-08-16 17:23:08 +00:00
|
|
|
static int build_dialplan_useage_map(struct parking_dp_map *usage_map, int complain)
|
2004-01-30 05:49:44 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
int status = 0;
|
|
|
|
struct ao2_iterator iter;
|
|
|
|
struct ast_parkinglot *curlot;
|
2009-10-07 22:58:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* For all parking lots */
|
|
|
|
iter = ao2_iterator_init(parkinglots, 0);
|
|
|
|
for (; (curlot = ao2_iterator_next(&iter)); ao2_ref(curlot, -1)) {
|
|
|
|
/* Add the parking lot to the map. */
|
|
|
|
if (dialplan_usage_add_parkinglot(usage_map, curlot, complain)) {
|
|
|
|
ao2_ref(curlot, -1);
|
|
|
|
status = -1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ao2_iterator_destroy(&iter);
|
2009-10-07 22:58:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
return status;
|
2004-01-30 05:49:44 +00:00
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \internal
|
|
|
|
* \brief Remove the given extension if it exists.
|
|
|
|
*
|
|
|
|
* \param context Dialplan database context name.
|
|
|
|
* \param exten Extension to remove.
|
|
|
|
* \param priority Extension priority to remove.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2011-08-16 17:23:08 +00:00
|
|
|
static void remove_exten_if_exist(const char *context, const char *exten, int priority)
|
2006-03-06 23:12:48 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
struct pbx_find_info q = { .stacklen = 0 }; /* the rest is reset in pbx_find_extension */
|
2006-03-06 23:12:48 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (pbx_find_extension(NULL, NULL, &q, context, exten, priority, NULL, NULL,
|
|
|
|
E_MATCH)) {
|
|
|
|
ast_debug(1, "Removing unneeded parking lot exten: %s@%s priority:%d\n",
|
|
|
|
context, exten, priority);
|
|
|
|
ast_context_remove_extension(context, exten, priority, registrar);
|
2006-03-06 23:12:48 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2006-03-06 23:12:48 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Remove unused parking lot access ramp items.
|
|
|
|
*
|
|
|
|
* \param context Dialplan database context name.
|
|
|
|
* \param old_ramps Before configuration reload access ramp usage map.
|
|
|
|
* \param new_ramps After configuration reload access ramp usage map.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* Remove access ramp items that were in the old context but not in the
|
|
|
|
* new context.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void remove_dead_ramp_usage(const char *context, struct parking_dp_ramp_map *old_ramps, struct parking_dp_ramp_map *new_ramps)
|
|
|
|
{
|
|
|
|
struct parking_dp_ramp *old_ramp;
|
|
|
|
struct parking_dp_ramp *new_ramp;
|
|
|
|
int cmp;
|
2009-02-18 22:51:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
old_ramp = AST_LIST_FIRST(old_ramps);
|
|
|
|
new_ramp = AST_LIST_FIRST(new_ramps);
|
2008-01-23 23:09:11 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
while (new_ramp) {
|
|
|
|
if (!old_ramp) {
|
|
|
|
/* No old ramps left, so no dead ramps can remain. */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
cmp = strcmp(old_ramp->exten, new_ramp->exten);
|
|
|
|
if (cmp < 0) {
|
|
|
|
/* New map does not have old ramp. */
|
|
|
|
remove_exten_if_exist(context, old_ramp->exten, 1);
|
|
|
|
old_ramp = AST_LIST_NEXT(old_ramp, node);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (cmp == 0) {
|
|
|
|
/* Old and new map have this ramp. */
|
|
|
|
old_ramp = AST_LIST_NEXT(old_ramp, node);
|
|
|
|
} else {
|
|
|
|
/* Old map does not have new ramp. */
|
|
|
|
}
|
|
|
|
new_ramp = AST_LIST_NEXT(new_ramp, node);
|
2006-03-06 23:12:48 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Any old ramps left must be dead. */
|
|
|
|
for (; old_ramp; old_ramp = AST_LIST_NEXT(old_ramp, node)) {
|
|
|
|
remove_exten_if_exist(context, old_ramp->exten, 1);
|
|
|
|
}
|
|
|
|
}
|
2009-02-18 22:51:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Destroy the given parking space.
|
|
|
|
*
|
|
|
|
* \param context Dialplan database context name.
|
|
|
|
* \param space Parking space.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void destroy_space(const char *context, int space)
|
|
|
|
{
|
|
|
|
char exten[AST_MAX_EXTENSION];
|
|
|
|
|
|
|
|
/* Destroy priorities of the parking space that we registered. */
|
|
|
|
snprintf(exten, sizeof(exten), "%d", space);
|
|
|
|
remove_exten_if_exist(context, exten, PRIORITY_HINT);
|
|
|
|
remove_exten_if_exist(context, exten, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Remove unused parking lot space items.
|
|
|
|
*
|
|
|
|
* \param context Dialplan database context name.
|
|
|
|
* \param old_spaces Before configuration reload parking space usage map.
|
|
|
|
* \param new_spaces After configuration reload parking space usage map.
|
|
|
|
* \param destroy_space Function to destroy parking space item.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* Remove parking space items that were in the old context but
|
|
|
|
* not in the new context.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void remove_dead_spaces_usage(const char *context,
|
|
|
|
struct parking_dp_space_map *old_spaces, struct parking_dp_space_map *new_spaces,
|
|
|
|
void (*destroy_space)(const char *context, int space))
|
|
|
|
{
|
|
|
|
struct parking_dp_spaces *old_range;
|
|
|
|
struct parking_dp_spaces *new_range;
|
|
|
|
int space;/*!< Current position in the current old range. */
|
|
|
|
int stop;
|
|
|
|
|
|
|
|
old_range = AST_LIST_FIRST(old_spaces);
|
|
|
|
new_range = AST_LIST_FIRST(new_spaces);
|
|
|
|
space = -1;
|
|
|
|
|
|
|
|
while (old_range) {
|
|
|
|
if (space < old_range->start) {
|
|
|
|
space = old_range->start;
|
|
|
|
}
|
|
|
|
if (new_range) {
|
|
|
|
if (space < new_range->start) {
|
|
|
|
/* Current position in old range starts before new range. */
|
|
|
|
if (old_range->stop < new_range->start) {
|
|
|
|
/* Old range ends before new range. */
|
|
|
|
stop = old_range->stop;
|
|
|
|
old_range = AST_LIST_NEXT(old_range, node);
|
|
|
|
} else {
|
|
|
|
/* Tail of old range overlaps new range. */
|
|
|
|
stop = new_range->start - 1;
|
|
|
|
}
|
|
|
|
} else if (/* new_range->start <= space && */ space <= new_range->stop) {
|
|
|
|
/* Current position in old range overlaps new range. */
|
|
|
|
if (old_range->stop <= new_range->stop) {
|
|
|
|
/* Old range ends at or before new range. */
|
|
|
|
old_range = AST_LIST_NEXT(old_range, node);
|
|
|
|
} else {
|
|
|
|
/* Old range extends beyond end of new range. */
|
|
|
|
space = new_range->stop + 1;
|
|
|
|
new_range = AST_LIST_NEXT(new_range, node);
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
} else /* if (new_range->stop < space) */ {
|
|
|
|
/* Current position in old range starts after new range. */
|
|
|
|
new_range = AST_LIST_NEXT(new_range, node);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* No more new ranges. All remaining old spaces are dead. */
|
|
|
|
stop = old_range->stop;
|
|
|
|
old_range = AST_LIST_NEXT(old_range, node);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Destroy dead parking spaces. */
|
|
|
|
for (; space <= stop; ++space) {
|
|
|
|
destroy_space(context, space);
|
|
|
|
}
|
2009-02-18 22:51:38 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2009-02-18 22:51:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Remove unused parking lot context items.
|
|
|
|
*
|
|
|
|
* \param context Dialplan database context name.
|
|
|
|
* \param old_ctx Before configuration reload context usage map.
|
|
|
|
* \param new_ctx After configuration reload context usage map.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* Remove context usage items that were in the old context but not in the
|
|
|
|
* new context.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void remove_dead_context_usage(const char *context, struct parking_dp_context *old_ctx, struct parking_dp_context *new_ctx)
|
|
|
|
{
|
|
|
|
remove_dead_ramp_usage(context, &old_ctx->access_extens, &new_ctx->access_extens);
|
|
|
|
remove_dead_spaces_usage(context, &old_ctx->spaces, &new_ctx->spaces, destroy_space);
|
|
|
|
#if 0
|
|
|
|
/* I don't think we should destroy hints if the parking space still exists. */
|
|
|
|
remove_dead_spaces_usage(context, &old_ctx->hints, &new_ctx->hints, destroy_space_hint);
|
|
|
|
#endif
|
|
|
|
}
|
2009-02-18 22:51:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Remove unused parking lot dialplan items.
|
|
|
|
*
|
|
|
|
* \param old_map Before configuration reload dialplan usage map.
|
|
|
|
* \param new_map After configuration reload dialplan usage map.
|
|
|
|
*
|
|
|
|
* \details
|
|
|
|
* Remove dialplan items that were in the old map but not in the
|
|
|
|
* new map.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void remove_dead_dialplan_useage(struct parking_dp_map *old_map, struct parking_dp_map *new_map)
|
|
|
|
{
|
|
|
|
struct parking_dp_context *old_ctx;
|
|
|
|
struct parking_dp_context *new_ctx;
|
|
|
|
struct ast_context *con;
|
|
|
|
int cmp;
|
|
|
|
|
|
|
|
old_ctx = AST_LIST_FIRST(old_map);
|
|
|
|
new_ctx = AST_LIST_FIRST(new_map);
|
|
|
|
|
|
|
|
while (new_ctx) {
|
|
|
|
if (!old_ctx) {
|
|
|
|
/* No old contexts left, so no dead stuff can remain. */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
cmp = strcmp(old_ctx->context, new_ctx->context);
|
|
|
|
if (cmp < 0) {
|
|
|
|
/* New map does not have old map context. */
|
|
|
|
con = ast_context_find(old_ctx->context);
|
|
|
|
if (con) {
|
|
|
|
ast_context_destroy(con, registrar);
|
|
|
|
}
|
|
|
|
old_ctx = AST_LIST_NEXT(old_ctx, node);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (cmp == 0) {
|
|
|
|
/* Old and new map have this context. */
|
|
|
|
remove_dead_context_usage(old_ctx->context, old_ctx, new_ctx);
|
|
|
|
old_ctx = AST_LIST_NEXT(old_ctx, node);
|
|
|
|
} else {
|
|
|
|
/* Old map does not have new map context. */
|
|
|
|
}
|
|
|
|
new_ctx = AST_LIST_NEXT(new_ctx, node);
|
2006-03-06 23:12:48 +00:00
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Any old contexts left must be dead. */
|
|
|
|
for (; old_ctx; old_ctx = AST_LIST_NEXT(old_ctx, node)) {
|
|
|
|
con = ast_context_find(old_ctx->context);
|
|
|
|
if (con) {
|
|
|
|
ast_context_destroy(con, registrar);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
static int parkinglot_markall_cb(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_parkinglot *parkinglot = obj;
|
2009-02-18 22:51:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
parkinglot->the_mark = 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parkinglot_is_marked_cb(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_parkinglot *parkinglot = obj;
|
|
|
|
|
|
|
|
if (parkinglot->the_mark) {
|
|
|
|
if (AST_LIST_EMPTY(&parkinglot->parkings)) {
|
|
|
|
/* This parking lot can actually be deleted. */
|
|
|
|
return CMP_MATCH;
|
|
|
|
}
|
|
|
|
/* Try reloading later when parking lot is empty. */
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Parking lot %s has parked calls. Could not remove.\n",
|
|
|
|
parkinglot->name);
|
|
|
|
parkinglot->disabled = 1;
|
|
|
|
force_reload_load = 1;
|
2006-03-06 23:12:48 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int parkinglot_activate_cb(void *obj, void *arg, int flags)
|
|
|
|
{
|
|
|
|
struct ast_parkinglot *parkinglot = obj;
|
|
|
|
|
|
|
|
if (parkinglot->the_mark) {
|
|
|
|
/*
|
|
|
|
* Don't activate a parking lot that still bears the_mark since
|
|
|
|
* it is effectively deleted.
|
|
|
|
*/
|
|
|
|
return 0;
|
2006-03-06 23:12:48 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (parkinglot_activate(parkinglot)) {
|
|
|
|
/*
|
|
|
|
* The parking lot failed to activate. Allow reloading later to
|
|
|
|
* see if that fixes it.
|
|
|
|
*/
|
|
|
|
force_reload_load = 1;
|
|
|
|
ast_log(LOG_WARNING, "Parking lot %s not open for business.\n", parkinglot->name);
|
|
|
|
} else {
|
|
|
|
ast_debug(1, "Parking lot %s now open for business. (parkpos %d-%d)\n",
|
|
|
|
parkinglot->name, parkinglot->cfg.parking_start,
|
|
|
|
parkinglot->cfg.parking_stop);
|
|
|
|
}
|
2009-02-18 22:51:38 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int load_config(int reload)
|
|
|
|
{
|
|
|
|
struct ast_flags config_flags = {
|
|
|
|
reload && !force_reload_load ? CONFIG_FLAG_FILEUNCHANGED : 0 };
|
|
|
|
struct ast_config *cfg;
|
|
|
|
struct parking_dp_map old_usage_map = AST_LIST_HEAD_NOLOCK_INIT_VALUE;
|
|
|
|
struct parking_dp_map new_usage_map = AST_LIST_HEAD_NOLOCK_INIT_VALUE;
|
|
|
|
|
|
|
|
/* We are reloading now and have already determined if we will force the reload. */
|
|
|
|
force_reload_load = 0;
|
|
|
|
|
|
|
|
if (!default_parkinglot) {
|
|
|
|
/* Must create the default default parking lot */
|
|
|
|
default_parkinglot = build_parkinglot(DEFAULT_PARKINGLOT, NULL);
|
|
|
|
if (!default_parkinglot) {
|
|
|
|
ast_log(LOG_ERROR, "Configuration of default default parking lot failed.\n");
|
|
|
|
return -1;
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_debug(1, "Configuration of default default parking lot done.\n");
|
|
|
|
parkinglot_addref(default_parkinglot);
|
2006-03-06 23:12:48 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
cfg = ast_config_load2("features.conf", "features", config_flags);
|
|
|
|
if (cfg == CONFIG_STATUS_FILEUNCHANGED) {
|
|
|
|
/* No sense in asking for reload trouble if nothing changed. */
|
|
|
|
ast_debug(1, "features.conf did not change.\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (cfg == CONFIG_STATUS_FILEMISSING
|
|
|
|
|| cfg == CONFIG_STATUS_FILEINVALID) {
|
|
|
|
ast_log(LOG_WARNING, "Could not load features.conf\n");
|
|
|
|
return 0;
|
|
|
|
}
|
2010-02-26 17:13:36 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Save current parking lot dialplan needs. */
|
|
|
|
if (build_dialplan_useage_map(&old_usage_map, 0)) {
|
|
|
|
destroy_dialplan_usage_map(&old_usage_map);
|
2010-02-26 17:13:36 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
/* Allow reloading later to see if conditions have improved. */
|
|
|
|
force_reload_load = 1;
|
|
|
|
return -1;
|
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ao2_t_callback(parkinglots, OBJ_NODATA, parkinglot_markall_cb, NULL,
|
|
|
|
"callback to mark all parking lots");
|
|
|
|
process_config(cfg);
|
|
|
|
ast_config_destroy(cfg);
|
|
|
|
ao2_t_callback(parkinglots, OBJ_NODATA | OBJ_UNLINK, parkinglot_is_marked_cb, NULL,
|
|
|
|
"callback to remove marked parking lots");
|
|
|
|
|
|
|
|
/* Save updated parking lot dialplan needs. */
|
|
|
|
if (build_dialplan_useage_map(&new_usage_map, 1)) {
|
|
|
|
/*
|
|
|
|
* Yuck, if this failure caused any parking lot dialplan items
|
|
|
|
* to be lost, they will likely remain lost until Asterisk is
|
|
|
|
* restarted.
|
|
|
|
*/
|
|
|
|
destroy_dialplan_usage_map(&old_usage_map);
|
|
|
|
destroy_dialplan_usage_map(&new_usage_map);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Remove no longer needed parking lot dialplan usage. */
|
|
|
|
remove_dead_dialplan_useage(&old_usage_map, &new_usage_map);
|
|
|
|
|
|
|
|
destroy_dialplan_usage_map(&old_usage_map);
|
|
|
|
destroy_dialplan_usage_map(&new_usage_map);
|
|
|
|
|
|
|
|
ao2_t_callback(parkinglots, OBJ_NODATA, parkinglot_activate_cb, NULL,
|
|
|
|
"callback to activate all parking lots");
|
2006-03-06 23:12:48 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \brief CLI command to list configured features
|
|
|
|
* \param e
|
2008-01-23 23:09:11 +00:00
|
|
|
* \param cmd
|
|
|
|
* \param a
|
2011-08-16 17:23:08 +00:00
|
|
|
*
|
2008-01-23 23:09:11 +00:00
|
|
|
* \retval CLI_SUCCESS on success.
|
|
|
|
* \retval NULL when tab completion is used.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2011-08-16 17:23:08 +00:00
|
|
|
static char *handle_feature_show(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a)
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
int i;
|
|
|
|
struct ast_call_feature *feature;
|
2008-04-21 23:42:45 +00:00
|
|
|
struct ao2_iterator iter;
|
|
|
|
struct ast_parkinglot *curlot;
|
2011-08-16 17:23:08 +00:00
|
|
|
#define HFS_FORMAT "%-25s %-7s %-7s\n"
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
switch (cmd) {
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
case CLI_INIT:
|
2011-08-16 17:23:08 +00:00
|
|
|
e->command = "features show";
|
2008-01-23 23:09:11 +00:00
|
|
|
e->usage =
|
2011-08-16 17:23:08 +00:00
|
|
|
"Usage: features show\n"
|
|
|
|
" Lists configured features\n";
|
2008-01-23 23:09:11 +00:00
|
|
|
return NULL;
|
|
|
|
case CLI_GENERATE:
|
|
|
|
return NULL;
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
}
|
2005-10-13 23:58:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_cli(a->fd, HFS_FORMAT, "Builtin Feature", "Default", "Current");
|
|
|
|
ast_cli(a->fd, HFS_FORMAT, "---------------", "-------", "-------");
|
|
|
|
|
|
|
|
ast_cli(a->fd, HFS_FORMAT, "Pickup", "*8", ast_pickup_ext()); /* default hardcoded above, so we'll hardcode it here */
|
2005-10-13 23:58:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_rwlock_rdlock(&features_lock);
|
|
|
|
for (i = 0; i < FEATURES_COUNT; i++)
|
|
|
|
ast_cli(a->fd, HFS_FORMAT, builtin_features[i].fname, builtin_features[i].default_exten, builtin_features[i].exten);
|
|
|
|
ast_rwlock_unlock(&features_lock);
|
2005-01-04 04:01:40 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_cli(a->fd, "\n");
|
|
|
|
ast_cli(a->fd, HFS_FORMAT, "Dynamic Feature", "Default", "Current");
|
|
|
|
ast_cli(a->fd, HFS_FORMAT, "---------------", "-------", "-------");
|
|
|
|
if (AST_RWLIST_EMPTY(&feature_list)) {
|
|
|
|
ast_cli(a->fd, "(none)\n");
|
|
|
|
} else {
|
|
|
|
AST_RWLIST_RDLOCK(&feature_list);
|
|
|
|
AST_RWLIST_TRAVERSE(&feature_list, feature, feature_entry) {
|
|
|
|
ast_cli(a->fd, HFS_FORMAT, feature->sname, "no def", feature->exten);
|
|
|
|
}
|
|
|
|
AST_RWLIST_UNLOCK(&feature_list);
|
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_cli(a->fd, "\nFeature Groups:\n");
|
|
|
|
ast_cli(a->fd, "---------------\n");
|
|
|
|
if (AST_RWLIST_EMPTY(&feature_groups)) {
|
|
|
|
ast_cli(a->fd, "(none)\n");
|
|
|
|
} else {
|
|
|
|
struct feature_group *fg;
|
|
|
|
struct feature_group_exten *fge;
|
|
|
|
|
|
|
|
AST_RWLIST_RDLOCK(&feature_groups);
|
|
|
|
AST_RWLIST_TRAVERSE(&feature_groups, fg, entry) {
|
|
|
|
ast_cli(a->fd, "===> Group: %s\n", fg->gname);
|
|
|
|
AST_LIST_TRAVERSE(&fg->features, fge, entry) {
|
|
|
|
ast_cli(a->fd, "===> --> %s (%s)\n", fge->feature->sname, fge->exten);
|
|
|
|
}
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
AST_RWLIST_UNLOCK(&feature_groups);
|
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
iter = ao2_iterator_init(parkinglots, 0);
|
|
|
|
while ((curlot = ao2_iterator_next(&iter))) {
|
|
|
|
ast_cli(a->fd, "\nCall parking (Parking lot: %s)\n", curlot->name);
|
|
|
|
ast_cli(a->fd, "------------\n");
|
|
|
|
ast_cli(a->fd,"%-22s: %s\n", "Parking extension", curlot->cfg.parkext);
|
|
|
|
ast_cli(a->fd,"%-22s: %s\n", "Parking context", curlot->cfg.parking_con);
|
|
|
|
ast_cli(a->fd,"%-22s: %d-%d\n", "Parked call extensions",
|
|
|
|
curlot->cfg.parking_start, curlot->cfg.parking_stop);
|
|
|
|
ast_cli(a->fd,"%-22s: %d ms\n", "Parkingtime", curlot->cfg.parkingtime);
|
2012-01-20 20:47:42 +00:00
|
|
|
ast_cli(a->fd,"%-22s: %s\n", "Comeback to origin",
|
|
|
|
(curlot->cfg.comebacktoorigin ? "yes" : "no"));
|
|
|
|
ast_cli(a->fd,"%-22s: %s%s\n", "Comeback context",
|
|
|
|
curlot->cfg.comebackcontext, (curlot->cfg.comebacktoorigin ?
|
|
|
|
" (comebacktoorigin=yes, not used)" : ""));
|
|
|
|
ast_cli(a->fd,"%-22s: %d\n", "Comeback dial time",
|
|
|
|
curlot->cfg.comebackdialtime);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_cli(a->fd,"%-22s: %s\n", "MusicOnHold class", curlot->cfg.mohclass);
|
|
|
|
ast_cli(a->fd,"%-22s: %s\n", "Enabled", AST_CLI_YESNO(!curlot->disabled));
|
|
|
|
ast_cli(a->fd,"\n");
|
2008-04-21 23:42:45 +00:00
|
|
|
ao2_ref(curlot, -1);
|
2006-08-31 21:00:20 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
ao2_iterator_destroy(&iter);
|
2006-08-31 21:00:20 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
return CLI_SUCCESS;
|
|
|
|
}
|
2006-08-31 21:00:20 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
int ast_features_reload(void)
|
|
|
|
{
|
|
|
|
struct ast_context *con;
|
|
|
|
int res;
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_mutex_lock(&features_reload_lock);/* Searialize reloading features.conf */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Always destroy the parking_con_dial context to remove buildup
|
|
|
|
* of recalled extensions in the context. At worst, the parked
|
|
|
|
* call gets hungup attempting to run an invalid extension when
|
|
|
|
* we are trying to callback the parker or the preset return
|
|
|
|
* extension. This is a small window of opportunity on an
|
|
|
|
* execution chain that is not expected to happen very often.
|
|
|
|
*/
|
|
|
|
con = ast_context_find(parking_con_dial);
|
|
|
|
if (con) {
|
|
|
|
ast_context_destroy(con, registrar);
|
|
|
|
}
|
|
|
|
|
|
|
|
res = load_config(1);
|
|
|
|
ast_mutex_unlock(&features_reload_lock);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *handle_features_reload(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a)
|
|
|
|
{
|
2012-03-22 19:51:16 +00:00
|
|
|
switch (cmd) {
|
2011-08-16 17:23:08 +00:00
|
|
|
case CLI_INIT:
|
|
|
|
e->command = "features reload";
|
|
|
|
e->usage =
|
|
|
|
"Usage: features reload\n"
|
|
|
|
" Reloads configured call features from features.conf\n";
|
|
|
|
return NULL;
|
|
|
|
case CLI_GENERATE:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
ast_features_reload();
|
|
|
|
|
|
|
|
return CLI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief Actual bridge
|
|
|
|
* \param chan
|
|
|
|
* \param tmpchan
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2011-08-16 17:23:08 +00:00
|
|
|
* Stop hold music, lock both channels, masq channels,
|
|
|
|
* after bridge return channel to next priority.
|
|
|
|
*/
|
|
|
|
static void do_bridge_masquerade(struct ast_channel *chan, struct ast_channel *tmpchan)
|
|
|
|
{
|
|
|
|
ast_moh_stop(chan);
|
|
|
|
ast_channel_lock_both(chan, tmpchan);
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_setstate(tmpchan, ast_channel_state(chan));
|
2012-02-24 00:32:20 +00:00
|
|
|
ast_format_copy(ast_channel_readformat(tmpchan), ast_channel_readformat(chan));
|
|
|
|
ast_format_copy(ast_channel_writeformat(tmpchan), ast_channel_writeformat(chan));
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_channel_unlock(chan);
|
|
|
|
ast_channel_unlock(tmpchan);
|
|
|
|
|
|
|
|
ast_channel_masquerade(tmpchan, chan);
|
|
|
|
|
|
|
|
/* must be done without any channel locks held */
|
|
|
|
ast_do_masquerade(tmpchan);
|
|
|
|
|
|
|
|
/* when returning from bridge, the channel will continue at the next priority */
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_explicit_goto(tmpchan, ast_channel_context(chan), ast_channel_exten(chan), ast_channel_priority(chan) + 1);
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief Bridge channels together
|
|
|
|
* \param s
|
|
|
|
* \param m
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
|
|
|
* Make sure valid channels were specified,
|
2011-08-16 17:23:08 +00:00
|
|
|
* send errors if any of the channels could not be found/locked, answer channels if needed,
|
2012-03-22 19:51:16 +00:00
|
|
|
* create the placeholder channels and grab the other channels
|
|
|
|
* make the channels compatible, send error if we fail doing so
|
2011-08-16 17:23:08 +00:00
|
|
|
* setup the bridge thread object and start the bridge.
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2011-08-16 17:23:08 +00:00
|
|
|
* \retval 0 on success or on incorrect use.
|
|
|
|
* \retval 1 on failure to bridge channels.
|
|
|
|
*/
|
|
|
|
static int action_bridge(struct mansession *s, const struct message *m)
|
|
|
|
{
|
|
|
|
const char *channela = astman_get_header(m, "Channel1");
|
|
|
|
const char *channelb = astman_get_header(m, "Channel2");
|
|
|
|
const char *playtone = astman_get_header(m, "Tone");
|
|
|
|
struct ast_channel *chana = NULL, *chanb = NULL, *chans[2];
|
|
|
|
struct ast_channel *tmpchana = NULL, *tmpchanb = NULL;
|
|
|
|
struct ast_bridge_thread_obj *tobj = NULL;
|
|
|
|
|
|
|
|
/* make sure valid channels were specified */
|
|
|
|
if (ast_strlen_zero(channela) || ast_strlen_zero(channelb)) {
|
|
|
|
astman_send_error(s, m, "Missing channel parameter in request");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Start with chana */
|
|
|
|
chana = ast_channel_get_by_name_prefix(channela, strlen(channela));
|
|
|
|
|
|
|
|
/* send errors if any of the channels could not be found/locked */
|
|
|
|
if (!chana) {
|
|
|
|
char buf[256];
|
|
|
|
snprintf(buf, sizeof(buf), "Channel1 does not exists: %s", channela);
|
|
|
|
astman_send_error(s, m, buf);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Answer the channels if needed */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chana) != AST_STATE_UP)
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_answer(chana);
|
|
|
|
|
|
|
|
/* create the placeholder channels and grab the other channels */
|
2012-03-22 19:51:16 +00:00
|
|
|
if (!(tmpchana = ast_channel_alloc(0, AST_STATE_DOWN, NULL, NULL, NULL,
|
2012-01-24 20:12:09 +00:00
|
|
|
NULL, NULL, ast_channel_linkedid(chana), 0, "Bridge/%s", ast_channel_name(chana)))) {
|
2011-08-16 17:23:08 +00:00
|
|
|
astman_send_error(s, m, "Unable to create temporary channel!");
|
|
|
|
chana = ast_channel_unref(chana);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
do_bridge_masquerade(chana, tmpchana);
|
|
|
|
|
|
|
|
chana = ast_channel_unref(chana);
|
|
|
|
|
|
|
|
/* now do chanb */
|
|
|
|
chanb = ast_channel_get_by_name_prefix(channelb, strlen(channelb));
|
|
|
|
/* send errors if any of the channels could not be found/locked */
|
|
|
|
if (!chanb) {
|
|
|
|
char buf[256];
|
|
|
|
snprintf(buf, sizeof(buf), "Channel2 does not exists: %s", channelb);
|
|
|
|
ast_hangup(tmpchana);
|
|
|
|
astman_send_error(s, m, buf);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Answer the channels if needed */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(chanb) != AST_STATE_UP)
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_answer(chanb);
|
|
|
|
|
|
|
|
/* create the placeholder channels and grab the other channels */
|
2012-03-22 19:51:16 +00:00
|
|
|
if (!(tmpchanb = ast_channel_alloc(0, AST_STATE_DOWN, NULL, NULL, NULL,
|
2012-01-24 20:12:09 +00:00
|
|
|
NULL, NULL, ast_channel_linkedid(chanb), 0, "Bridge/%s", ast_channel_name(chanb)))) {
|
2011-08-16 17:23:08 +00:00
|
|
|
astman_send_error(s, m, "Unable to create temporary channels!");
|
|
|
|
ast_hangup(tmpchana);
|
|
|
|
chanb = ast_channel_unref(chanb);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
do_bridge_masquerade(chanb, tmpchanb);
|
|
|
|
|
|
|
|
chanb = ast_channel_unref(chanb);
|
|
|
|
|
|
|
|
/* make the channels compatible, send error if we fail doing so */
|
|
|
|
if (ast_channel_make_compatible(tmpchana, tmpchanb)) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Could not make channels %s and %s compatible for manager bridge\n", ast_channel_name(tmpchana), ast_channel_name(tmpchanb));
|
2011-08-16 17:23:08 +00:00
|
|
|
astman_send_error(s, m, "Could not make channels compatible for manager bridge");
|
|
|
|
ast_hangup(tmpchana);
|
|
|
|
ast_hangup(tmpchanb);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* setup the bridge thread object and start the bridge */
|
|
|
|
if (!(tobj = ast_calloc(1, sizeof(*tobj)))) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Unable to spawn a new bridge thread on %s and %s: %s\n", ast_channel_name(tmpchana), ast_channel_name(tmpchanb), strerror(errno));
|
2011-08-16 17:23:08 +00:00
|
|
|
astman_send_error(s, m, "Unable to spawn a new bridge thread");
|
|
|
|
ast_hangup(tmpchana);
|
|
|
|
ast_hangup(tmpchanb);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
tobj->chan = tmpchana;
|
|
|
|
tobj->peer = tmpchanb;
|
|
|
|
tobj->return_to_pbx = 1;
|
|
|
|
|
|
|
|
if (ast_true(playtone)) {
|
2012-01-24 20:12:09 +00:00
|
|
|
if (!ast_strlen_zero(xfersound) && !ast_streamfile(tmpchanb, xfersound, ast_channel_language(tmpchanb))) {
|
2011-08-16 17:23:08 +00:00
|
|
|
if (ast_waitstream(tmpchanb, "") < 0)
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Failed to play a courtesy tone on chan %s\n", ast_channel_name(tmpchanb));
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
chans[0] = tmpchana;
|
|
|
|
chans[1] = tmpchanb;
|
|
|
|
|
|
|
|
ast_manager_event_multichan(EVENT_FLAG_CALL, "BridgeAction", 2, chans,
|
|
|
|
"Response: Success\r\n"
|
|
|
|
"Channel1: %s\r\n"
|
2012-01-09 22:15:50 +00:00
|
|
|
"Channel2: %s\r\n", ast_channel_name(tmpchana), ast_channel_name(tmpchanb));
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
bridge_call_thread_launch(tobj);
|
|
|
|
|
|
|
|
astman_send_ack(s, m, "Launched bridge thread with success");
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief CLI command to list parked calls
|
2012-03-22 19:51:16 +00:00
|
|
|
* \param e
|
2011-08-16 17:23:08 +00:00
|
|
|
* \param cmd
|
|
|
|
* \param a
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2011-08-16 17:23:08 +00:00
|
|
|
* Check right usage, lock parking lot, display parked calls, unlock parking lot list.
|
|
|
|
* \retval CLI_SUCCESS on success.
|
|
|
|
* \retval CLI_SHOWUSAGE on incorrect number of arguments.
|
|
|
|
* \retval NULL when tab completion is used.
|
|
|
|
*/
|
|
|
|
static char *handle_parkedcalls(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a)
|
|
|
|
{
|
|
|
|
struct parkeduser *cur;
|
|
|
|
int numparked = 0;
|
|
|
|
struct ao2_iterator iter;
|
|
|
|
struct ast_parkinglot *curlot;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case CLI_INIT:
|
|
|
|
e->command = "parkedcalls show";
|
|
|
|
e->usage =
|
|
|
|
"Usage: parkedcalls show\n"
|
|
|
|
" List currently parked calls\n";
|
|
|
|
return NULL;
|
|
|
|
case CLI_GENERATE:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (a->argc > e->args)
|
|
|
|
return CLI_SHOWUSAGE;
|
|
|
|
|
|
|
|
ast_cli(a->fd, "%-10s %-25s (%-15s %-12s %4s) %s\n", "Num", "Channel",
|
|
|
|
"Context", "Extension", "Pri", "Timeout");
|
|
|
|
|
|
|
|
iter = ao2_iterator_init(parkinglots, 0);
|
|
|
|
while ((curlot = ao2_iterator_next(&iter))) {
|
|
|
|
int lotparked = 0;
|
|
|
|
|
|
|
|
/* subtract ref for iterator and for configured parking lot */
|
|
|
|
ast_cli(a->fd, "*** Parking lot: %s (%d)\n", curlot->name,
|
|
|
|
ao2_ref(curlot, 0) - 2 - (curlot == default_parkinglot));
|
|
|
|
|
|
|
|
AST_LIST_LOCK(&curlot->parkings);
|
|
|
|
AST_LIST_TRAVERSE(&curlot->parkings, cur, list) {
|
|
|
|
ast_cli(a->fd, "%-10.10s %-25s (%-15s %-12s %4d) %6lds\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
cur->parkingexten, ast_channel_name(cur->chan), cur->context, cur->exten,
|
2011-08-16 17:23:08 +00:00
|
|
|
cur->priority,
|
|
|
|
(long) (cur->start.tv_sec + (cur->parkingtime / 1000) - time(NULL)));
|
|
|
|
++lotparked;
|
|
|
|
}
|
|
|
|
AST_LIST_UNLOCK(&curlot->parkings);
|
|
|
|
if (lotparked) {
|
|
|
|
numparked += lotparked;
|
|
|
|
ast_cli(a->fd, " %d parked call%s in parking lot %s\n", lotparked,
|
|
|
|
ESS(lotparked), curlot->name);
|
|
|
|
}
|
|
|
|
|
|
|
|
ao2_ref(curlot, -1);
|
|
|
|
}
|
|
|
|
ao2_iterator_destroy(&iter);
|
|
|
|
|
|
|
|
ast_cli(a->fd, "---\n%d parked call%s in total.\n", numparked, ESS(numparked));
|
|
|
|
|
|
|
|
return CLI_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct ast_cli_entry cli_features[] = {
|
|
|
|
AST_CLI_DEFINE(handle_feature_show, "Lists configured features"),
|
|
|
|
AST_CLI_DEFINE(handle_features_reload, "Reloads configured features"),
|
|
|
|
AST_CLI_DEFINE(handle_parkedcalls, "List currently parked calls"),
|
|
|
|
};
|
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/*!
|
2011-08-16 17:23:08 +00:00
|
|
|
* \brief Dump parking lot status
|
|
|
|
* \param s
|
|
|
|
* \param m
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2011-08-16 17:23:08 +00:00
|
|
|
* Lock parking lot, iterate list and append parked calls status, unlock parking lot.
|
2012-03-22 19:51:16 +00:00
|
|
|
* \return Always RESULT_SUCCESS
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2008-01-23 23:09:11 +00:00
|
|
|
static int manager_parking_status(struct mansession *s, const struct message *m)
|
|
|
|
{
|
|
|
|
struct parkeduser *cur;
|
|
|
|
const char *id = astman_get_header(m, "ActionID");
|
|
|
|
char idText[256] = "";
|
2008-04-21 23:42:45 +00:00
|
|
|
struct ao2_iterator iter;
|
|
|
|
struct ast_parkinglot *curlot;
|
2011-08-16 17:23:08 +00:00
|
|
|
int numparked = 0;
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
if (!ast_strlen_zero(id))
|
|
|
|
snprintf(idText, sizeof(idText), "ActionID: %s\r\n", id);
|
2006-08-31 21:00:20 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
astman_send_ack(s, m, "Parked calls will follow");
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
iter = ao2_iterator_init(parkinglots, 0);
|
|
|
|
while ((curlot = ao2_iterator_next(&iter))) {
|
|
|
|
AST_LIST_LOCK(&curlot->parkings);
|
|
|
|
AST_LIST_TRAVERSE(&curlot->parkings, cur, list) {
|
|
|
|
astman_append(s, "Event: ParkedCall\r\n"
|
2011-08-16 17:23:08 +00:00
|
|
|
"Parkinglot: %s\r\n"
|
2008-04-21 23:42:45 +00:00
|
|
|
"Exten: %d\r\n"
|
|
|
|
"Channel: %s\r\n"
|
|
|
|
"From: %s\r\n"
|
|
|
|
"Timeout: %ld\r\n"
|
|
|
|
"CallerIDNum: %s\r\n"
|
|
|
|
"CallerIDName: %s\r\n"
|
2011-05-25 17:14:11 +00:00
|
|
|
"ConnectedLineNum: %s\r\n"
|
|
|
|
"ConnectedLineName: %s\r\n"
|
2008-04-21 23:42:45 +00:00
|
|
|
"%s"
|
|
|
|
"\r\n",
|
2011-08-16 17:23:08 +00:00
|
|
|
curlot->name,
|
2012-01-09 22:15:50 +00:00
|
|
|
cur->parkingnum, ast_channel_name(cur->chan), cur->peername,
|
2008-04-21 23:42:45 +00:00
|
|
|
(long) cur->start.tv_sec + (long) (cur->parkingtime / 1000) - (long) time(NULL),
|
2012-02-29 16:52:47 +00:00
|
|
|
S_COR(ast_channel_caller(cur->chan)->id.number.valid, ast_channel_caller(cur->chan)->id.number.str, ""), /* XXX in other places it is <unknown> */
|
|
|
|
S_COR(ast_channel_caller(cur->chan)->id.name.valid, ast_channel_caller(cur->chan)->id.name.str, ""),
|
|
|
|
S_COR(ast_channel_connected(cur->chan)->id.number.valid, ast_channel_connected(cur->chan)->id.number.str, ""), /* XXX in other places it is <unknown> */
|
|
|
|
S_COR(ast_channel_connected(cur->chan)->id.name.valid, ast_channel_connected(cur->chan)->id.name.str, ""),
|
2008-04-21 23:42:45 +00:00
|
|
|
idText);
|
2011-08-16 17:23:08 +00:00
|
|
|
++numparked;
|
2008-04-21 23:42:45 +00:00
|
|
|
}
|
|
|
|
AST_LIST_UNLOCK(&curlot->parkings);
|
|
|
|
ao2_ref(curlot, -1);
|
2007-05-31 18:21:47 +00:00
|
|
|
}
|
2011-08-16 17:23:08 +00:00
|
|
|
ao2_iterator_destroy(&iter);
|
2007-05-31 18:21:47 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
astman_append(s,
|
|
|
|
"Event: ParkedCallsComplete\r\n"
|
2011-08-16 17:23:08 +00:00
|
|
|
"Total: %d\r\n"
|
2008-01-23 23:09:11 +00:00
|
|
|
"%s"
|
2011-08-16 17:23:08 +00:00
|
|
|
"\r\n",
|
|
|
|
numparked, idText);
|
2007-05-31 18:21:47 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
return RESULT_SUCCESS;
|
|
|
|
}
|
2007-05-31 18:21:47 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
/*!
|
|
|
|
* \brief Create manager event for parked calls
|
|
|
|
* \param s
|
|
|
|
* \param m
|
|
|
|
*
|
|
|
|
* Get channels involved in park, create event.
|
|
|
|
* \return Always 0
|
2011-09-07 19:35:18 +00:00
|
|
|
*
|
|
|
|
* \note ADSI is not compatible with this AMI action for the
|
|
|
|
* same reason ch2 can no longer announce the parking space.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2008-01-23 23:09:11 +00:00
|
|
|
static int manager_park(struct mansession *s, const struct message *m)
|
|
|
|
{
|
|
|
|
const char *channel = astman_get_header(m, "Channel");
|
|
|
|
const char *channel2 = astman_get_header(m, "Channel2");
|
|
|
|
const char *timeout = astman_get_header(m, "Timeout");
|
2010-09-15 19:23:56 +00:00
|
|
|
const char *parkinglotname = astman_get_header(m, "Parkinglot");
|
2008-01-23 23:09:11 +00:00
|
|
|
char buf[BUFSIZ];
|
|
|
|
int res = 0;
|
|
|
|
struct ast_channel *ch1, *ch2;
|
2011-09-07 19:35:18 +00:00
|
|
|
struct ast_park_call_args args = {
|
|
|
|
/*
|
|
|
|
* Don't say anything to ch2 since AMI is a third party parking
|
|
|
|
* a call and we will likely crash if we do.
|
|
|
|
*
|
|
|
|
* XXX When the AMI action was originally implemented, the
|
|
|
|
* parking space was announced to ch2. Unfortunately, grabbing
|
|
|
|
* the ch2 lock and holding it while the announcement is played
|
|
|
|
* was not really a good thing to do to begin with since it
|
|
|
|
* could hold up the system. Also holding the lock is no longer
|
|
|
|
* possible with a masquerade.
|
|
|
|
*
|
|
|
|
* Restoring the announcement to ch2 is not easily doable for
|
|
|
|
* the following reasons:
|
|
|
|
*
|
|
|
|
* 1) The AMI manager is not the thread processing ch2.
|
|
|
|
*
|
|
|
|
* 2) ch2 could be the same as ch1, bridged to ch1, or some
|
|
|
|
* random uninvolved channel.
|
|
|
|
*/
|
|
|
|
.flags = AST_PARK_OPT_SILENCE,
|
|
|
|
};
|
2007-06-28 19:02:31 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
if (ast_strlen_zero(channel)) {
|
|
|
|
astman_send_error(s, m, "Channel not specified");
|
|
|
|
return 0;
|
|
|
|
}
|
2007-05-31 18:21:47 +00:00
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
if (ast_strlen_zero(channel2)) {
|
|
|
|
astman_send_error(s, m, "Channel2 not specified");
|
|
|
|
return 0;
|
2007-05-31 18:21:47 +00:00
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!ast_strlen_zero(timeout)) {
|
|
|
|
if (sscanf(timeout, "%30d", &args.timeout) != 1) {
|
|
|
|
astman_send_error(s, m, "Invalid timeout value.");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!(ch1 = ast_channel_get_by_name(channel))) {
|
|
|
|
snprintf(buf, sizeof(buf), "Channel does not exist: %s", channel);
|
2008-01-23 23:09:11 +00:00
|
|
|
astman_send_error(s, m, buf);
|
|
|
|
return 0;
|
|
|
|
}
|
2007-05-31 18:21:47 +00:00
|
|
|
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
if (!(ch2 = ast_channel_get_by_name(channel2))) {
|
2008-01-23 23:09:11 +00:00
|
|
|
snprintf(buf, sizeof(buf), "Channel does not exist: %s", channel2);
|
|
|
|
astman_send_error(s, m, buf);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
ast_channel_unref(ch1);
|
2008-01-23 23:09:11 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2010-09-15 19:23:56 +00:00
|
|
|
if (!ast_strlen_zero(parkinglotname)) {
|
|
|
|
args.parkinglot = find_parkinglot(parkinglotname);
|
|
|
|
}
|
|
|
|
|
2011-10-18 21:15:45 +00:00
|
|
|
res = masq_park_call(ch1, ch2, &args);
|
2008-01-23 23:09:11 +00:00
|
|
|
if (!res) {
|
|
|
|
ast_softhangup(ch2, AST_SOFTHANGUP_EXPLICIT);
|
|
|
|
astman_send_ack(s, m, "Park successful");
|
|
|
|
} else {
|
|
|
|
astman_send_error(s, m, "Park failure");
|
2001-12-27 11:07:33 +00:00
|
|
|
}
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
if (args.parkinglot) {
|
|
|
|
parkinglot_unref(args.parkinglot);
|
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
ch1 = ast_channel_unref(ch1);
|
|
|
|
ch2 = ast_channel_unref(ch2);
|
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-06-09 16:47:07 +00:00
|
|
|
/*!
|
|
|
|
* The presence of this datastore on the channel indicates that
|
|
|
|
* someone is attemting to pickup or has picked up the channel.
|
|
|
|
* The purpose is to prevent a race between two channels
|
|
|
|
* attempting to pickup the same channel.
|
|
|
|
*/
|
|
|
|
static const struct ast_datastore_info pickup_active = {
|
2012-03-22 19:51:16 +00:00
|
|
|
.type = "pickup-active",
|
2011-06-09 16:47:07 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
int ast_can_pickup(struct ast_channel *chan)
|
|
|
|
{
|
2012-03-13 18:20:34 +00:00
|
|
|
if (!ast_channel_pbx(chan) && !ast_channel_masq(chan) && !ast_test_flag(ast_channel_flags(chan), AST_FLAG_ZOMBIE)
|
2012-02-20 23:43:27 +00:00
|
|
|
&& (ast_channel_state(chan) == AST_STATE_RINGING
|
|
|
|
|| ast_channel_state(chan) == AST_STATE_RING
|
2011-06-09 16:47:07 +00:00
|
|
|
/*
|
|
|
|
* Check the down state as well because some SIP devices do not
|
|
|
|
* give 180 ringing when they can just give 183 session progress
|
|
|
|
* instead. Issue 14005. (Some ISDN switches as well for that
|
|
|
|
* matter.)
|
|
|
|
*/
|
2012-02-20 23:43:27 +00:00
|
|
|
|| ast_channel_state(chan) == AST_STATE_DOWN)
|
2011-06-09 16:47:07 +00:00
|
|
|
&& !ast_channel_datastore_find(chan, &pickup_active, NULL)) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
static int find_channel_by_group(void *obj, void *arg, void *data, int flags)
|
|
|
|
{
|
2011-05-20 16:20:25 +00:00
|
|
|
struct ast_channel *target = obj;/*!< Potential pickup target */
|
|
|
|
struct ast_channel *chan = data;/*!< Channel wanting to pickup call */
|
|
|
|
|
|
|
|
ast_channel_lock(target);
|
2012-03-01 22:09:18 +00:00
|
|
|
if (chan != target && (ast_channel_pickupgroup(chan) & ast_channel_callgroup(target))
|
2011-06-09 16:47:07 +00:00
|
|
|
&& ast_can_pickup(target)) {
|
2011-05-20 15:52:20 +00:00
|
|
|
/* Return with the channel still locked on purpose */
|
|
|
|
return CMP_MATCH | CMP_STOP;
|
|
|
|
}
|
2011-05-20 16:20:25 +00:00
|
|
|
ast_channel_unlock(target);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
2011-05-20 15:52:20 +00:00
|
|
|
return 0;
|
2008-11-09 01:59:59 +00:00
|
|
|
}
|
|
|
|
|
2008-01-23 23:09:11 +00:00
|
|
|
/*!
|
|
|
|
* \brief Pickup a call
|
|
|
|
* \param chan channel that initiated pickup.
|
|
|
|
*
|
|
|
|
* Walk list of channels, checking it is not itself, channel is pbx one,
|
|
|
|
* check that the callgroup for both channels are the same and the channel is ringing.
|
|
|
|
* Answer calling channel, flag channel as answered on queue, masq channels together.
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
*/
|
2008-01-23 23:09:11 +00:00
|
|
|
int ast_pickup_call(struct ast_channel *chan)
|
|
|
|
{
|
2011-05-20 16:20:25 +00:00
|
|
|
struct ast_channel *target;/*!< Potential pickup target */
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
int res = -1;
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(1, "pickup attempt by %s\n", ast_channel_name(chan));
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
|
2011-05-20 15:52:20 +00:00
|
|
|
/* The found channel is already locked. */
|
|
|
|
target = ast_channel_callback(find_channel_by_group, NULL, chan, 0);
|
|
|
|
if (target) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_NOTICE, "pickup %s attempt by %s\n", ast_channel_name(target), ast_channel_name(chan));
|
2011-05-20 15:52:20 +00:00
|
|
|
|
|
|
|
res = ast_do_pickup(chan, target);
|
2011-05-27 08:37:59 +00:00
|
|
|
ast_channel_unlock(target);
|
2011-05-20 15:52:20 +00:00
|
|
|
if (!res) {
|
|
|
|
if (!ast_strlen_zero(pickupsound)) {
|
2011-05-27 08:37:59 +00:00
|
|
|
pbx_builtin_setvar_helper(target, "BRIDGE_PLAY_SOUND", pickupsound);
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
}
|
|
|
|
} else {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "pickup %s failed by %s\n", ast_channel_name(target), ast_channel_name(chan));
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
}
|
|
|
|
target = ast_channel_unref(target);
|
|
|
|
}
|
2009-04-03 22:41:46 +00:00
|
|
|
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
if (res < 0) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_debug(1, "No call pickup possible... for %s\n", ast_channel_name(chan));
|
2009-02-26 18:41:28 +00:00
|
|
|
if (!ast_strlen_zero(pickupfailsound)) {
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
ast_answer(chan);
|
2009-02-26 18:41:28 +00:00
|
|
|
ast_stream_and_wait(chan, pickupfailsound, "");
|
|
|
|
}
|
2008-01-23 23:09:11 +00:00
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
return res;
|
|
|
|
}
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
int ast_do_pickup(struct ast_channel *chan, struct ast_channel *target)
|
|
|
|
{
|
|
|
|
struct ast_party_connected_line connected_caller;
|
|
|
|
struct ast_channel *chans[2] = { chan, target };
|
2011-06-09 16:47:07 +00:00
|
|
|
struct ast_datastore *ds_pickup;
|
|
|
|
const char *chan_name;/*!< A masquerade changes channel names. */
|
|
|
|
const char *target_name;/*!< A masquerade changes channel names. */
|
|
|
|
int res = -1;
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
2012-01-09 22:15:50 +00:00
|
|
|
target_name = ast_strdupa(ast_channel_name(target));
|
|
|
|
ast_debug(1, "Call pickup on '%s' by '%s'\n", target_name, ast_channel_name(chan));
|
2011-06-09 16:47:07 +00:00
|
|
|
|
|
|
|
/* Mark the target to block any call pickup race. */
|
|
|
|
ds_pickup = ast_datastore_alloc(&pickup_active, NULL);
|
|
|
|
if (!ds_pickup) {
|
|
|
|
ast_log(LOG_WARNING,
|
|
|
|
"Unable to create channel datastore on '%s' for call pickup\n", target_name);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
ast_channel_datastore_add(target, ds_pickup);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
ast_party_connected_line_init(&connected_caller);
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_party_connected_line_copy(&connected_caller, ast_channel_connected(target));
|
2011-06-09 16:47:07 +00:00
|
|
|
ast_channel_unlock(target);/* The pickup race is avoided so we do not need the lock anymore. */
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
connected_caller.source = AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER;
|
2012-02-27 16:50:19 +00:00
|
|
|
if (ast_channel_connected_line_sub(NULL, chan, &connected_caller, 0) &&
|
|
|
|
ast_channel_connected_line_macro(NULL, chan, &connected_caller, 0, 0)) {
|
2010-07-14 15:48:36 +00:00
|
|
|
ast_channel_update_connected_line(chan, &connected_caller, NULL);
|
2009-06-01 20:57:31 +00:00
|
|
|
}
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
ast_party_connected_line_free(&connected_caller);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
ast_channel_lock(chan);
|
2012-01-09 22:15:50 +00:00
|
|
|
chan_name = ast_strdupa(ast_channel_name(chan));
|
2012-02-29 16:52:47 +00:00
|
|
|
ast_connected_line_copy_from_caller(&connected_caller, ast_channel_caller(chan));
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
ast_channel_unlock(chan);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
connected_caller.source = AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER;
|
|
|
|
|
2011-06-09 16:47:07 +00:00
|
|
|
ast_cel_report_event(target, AST_CEL_PICKUP, NULL, NULL, chan);
|
|
|
|
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
if (ast_answer(chan)) {
|
2011-06-09 16:47:07 +00:00
|
|
|
ast_log(LOG_WARNING, "Unable to answer '%s'\n", chan_name);
|
|
|
|
goto pickup_failed;
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_queue_control(chan, AST_CONTROL_ANSWER)) {
|
2011-06-09 16:47:07 +00:00
|
|
|
ast_log(LOG_WARNING, "Unable to queue answer on '%s'\n", chan_name);
|
|
|
|
goto pickup_failed;
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2012-03-29 23:36:37 +00:00
|
|
|
ast_channel_queue_connected_line_update(chan, &connected_caller, NULL);
|
|
|
|
|
2011-09-07 15:37:32 +00:00
|
|
|
/* setting this flag to generate a reason header in the cancel message to the ringing channel */
|
2012-03-13 18:20:34 +00:00
|
|
|
ast_set_flag(ast_channel_flags(chan), AST_FLAG_ANSWERED_ELSEWHERE);
|
2011-09-07 14:23:38 +00:00
|
|
|
|
Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-12 22:56:43 +00:00
|
|
|
if (ast_channel_masquerade(target, chan)) {
|
2011-06-09 16:47:07 +00:00
|
|
|
ast_log(LOG_WARNING, "Unable to masquerade '%s' into '%s'\n", chan_name,
|
|
|
|
target_name);
|
|
|
|
goto pickup_failed;
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
}
|
|
|
|
|
2010-01-15 21:04:34 +00:00
|
|
|
/* If you want UniqueIDs, set channelvars in manager.conf to CHANNEL(uniqueid) */
|
|
|
|
ast_manager_event_multichan(EVENT_FLAG_CALL, "Pickup", 2, chans,
|
2011-06-09 16:47:07 +00:00
|
|
|
"Channel: %s\r\n"
|
|
|
|
"TargetChannel: %s\r\n",
|
|
|
|
chan_name, target_name);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
2011-06-09 16:47:07 +00:00
|
|
|
/* Do the masquerade manually to make sure that it is completed. */
|
2011-05-20 15:52:20 +00:00
|
|
|
ast_do_masquerade(target);
|
2011-06-09 16:47:07 +00:00
|
|
|
res = 0;
|
|
|
|
|
|
|
|
pickup_failed:
|
2011-05-20 15:52:20 +00:00
|
|
|
ast_channel_lock(target);
|
2011-06-09 16:47:07 +00:00
|
|
|
if (!ast_channel_datastore_remove(target, ds_pickup)) {
|
|
|
|
ast_datastore_free(ds_pickup);
|
|
|
|
}
|
2012-03-29 23:36:37 +00:00
|
|
|
ast_party_connected_line_free(&connected_caller);
|
2011-05-20 15:52:20 +00:00
|
|
|
|
2011-06-09 16:47:07 +00:00
|
|
|
return res;
|
2005-01-10 04:03:30 +00:00
|
|
|
}
|
|
|
|
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
static char *app_bridge = "Bridge";
|
|
|
|
|
|
|
|
enum {
|
|
|
|
BRIDGE_OPT_PLAYTONE = (1 << 0),
|
2009-09-24 20:29:51 +00:00
|
|
|
OPT_CALLEE_HANGUP = (1 << 1),
|
|
|
|
OPT_CALLER_HANGUP = (1 << 2),
|
|
|
|
OPT_DURATION_LIMIT = (1 << 3),
|
|
|
|
OPT_DURATION_STOP = (1 << 4),
|
|
|
|
OPT_CALLEE_TRANSFER = (1 << 5),
|
|
|
|
OPT_CALLER_TRANSFER = (1 << 6),
|
|
|
|
OPT_CALLEE_MONITOR = (1 << 7),
|
|
|
|
OPT_CALLER_MONITOR = (1 << 8),
|
|
|
|
OPT_CALLEE_PARK = (1 << 9),
|
|
|
|
OPT_CALLER_PARK = (1 << 10),
|
|
|
|
OPT_CALLEE_KILL = (1 << 11),
|
2012-03-22 21:25:22 +00:00
|
|
|
OPT_CALLEE_GO_ON = (1 << 12),
|
2009-09-24 20:29:51 +00:00
|
|
|
};
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2009-09-24 20:29:51 +00:00
|
|
|
enum {
|
|
|
|
OPT_ARG_DURATION_LIMIT = 0,
|
|
|
|
OPT_ARG_DURATION_STOP,
|
2012-03-22 21:25:22 +00:00
|
|
|
OPT_ARG_CALLEE_GO_ON,
|
2009-09-24 20:29:51 +00:00
|
|
|
/* note: this entry _MUST_ be the last one in the enum */
|
|
|
|
OPT_ARG_ARRAY_SIZE,
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
AST_APP_OPTIONS(bridge_exec_options, BEGIN_OPTIONS
|
2009-09-24 20:29:51 +00:00
|
|
|
AST_APP_OPTION('p', BRIDGE_OPT_PLAYTONE),
|
2012-03-22 21:25:22 +00:00
|
|
|
AST_APP_OPTION_ARG('F', OPT_CALLEE_GO_ON, OPT_ARG_CALLEE_GO_ON),
|
2009-09-24 20:29:51 +00:00
|
|
|
AST_APP_OPTION('h', OPT_CALLEE_HANGUP),
|
|
|
|
AST_APP_OPTION('H', OPT_CALLER_HANGUP),
|
|
|
|
AST_APP_OPTION('k', OPT_CALLEE_PARK),
|
|
|
|
AST_APP_OPTION('K', OPT_CALLER_PARK),
|
|
|
|
AST_APP_OPTION_ARG('L', OPT_DURATION_LIMIT, OPT_ARG_DURATION_LIMIT),
|
|
|
|
AST_APP_OPTION_ARG('S', OPT_DURATION_STOP, OPT_ARG_DURATION_STOP),
|
|
|
|
AST_APP_OPTION('t', OPT_CALLEE_TRANSFER),
|
|
|
|
AST_APP_OPTION('T', OPT_CALLER_TRANSFER),
|
|
|
|
AST_APP_OPTION('w', OPT_CALLEE_MONITOR),
|
|
|
|
AST_APP_OPTION('W', OPT_CALLER_MONITOR),
|
|
|
|
AST_APP_OPTION('x', OPT_CALLEE_KILL),
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
END_OPTIONS );
|
|
|
|
|
2009-09-24 20:29:51 +00:00
|
|
|
int ast_bridge_timelimit(struct ast_channel *chan, struct ast_bridge_config *config,
|
|
|
|
char *parse, struct timeval *calldurationlimit)
|
|
|
|
{
|
|
|
|
char *stringp = ast_strdupa(parse);
|
|
|
|
char *limit_str, *warning_str, *warnfreq_str;
|
|
|
|
const char *var;
|
|
|
|
int play_to_caller = 0, play_to_callee = 0;
|
|
|
|
int delta;
|
|
|
|
|
|
|
|
limit_str = strsep(&stringp, ":");
|
|
|
|
warning_str = strsep(&stringp, ":");
|
|
|
|
warnfreq_str = strsep(&stringp, ":");
|
|
|
|
|
|
|
|
config->timelimit = atol(limit_str);
|
|
|
|
if (warning_str)
|
|
|
|
config->play_warning = atol(warning_str);
|
|
|
|
if (warnfreq_str)
|
|
|
|
config->warning_freq = atol(warnfreq_str);
|
|
|
|
|
|
|
|
if (!config->timelimit) {
|
|
|
|
ast_log(LOG_WARNING, "Bridge does not accept L(%s), hanging up.\n", limit_str);
|
|
|
|
config->timelimit = config->play_warning = config->warning_freq = 0;
|
|
|
|
config->warning_sound = NULL;
|
|
|
|
return -1; /* error */
|
|
|
|
} else if ( (delta = config->play_warning - config->timelimit) > 0) {
|
|
|
|
int w = config->warning_freq;
|
|
|
|
|
2011-08-09 23:17:13 +00:00
|
|
|
/*
|
|
|
|
* If the first warning is requested _after_ the entire call
|
|
|
|
* would end, and no warning frequency is requested, then turn
|
|
|
|
* off the warning. If a warning frequency is requested, reduce
|
|
|
|
* the 'first warning' time by that frequency until it falls
|
|
|
|
* within the call's total time limit.
|
|
|
|
*
|
|
|
|
* Graphically:
|
|
|
|
* timelim->| delta |<-playwarning
|
|
|
|
* 0__________________|_________________|
|
|
|
|
* | w | | | |
|
|
|
|
*
|
|
|
|
* so the number of intervals to cut is 1+(delta-1)/w
|
|
|
|
*/
|
2009-09-24 20:29:51 +00:00
|
|
|
if (w == 0) {
|
|
|
|
config->play_warning = 0;
|
|
|
|
} else {
|
|
|
|
config->play_warning -= w * ( 1 + (delta-1)/w );
|
|
|
|
if (config->play_warning < 1)
|
|
|
|
config->play_warning = config->warning_freq = 0;
|
|
|
|
}
|
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2009-09-24 20:29:51 +00:00
|
|
|
ast_channel_lock(chan);
|
|
|
|
|
|
|
|
var = pbx_builtin_getvar_helper(chan, "LIMIT_PLAYAUDIO_CALLER");
|
|
|
|
play_to_caller = var ? ast_true(var) : 1;
|
|
|
|
|
|
|
|
var = pbx_builtin_getvar_helper(chan, "LIMIT_PLAYAUDIO_CALLEE");
|
|
|
|
play_to_callee = var ? ast_true(var) : 0;
|
|
|
|
|
|
|
|
if (!play_to_caller && !play_to_callee)
|
|
|
|
play_to_caller = 1;
|
|
|
|
|
|
|
|
var = pbx_builtin_getvar_helper(chan, "LIMIT_WARNING_FILE");
|
|
|
|
config->warning_sound = !ast_strlen_zero(var) ? ast_strdup(var) : ast_strdup("timeleft");
|
|
|
|
|
|
|
|
/* The code looking at config wants a NULL, not just "", to decide
|
|
|
|
* that the message should not be played, so we replace "" with NULL.
|
|
|
|
* Note, pbx_builtin_getvar_helper _can_ return NULL if the variable is
|
|
|
|
* not found.
|
|
|
|
*/
|
|
|
|
|
|
|
|
var = pbx_builtin_getvar_helper(chan, "LIMIT_TIMEOUT_FILE");
|
|
|
|
config->end_sound = !ast_strlen_zero(var) ? ast_strdup(var) : NULL;
|
|
|
|
|
|
|
|
var = pbx_builtin_getvar_helper(chan, "LIMIT_CONNECT_FILE");
|
|
|
|
config->start_sound = !ast_strlen_zero(var) ? ast_strdup(var) : NULL;
|
|
|
|
|
|
|
|
ast_channel_unlock(chan);
|
|
|
|
|
|
|
|
/* undo effect of S(x) in case they are both used */
|
|
|
|
calldurationlimit->tv_sec = 0;
|
|
|
|
calldurationlimit->tv_usec = 0;
|
|
|
|
|
|
|
|
/* more efficient to do it like S(x) does since no advanced opts */
|
|
|
|
if (!config->play_warning && !config->start_sound && !config->end_sound && config->timelimit) {
|
|
|
|
calldurationlimit->tv_sec = config->timelimit / 1000;
|
|
|
|
calldurationlimit->tv_usec = (config->timelimit % 1000) * 1000;
|
|
|
|
ast_verb(3, "Setting call duration limit to %.3lf seconds.\n",
|
|
|
|
calldurationlimit->tv_sec + calldurationlimit->tv_usec / 1000000.0);
|
|
|
|
config->timelimit = play_to_caller = play_to_callee =
|
|
|
|
config->play_warning = config->warning_freq = 0;
|
|
|
|
} else {
|
2010-01-18 22:31:25 +00:00
|
|
|
ast_verb(4, "Limit Data for this call:\n");
|
|
|
|
ast_verb(4, "timelimit = %ld ms (%.3lf s)\n", config->timelimit, config->timelimit / 1000.0);
|
|
|
|
ast_verb(4, "play_warning = %ld ms (%.3lf s)\n", config->play_warning, config->play_warning / 1000.0);
|
2009-09-24 20:29:51 +00:00
|
|
|
ast_verb(4, "play_to_caller = %s\n", play_to_caller ? "yes" : "no");
|
|
|
|
ast_verb(4, "play_to_callee = %s\n", play_to_callee ? "yes" : "no");
|
2010-01-18 22:31:25 +00:00
|
|
|
ast_verb(4, "warning_freq = %ld ms (%.3lf s)\n", config->warning_freq, config->warning_freq / 1000.0);
|
2009-09-24 20:29:51 +00:00
|
|
|
ast_verb(4, "start_sound = %s\n", S_OR(config->start_sound, ""));
|
|
|
|
ast_verb(4, "warning_sound = %s\n", config->warning_sound);
|
|
|
|
ast_verb(4, "end_sound = %s\n", S_OR(config->end_sound, ""));
|
|
|
|
}
|
|
|
|
if (play_to_caller)
|
|
|
|
ast_set_flag(&(config->features_caller), AST_FEATURE_PLAY_WARNING);
|
|
|
|
if (play_to_callee)
|
|
|
|
ast_set_flag(&(config->features_callee), AST_FEATURE_PLAY_WARNING);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2007-08-07 23:04:01 +00:00
|
|
|
/*!
|
|
|
|
* \brief Bridge channels
|
|
|
|
* \param chan
|
2007-09-05 16:31:39 +00:00
|
|
|
* \param data channel to bridge with.
|
2012-03-22 19:51:16 +00:00
|
|
|
*
|
2007-08-07 23:04:01 +00:00
|
|
|
* Split data, check we aren't bridging with ourself, check valid channel,
|
|
|
|
* answer call if not already, check compatible channels, setup bridge config
|
|
|
|
* now bridge call, if transfered party hangs up return to PBX extension.
|
2011-05-20 17:04:53 +00:00
|
|
|
*/
|
2009-05-21 21:13:09 +00:00
|
|
|
static int bridge_exec(struct ast_channel *chan, const char *data)
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
{
|
2009-11-13 20:42:03 +00:00
|
|
|
struct ast_channel *current_dest_chan, *final_dest_chan, *chans[2];
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
char *tmp_data = NULL;
|
|
|
|
struct ast_flags opts = { 0, };
|
|
|
|
struct ast_bridge_config bconfig = { { 0, }, };
|
2009-09-24 20:29:51 +00:00
|
|
|
char *opt_args[OPT_ARG_ARRAY_SIZE];
|
|
|
|
struct timeval calldurationlimit = { 0, };
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
|
|
|
AST_DECLARE_APP_ARGS(args,
|
|
|
|
AST_APP_ARG(dest_chan);
|
|
|
|
AST_APP_ARG(options);
|
|
|
|
);
|
2012-03-22 19:51:16 +00:00
|
|
|
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
if (ast_strlen_zero(data)) {
|
|
|
|
ast_log(LOG_WARNING, "Bridge require at least 1 argument specifying the other end of the bridge\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
tmp_data = ast_strdupa(data);
|
|
|
|
AST_STANDARD_APP_ARGS(args, tmp_data);
|
|
|
|
if (!ast_strlen_zero(args.options))
|
2009-09-24 20:29:51 +00:00
|
|
|
ast_app_parse_options(bridge_exec_options, &opts, opt_args, args.options);
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
|
|
|
/* avoid bridge with ourselves */
|
2012-01-09 22:15:50 +00:00
|
|
|
if (!strcmp(ast_channel_name(chan), args.dest_chan)) {
|
|
|
|
ast_log(LOG_WARNING, "Unable to bridge channel %s with itself\n", ast_channel_name(chan));
|
2009-11-13 20:42:03 +00:00
|
|
|
ast_manager_event(chan, EVENT_FLAG_CALL, "BridgeExec",
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
"Response: Failed\r\n"
|
|
|
|
"Reason: Unable to bridge channel to itself\r\n"
|
|
|
|
"Channel1: %s\r\n"
|
|
|
|
"Channel2: %s\r\n",
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_channel_name(chan), args.dest_chan);
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
pbx_builtin_setvar_helper(chan, "BRIDGERESULT", "LOOP");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* make sure we have a valid end point */
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
if (!(current_dest_chan = ast_channel_get_by_name_prefix(args.dest_chan,
|
|
|
|
strlen(args.dest_chan)))) {
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_log(LOG_WARNING, "Bridge failed because channel %s does not exists or we "
|
|
|
|
"cannot get its lock\n", args.dest_chan);
|
2009-11-13 20:42:03 +00:00
|
|
|
ast_manager_event(chan, EVENT_FLAG_CALL, "BridgeExec",
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
"Response: Failed\r\n"
|
|
|
|
"Reason: Cannot grab end point\r\n"
|
|
|
|
"Channel1: %s\r\n"
|
2012-01-09 22:15:50 +00:00
|
|
|
"Channel2: %s\r\n", ast_channel_name(chan), args.dest_chan);
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
pbx_builtin_setvar_helper(chan, "BRIDGERESULT", "NONEXISTENT");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* answer the channel if needed */
|
2012-02-20 23:43:27 +00:00
|
|
|
if (ast_channel_state(current_dest_chan) != AST_STATE_UP) {
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_answer(current_dest_chan);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
}
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
|
|
|
/* try to allocate a place holder where current_dest_chan will be placed */
|
2012-03-22 19:51:16 +00:00
|
|
|
if (!(final_dest_chan = ast_channel_alloc(0, AST_STATE_DOWN, NULL, NULL, NULL,
|
2012-01-24 20:12:09 +00:00
|
|
|
NULL, NULL, ast_channel_linkedid(current_dest_chan), 0, "Bridge/%s", ast_channel_name(current_dest_chan)))) {
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_log(LOG_WARNING, "Cannot create placeholder channel for chan %s\n", args.dest_chan);
|
2009-11-13 20:42:03 +00:00
|
|
|
ast_manager_event(chan, EVENT_FLAG_CALL, "BridgeExec",
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
"Response: Failed\r\n"
|
|
|
|
"Reason: cannot create placeholder\r\n"
|
|
|
|
"Channel1: %s\r\n"
|
2012-01-09 22:15:50 +00:00
|
|
|
"Channel2: %s\r\n", ast_channel_name(chan), args.dest_chan);
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
}
|
|
|
|
|
2009-10-07 22:58:38 +00:00
|
|
|
do_bridge_masquerade(current_dest_chan, final_dest_chan);
|
|
|
|
|
2009-11-13 20:42:03 +00:00
|
|
|
chans[0] = current_dest_chan;
|
|
|
|
chans[1] = final_dest_chan;
|
|
|
|
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
/* now current_dest_chan is a ZOMBIE and with softhangup set to 1 and final_dest_chan is our end point */
|
|
|
|
/* try to make compatible, send error if we fail */
|
|
|
|
if (ast_channel_make_compatible(chan, final_dest_chan) < 0) {
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Could not make channels %s and %s compatible for bridge\n", ast_channel_name(chan), ast_channel_name(final_dest_chan));
|
2009-11-13 20:42:03 +00:00
|
|
|
ast_manager_event_multichan(EVENT_FLAG_CALL, "BridgeExec", 2, chans,
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
"Response: Failed\r\n"
|
|
|
|
"Reason: Could not make channels compatible for bridge\r\n"
|
|
|
|
"Channel1: %s\r\n"
|
2012-01-09 22:15:50 +00:00
|
|
|
"Channel2: %s\r\n", ast_channel_name(chan), ast_channel_name(final_dest_chan));
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_hangup(final_dest_chan); /* may be we should return this channel to the PBX? */
|
|
|
|
pbx_builtin_setvar_helper(chan, "BRIDGERESULT", "INCOMPATIBLE");
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
current_dest_chan = ast_channel_unref(current_dest_chan);
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Report that the bridge will be successfull */
|
2009-11-13 20:42:03 +00:00
|
|
|
ast_manager_event_multichan(EVENT_FLAG_CALL, "BridgeExec", 2, chans,
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
"Response: Success\r\n"
|
|
|
|
"Channel1: %s\r\n"
|
2012-01-09 22:15:50 +00:00
|
|
|
"Channel2: %s\r\n", ast_channel_name(chan), ast_channel_name(final_dest_chan));
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2012-03-22 19:51:16 +00:00
|
|
|
/* we have 2 valid channels to bridge, now it is just a matter of setting up the bridge config and starting the bridge */
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
if (ast_test_flag(&opts, BRIDGE_OPT_PLAYTONE) && !ast_strlen_zero(xfersound)) {
|
2012-01-24 20:12:09 +00:00
|
|
|
if (!ast_streamfile(final_dest_chan, xfersound, ast_channel_language(final_dest_chan))) {
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
if (ast_waitstream(final_dest_chan, "") < 0)
|
2012-01-09 22:15:50 +00:00
|
|
|
ast_log(LOG_WARNING, "Failed to play courtesy tone on %s\n", ast_channel_name(final_dest_chan));
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
}
|
|
|
|
}
|
2012-03-22 19:51:16 +00:00
|
|
|
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
current_dest_chan = ast_channel_unref(current_dest_chan);
|
2012-03-22 19:51:16 +00:00
|
|
|
|
2009-09-24 20:29:51 +00:00
|
|
|
if (ast_test_flag(&opts, OPT_DURATION_LIMIT) && !ast_strlen_zero(opt_args[OPT_ARG_DURATION_LIMIT])) {
|
|
|
|
if (ast_bridge_timelimit(chan, &bconfig, opt_args[OPT_ARG_DURATION_LIMIT], &calldurationlimit))
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLEE_TRANSFER))
|
|
|
|
ast_set_flag(&(bconfig.features_callee), AST_FEATURE_REDIRECT);
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLER_TRANSFER))
|
|
|
|
ast_set_flag(&(bconfig.features_caller), AST_FEATURE_REDIRECT);
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLEE_HANGUP))
|
|
|
|
ast_set_flag(&(bconfig.features_callee), AST_FEATURE_DISCONNECT);
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLER_HANGUP))
|
|
|
|
ast_set_flag(&(bconfig.features_caller), AST_FEATURE_DISCONNECT);
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLEE_MONITOR))
|
|
|
|
ast_set_flag(&(bconfig.features_callee), AST_FEATURE_AUTOMON);
|
2011-02-04 16:55:39 +00:00
|
|
|
if (ast_test_flag(&opts, OPT_CALLER_MONITOR))
|
2009-09-24 20:29:51 +00:00
|
|
|
ast_set_flag(&(bconfig.features_caller), AST_FEATURE_AUTOMON);
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLEE_PARK))
|
|
|
|
ast_set_flag(&(bconfig.features_callee), AST_FEATURE_PARKCALL);
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLER_PARK))
|
|
|
|
ast_set_flag(&(bconfig.features_caller), AST_FEATURE_PARKCALL);
|
Convert the ast_channel data structure over to the astobj2 framework.
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-04-24 14:04:26 +00:00
|
|
|
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_bridge_call(chan, final_dest_chan, &bconfig);
|
|
|
|
|
|
|
|
/* the bridge has ended, set BRIDGERESULT to SUCCESS. If the other channel has not been hung up, return it to the PBX */
|
|
|
|
pbx_builtin_setvar_helper(chan, "BRIDGERESULT", "SUCCESS");
|
2012-03-22 21:25:22 +00:00
|
|
|
if (!ast_check_hangup(final_dest_chan)) {
|
|
|
|
if (ast_test_flag(&opts, OPT_CALLEE_GO_ON)) {
|
|
|
|
char *caller_context = ast_strdupa(ast_channel_context(chan));
|
|
|
|
char *caller_extension = ast_strdupa(ast_channel_exten(chan));
|
|
|
|
int caller_priority = ast_channel_priority(chan);
|
|
|
|
|
|
|
|
if (!ast_strlen_zero(opt_args[OPT_ARG_CALLEE_GO_ON])) {
|
|
|
|
ast_replace_subargument_delimiter(opt_args[OPT_ARG_CALLEE_GO_ON]);
|
|
|
|
/* Set current dialplan position to bridger dialplan position */
|
|
|
|
ast_goto_if_exists(final_dest_chan, caller_context, caller_extension, caller_priority);
|
|
|
|
/* Then perform the goto */
|
|
|
|
if (ast_parseable_goto(final_dest_chan, opt_args[OPT_ARG_CALLEE_GO_ON]) == AST_PBX_SUCCESS) {
|
|
|
|
ast_pbx_start(final_dest_chan);
|
|
|
|
} else {
|
|
|
|
ast_hangup(final_dest_chan);
|
|
|
|
}
|
|
|
|
} else { /* F() */
|
|
|
|
if (ast_goto_if_exists(final_dest_chan, caller_context, caller_extension, caller_priority + 1) == AST_PBX_GOTO_FAILED) {
|
|
|
|
ast_hangup(final_dest_chan);
|
|
|
|
} else {
|
|
|
|
ast_pbx_start(final_dest_chan);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (!ast_test_flag(&opts, OPT_CALLEE_KILL)) {
|
|
|
|
ast_debug(1, "starting new PBX in %s,%s,%d for chan %s\n",
|
|
|
|
ast_channel_context(final_dest_chan), ast_channel_exten(final_dest_chan),
|
|
|
|
ast_channel_priority(final_dest_chan), ast_channel_name(final_dest_chan));
|
|
|
|
|
|
|
|
if (ast_pbx_start(final_dest_chan) != AST_PBX_SUCCESS) {
|
|
|
|
ast_log(LOG_WARNING, "FAILED continuing PBX on dest chan %s\n", ast_channel_name(final_dest_chan));
|
|
|
|
ast_hangup(final_dest_chan);
|
|
|
|
} else {
|
|
|
|
ast_debug(1, "SUCCESS continuing PBX on chan %s\n", ast_channel_name(final_dest_chan));
|
|
|
|
}
|
|
|
|
}
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
} else {
|
2012-03-22 21:25:22 +00:00
|
|
|
ast_debug(1, "hangup chan %s since the other endpoint has hung up or the x flag was passed\n", ast_channel_name(final_dest_chan));
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
ast_hangup(final_dest_chan);
|
|
|
|
}
|
2009-09-24 20:29:51 +00:00
|
|
|
done:
|
|
|
|
if (bconfig.warning_sound) {
|
|
|
|
ast_free((char *)bconfig.warning_sound);
|
|
|
|
}
|
|
|
|
if (bconfig.end_sound) {
|
|
|
|
ast_free((char *)bconfig.end_sound);
|
|
|
|
}
|
|
|
|
if (bconfig.start_sound) {
|
|
|
|
ast_free((char *)bconfig.start_sound);
|
|
|
|
}
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Convert parking spaces map list to a comma separated string.
|
|
|
|
*
|
|
|
|
* \param str String buffer to fill.
|
|
|
|
* \param spaces Parking spaces map list to convert.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void create_spaces_str(struct ast_str **str, struct parking_dp_space_map *spaces)
|
2005-01-10 04:03:30 +00:00
|
|
|
{
|
2011-08-16 17:23:08 +00:00
|
|
|
const char *comma;
|
|
|
|
struct parking_dp_spaces *cur;
|
|
|
|
|
|
|
|
ast_str_reset(*str);
|
|
|
|
comma = "";
|
|
|
|
AST_LIST_TRAVERSE(spaces, cur, node) {
|
|
|
|
if (cur->start == cur->stop) {
|
|
|
|
ast_str_append(str, 0, "%s%d", comma, cur->start);
|
|
|
|
} else {
|
|
|
|
ast_str_append(str, 0, "%s%d-%d", comma, cur->start, cur->stop);
|
|
|
|
}
|
|
|
|
comma = ",";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Compare parking spaces map to what is expected.
|
|
|
|
*
|
|
|
|
* \param test Unit test context.
|
|
|
|
* \param spaces Parking spaces map list to check.
|
|
|
|
* \param expected String to compare with.
|
|
|
|
* \param what What is being compared.
|
|
|
|
*
|
|
|
|
* \retval 0 successful compare.
|
|
|
|
* \retval nonzero if failed to compare.
|
|
|
|
*/
|
|
|
|
static int check_spaces(struct ast_test *test, struct parking_dp_space_map *spaces, const char *expected, const char *what)
|
|
|
|
{
|
|
|
|
int cmp;
|
|
|
|
struct ast_str *str = ast_str_alloca(1024);
|
|
|
|
|
|
|
|
create_spaces_str(&str, spaces);
|
|
|
|
cmp = strcmp(expected, ast_str_buffer(str));
|
|
|
|
if (cmp) {
|
|
|
|
ast_test_status_update(test,
|
|
|
|
"Unexpected parking space map for %s. Expect:'%s' Got:'%s'\n",
|
|
|
|
what, expected, ast_str_buffer(str));
|
|
|
|
}
|
|
|
|
return cmp;
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Add a dead space to the dead spaces list.
|
|
|
|
*
|
|
|
|
* \param context Dead spaces list ptr pretending to be a context name ptr.
|
|
|
|
* \param space Dead space to add to the list.
|
|
|
|
*
|
|
|
|
* \return Nothing
|
|
|
|
*/
|
|
|
|
static void test_add_dead_space(const char *context, int space)
|
|
|
|
{
|
|
|
|
struct parking_dp_space_map *dead_spaces = (struct parking_dp_space_map *) context;
|
|
|
|
|
|
|
|
usage_context_add_spaces(dead_spaces, space, space, NULL, 0);
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
struct test_map {
|
|
|
|
const char *ramp;
|
|
|
|
int start;
|
|
|
|
int stop;
|
|
|
|
const char *expect;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Build a parking lot dialplan usage test map from a table.
|
|
|
|
*
|
|
|
|
* \param test Unit test context.
|
|
|
|
* \param lot Parking lot to use to build test usage map.
|
|
|
|
* \param table_name Name of passed in table.
|
|
|
|
* \param table Usage information to put in the usage map.
|
|
|
|
* \param num_entries Number of entries in the table.
|
|
|
|
*
|
|
|
|
* \retval Created context node on success.
|
|
|
|
* \retval NULL on error.
|
|
|
|
*/
|
|
|
|
static struct parking_dp_context *test_build_maps(struct ast_test *test,
|
|
|
|
struct ast_parkinglot *lot, const char *table_name, const struct test_map *table,
|
|
|
|
size_t num_entries)
|
|
|
|
{
|
|
|
|
struct parking_dp_context *ctx_node;
|
|
|
|
int cur_index = 0;
|
|
|
|
char what[40];
|
|
|
|
|
|
|
|
snprintf(what, sizeof(what), "%s[%d]", table_name, cur_index);
|
|
|
|
ast_copy_string(lot->cfg.parkext, table->ramp, sizeof(lot->cfg.parkext));
|
|
|
|
lot->cfg.parking_start = table->start;
|
|
|
|
lot->cfg.parking_stop = table->stop;
|
|
|
|
ctx_node = build_dialplan_useage_context(lot);
|
|
|
|
if (!ctx_node) {
|
|
|
|
ast_test_status_update(test, "Failed to create parking lot context map for %s\n",
|
|
|
|
what);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (check_spaces(test, &ctx_node->spaces, table->expect, what)) {
|
|
|
|
destroy_dialplan_usage_context(ctx_node);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
while (--num_entries) {
|
|
|
|
++cur_index;
|
|
|
|
++table;
|
|
|
|
snprintf(what, sizeof(what), "%s[%d]", table_name, cur_index);
|
|
|
|
ast_copy_string(lot->cfg.parkext, table->ramp, sizeof(lot->cfg.parkext));
|
|
|
|
lot->cfg.parking_start = table->start;
|
|
|
|
lot->cfg.parking_stop = table->stop;
|
|
|
|
if (dialplan_usage_add_parkinglot_data(ctx_node, lot, 1)) {
|
|
|
|
ast_test_status_update(test, "Failed to add parking lot data for %s\n", what);
|
|
|
|
destroy_dialplan_usage_context(ctx_node);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
if (check_spaces(test, &ctx_node->spaces, table->expect, what)) {
|
|
|
|
destroy_dialplan_usage_context(ctx_node);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return ctx_node;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct test_map test_old_ctx[] = {
|
|
|
|
/* The following order of building ctx is important to test adding items to the lists. */
|
|
|
|
{ "702", 14, 15, "14-15" },
|
|
|
|
{ "700", 10, 11, "10-11,14-15" },
|
|
|
|
{ "701", 18, 19, "10-11,14-15,18-19" },
|
|
|
|
{ "703", 12, 13, "10-15,18-19" },
|
|
|
|
{ "704", 16, 17, "10-19" },
|
|
|
|
|
|
|
|
/* Parking ramp and space conflicts are intended with these lines. */
|
|
|
|
{ "704", 9, 19, "9-19" },
|
|
|
|
{ "704", 9, 20, "9-20" },
|
|
|
|
{ "704", 8, 21, "8-21" },
|
|
|
|
|
|
|
|
/* Add more spaces to ctx to test removing dead parking spaces. */
|
|
|
|
{ "705", 23, 25, "8-21,23-25" },
|
|
|
|
{ "706", 28, 31, "8-21,23-25,28-31" },
|
|
|
|
{ "707", 33, 34, "8-21,23-25,28-31,33-34" },
|
|
|
|
{ "708", 38, 40, "8-21,23-25,28-31,33-34,38-40" },
|
|
|
|
{ "709", 42, 43, "8-21,23-25,28-31,33-34,38-40,42-43" },
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct test_map test_new_ctx[] = {
|
|
|
|
{ "702", 4, 5, "4-5" },
|
|
|
|
{ "704", 24, 26, "4-5,24-26" },
|
|
|
|
{ "709", 29, 30, "4-5,24-26,29-30" },
|
|
|
|
{ "710", 32, 35, "4-5,24-26,29-30,32-35" },
|
|
|
|
{ "711", 37, 39, "4-5,24-26,29-30,32-35,37-39" },
|
|
|
|
};
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Test parking dialplan usage map code.
|
|
|
|
*
|
|
|
|
* \param test Unit test context.
|
|
|
|
*
|
|
|
|
* \retval 0 on success.
|
|
|
|
* \retval -1 on error.
|
|
|
|
*/
|
|
|
|
static int test_dialplan_usage_map(struct ast_test *test)
|
|
|
|
{
|
|
|
|
struct parking_dp_context *old_ctx;
|
|
|
|
struct parking_dp_context *new_ctx;
|
|
|
|
struct ast_parkinglot *lot;
|
|
|
|
struct parking_dp_spaces *spaces;
|
|
|
|
struct parking_dp_space_map dead_spaces = AST_LIST_HEAD_NOLOCK_INIT_VALUE;
|
2005-01-10 04:03:30 +00:00
|
|
|
int res;
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_test_status_update(test, "Test parking dialplan usage map code\n");
|
|
|
|
|
|
|
|
lot = create_parkinglot("test_lot");
|
|
|
|
if (!lot) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
ast_copy_string(lot->cfg.parking_con, "test-ctx", sizeof(lot->cfg.parking_con));
|
|
|
|
lot->cfg.parkext_exclusive = 1;
|
|
|
|
|
|
|
|
ast_test_status_update(test,
|
|
|
|
"Build old_ctx map\n");
|
|
|
|
ast_log(LOG_NOTICE, "6 Ramp and space conflict warnings are expected.\n");
|
|
|
|
old_ctx = test_build_maps(test, lot, "test_old_ctx", test_old_ctx,
|
|
|
|
ARRAY_LEN(test_old_ctx));
|
|
|
|
if (!old_ctx) {
|
|
|
|
ao2_ref(lot, -1);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_test_status_update(test, "Build new_ctx map\n");
|
|
|
|
new_ctx = test_build_maps(test, lot, "test_new_ctx", test_new_ctx,
|
|
|
|
ARRAY_LEN(test_new_ctx));
|
|
|
|
if (!new_ctx) {
|
|
|
|
res = -1;
|
|
|
|
goto fail_old_ctx;
|
|
|
|
}
|
|
|
|
|
|
|
|
ast_test_status_update(test, "Test removing dead parking spaces\n");
|
|
|
|
remove_dead_spaces_usage((void *) &dead_spaces, &old_ctx->spaces,
|
|
|
|
&new_ctx->spaces, test_add_dead_space);
|
|
|
|
if (check_spaces(test, &dead_spaces, "8-21,23,28,31,40,42-43", "dead_spaces")) {
|
|
|
|
res = -1;
|
|
|
|
goto fail_dead_spaces;
|
|
|
|
}
|
|
|
|
|
|
|
|
res = 0;
|
|
|
|
|
|
|
|
fail_dead_spaces:
|
|
|
|
while ((spaces = AST_LIST_REMOVE_HEAD(&dead_spaces, node))) {
|
|
|
|
ast_free(spaces);
|
|
|
|
}
|
|
|
|
destroy_dialplan_usage_context(new_ctx);
|
|
|
|
|
|
|
|
fail_old_ctx:
|
|
|
|
destroy_dialplan_usage_context(old_ctx);
|
|
|
|
ao2_ref(lot, -1);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
static int fake_fixup(struct ast_channel *clonechan, struct ast_channel *original)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
static struct ast_channel *create_test_channel(const struct ast_channel_tech *fake_tech)
|
|
|
|
{
|
|
|
|
struct ast_channel *test_channel1;
|
|
|
|
struct ast_format tmp_fmt;
|
|
|
|
|
|
|
|
if (!(test_channel1 = ast_channel_alloc(0, AST_STATE_DOWN, NULL, NULL, NULL,
|
|
|
|
NULL, NULL, 0, 0, "TestChannel1"))) {
|
|
|
|
ast_log(LOG_WARNING, "Whoa, test channel creation failed.\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* normally this is done in the channel driver */
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_format_cap_add(ast_channel_nativeformats(test_channel1), ast_format_set(&tmp_fmt, AST_FORMAT_GSM, 0));
|
2011-08-16 17:23:08 +00:00
|
|
|
|
2012-02-24 00:32:20 +00:00
|
|
|
ast_format_set(ast_channel_writeformat(test_channel1), AST_FORMAT_GSM, 0);
|
|
|
|
ast_format_set(ast_channel_rawwriteformat(test_channel1), AST_FORMAT_GSM, 0);
|
|
|
|
ast_format_set(ast_channel_readformat(test_channel1), AST_FORMAT_GSM, 0);
|
|
|
|
ast_format_set(ast_channel_rawreadformat(test_channel1), AST_FORMAT_GSM, 0);
|
2011-08-16 17:23:08 +00:00
|
|
|
|
2012-02-20 23:43:27 +00:00
|
|
|
ast_channel_tech_set(test_channel1, fake_tech);
|
2011-08-16 17:23:08 +00:00
|
|
|
|
|
|
|
return test_channel1;
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
static int unpark_test_channel(struct ast_channel *toremove, struct ast_park_call_args *args)
|
|
|
|
{
|
|
|
|
struct ast_context *con;
|
|
|
|
struct parkeduser *pu_toremove;
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
args->pu->notquiteyet = 1; /* go ahead and stop processing the test parking */
|
|
|
|
|
|
|
|
AST_LIST_LOCK(&args->pu->parkinglot->parkings);
|
|
|
|
AST_LIST_TRAVERSE_SAFE_BEGIN(&args->pu->parkinglot->parkings, pu_toremove, list) {
|
|
|
|
if (pu_toremove == args->pu) {
|
|
|
|
AST_LIST_REMOVE_CURRENT(list);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
AST_LIST_TRAVERSE_SAFE_END;
|
|
|
|
AST_LIST_UNLOCK(&args->pu->parkinglot->parkings);
|
|
|
|
|
|
|
|
if (!pu_toremove) {
|
|
|
|
ast_log(LOG_WARNING, "Whoa, could not find parking test call!\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
con = ast_context_find(args->pu->parkinglot->cfg.parking_con);
|
|
|
|
if (con) {
|
|
|
|
if (ast_context_remove_extension2(con, args->pu->parkingexten, 1, NULL, 0)) {
|
|
|
|
ast_log(LOG_WARNING, "Whoa, failed to remove the parking extension!\n");
|
|
|
|
res = -1;
|
|
|
|
} else {
|
|
|
|
notify_metermaids(args->pu->parkingexten,
|
|
|
|
pu_toremove->parkinglot->cfg.parking_con, AST_DEVICE_NOT_INUSE);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ast_log(LOG_WARNING, "Whoa, no parking context?\n");
|
|
|
|
res = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
parkinglot_unref(pu_toremove->parkinglot);
|
|
|
|
ast_free(pu_toremove);
|
|
|
|
args->pu = NULL;
|
|
|
|
|
|
|
|
if (!res && toremove) {
|
|
|
|
ast_hangup(toremove);
|
|
|
|
}
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
#if defined(TEST_FRAMEWORK)
|
|
|
|
AST_TEST_DEFINE(features_test)
|
|
|
|
{
|
|
|
|
struct ast_channel *test_channel1 = NULL;
|
|
|
|
struct ast_channel *parked_chan = NULL;
|
|
|
|
struct ast_parkinglot *dynlot;
|
|
|
|
struct ast_park_call_args args = {
|
|
|
|
.timeout = DEFAULT_PARK_TIME,
|
|
|
|
};
|
|
|
|
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
static const struct ast_channel_tech fake_tech = {
|
|
|
|
.fixup = fake_fixup, /* silence warning from masquerade */
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char unique_lot_1[] = "myuniquetestparkinglot314";
|
|
|
|
static const char unique_lot_2[] = "myuniquetestparkinglot3141592654";
|
|
|
|
static const char unique_context_1[] = "myuniquetestcontext314";
|
|
|
|
static const char unique_context_2[] = "myuniquetestcontext3141592654";
|
|
|
|
static const char parkinglot_parkext[] = "750";
|
|
|
|
static const char parkinglot_range[] = "751-760";
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case TEST_INIT:
|
|
|
|
info->name = "features_test";
|
|
|
|
info->category = "/main/features/";
|
|
|
|
info->summary = "Features unit test";
|
|
|
|
info->description =
|
|
|
|
"Tests whether parking respects PARKINGLOT settings";
|
|
|
|
return AST_TEST_NOT_RUN;
|
|
|
|
case TEST_EXECUTE:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (test_dialplan_usage_map(test)) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* changing a config option is a bad practice, but must be done in this case */
|
|
|
|
parkeddynamic = 1;
|
|
|
|
|
|
|
|
ast_test_status_update(test, "Test parking functionality with defaults\n");
|
|
|
|
if (!(test_channel1 = create_test_channel(&fake_tech))) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
if (park_call_full(test_channel1, NULL, &args)) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
if (unpark_test_channel(test_channel1, &args)) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ast_test_status_update(test, "Check that certain parking options are respected\n");
|
|
|
|
if (!(test_channel1 = create_test_channel(&fake_tech))) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGLOT", unique_lot_1);
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGDYNCONTEXT", unique_context_1);
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGDYNEXTEN", parkinglot_parkext);
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGDYNPOS", parkinglot_range);
|
|
|
|
if (park_call_full(test_channel1, NULL, &args)) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
/* grab newly created parking lot for destruction in the end */
|
|
|
|
dynlot = args.pu->parkinglot;
|
|
|
|
if (args.pu->parkingnum != 751
|
|
|
|
|| strcmp(dynlot->name, unique_lot_1)
|
|
|
|
|| strcmp(dynlot->cfg.parking_con, unique_context_1)
|
|
|
|
|| strcmp(dynlot->cfg.parkext, parkinglot_parkext)
|
|
|
|
|| dynlot->cfg.parking_start != 751
|
|
|
|
|| dynlot->cfg.parking_stop != 760) {
|
|
|
|
ast_test_status_update(test, "Parking settings were not respected\n");
|
|
|
|
ast_test_status_update(test, "Dyn-name:%s\n", dynlot->name);
|
|
|
|
ast_test_status_update(test, "Dyn-context:%s\n", dynlot->cfg.parking_con);
|
|
|
|
ast_test_status_update(test, "Dyn-parkext:%s\n", dynlot->cfg.parkext);
|
|
|
|
ast_test_status_update(test, "Dyn-parkpos:%d-%d\n", dynlot->cfg.parking_start,
|
|
|
|
dynlot->cfg.parking_stop);
|
|
|
|
ast_test_status_update(test, "Parked in space:%d\n", args.pu->parkingnum);
|
|
|
|
if (!unpark_test_channel(test_channel1, &args)) {
|
|
|
|
test_channel1 = NULL;
|
|
|
|
}
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
} else {
|
|
|
|
ast_test_status_update(test, "Parking settings for non-masquerading park verified\n");
|
|
|
|
}
|
|
|
|
if (unpark_test_channel(test_channel1, &args)) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ast_test_status_update(test, "Check #2 that certain parking options are respected\n");
|
|
|
|
if (!(test_channel1 = create_test_channel(&fake_tech))) {
|
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGLOT", unique_lot_2);
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGDYNCONTEXT", unique_context_2);
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGDYNEXTEN", parkinglot_parkext);
|
|
|
|
pbx_builtin_setvar_helper(test_channel1, "PARKINGDYNPOS", parkinglot_range);
|
2011-10-18 21:15:45 +00:00
|
|
|
if (masq_park_call(test_channel1, NULL, &args)) {
|
2011-08-16 17:23:08 +00:00
|
|
|
res = -1;
|
|
|
|
goto exit_features_test;
|
|
|
|
}
|
|
|
|
/* hangup zombie channel */
|
|
|
|
ast_hangup(test_channel1);
|
|
|
|
test_channel1 = NULL;
|
|
|
|
|
|
|
|
dynlot = args.pu->parkinglot;
|
|
|
|
if (args.pu->parkingnum != 751
|
|
|
|
|| strcmp(dynlot->name, unique_lot_2)
|
|
|
|
|| strcmp(dynlot->cfg.parking_con, unique_context_2)
|
|
|
|
|| strcmp(dynlot->cfg.parkext, parkinglot_parkext)
|
|
|
|
|| dynlot->cfg.parking_start != 751
|
|
|
|
|| dynlot->cfg.parking_stop != 760) {
|
|
|
|
ast_test_status_update(test, "Parking settings were not respected\n");
|
|
|
|
ast_test_status_update(test, "Dyn-name:%s\n", dynlot->name);
|
|
|
|
ast_test_status_update(test, "Dyn-context:%s\n", dynlot->cfg.parking_con);
|
|
|
|
ast_test_status_update(test, "Dyn-parkext:%s\n", dynlot->cfg.parkext);
|
|
|
|
ast_test_status_update(test, "Dyn-parkpos:%d-%d\n", dynlot->cfg.parking_start,
|
|
|
|
dynlot->cfg.parking_stop);
|
|
|
|
ast_test_status_update(test, "Parked in space:%d\n", args.pu->parkingnum);
|
|
|
|
res = -1;
|
|
|
|
} else {
|
|
|
|
ast_test_status_update(test, "Parking settings for masquerading park verified\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* find the real channel */
|
|
|
|
parked_chan = ast_channel_get_by_name("TestChannel1");
|
|
|
|
if (unpark_test_channel(parked_chan, &args)) {
|
|
|
|
if (parked_chan) {
|
|
|
|
ast_hangup(parked_chan);
|
|
|
|
}
|
|
|
|
res = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
exit_features_test:
|
|
|
|
|
|
|
|
if (test_channel1) {
|
|
|
|
ast_hangup(test_channel1);
|
|
|
|
}
|
|
|
|
|
|
|
|
force_reload_load = 1;
|
|
|
|
ast_features_reload();
|
|
|
|
return res ? AST_TEST_FAIL : AST_TEST_PASS;
|
|
|
|
}
|
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
|
|
|
|
|
|
|
int ast_features_init(void)
|
|
|
|
{
|
|
|
|
int res;
|
Merge changes from team/russell/issue_5841:
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-04-10 20:44:44 +00:00
|
|
|
|
2008-04-21 23:42:45 +00:00
|
|
|
parkinglots = ao2_container_alloc(7, parkinglot_hash_cb, parkinglot_cmp_cb);
|
2011-08-16 17:23:08 +00:00
|
|
|
if (!parkinglots) {
|
|
|
|
return -1;
|
|
|
|
}
|
2005-08-23 02:22:33 +00:00
|
|
|
|
2011-08-16 17:23:08 +00:00
|
|
|
res = load_config(0);
|
|
|
|
if (res) {
|
2005-01-10 04:03:30 +00:00
|
|
|
return res;
|
2011-08-16 17:23:08 +00:00
|
|
|
}
|
2008-12-05 10:31:25 +00:00
|
|
|
ast_cli_register_multiple(cli_features, ARRAY_LEN(cli_features));
|
2004-08-08 17:15:02 +00:00
|
|
|
ast_pthread_create(&parking_thread, NULL, do_parking_thread, NULL);
|
2011-08-16 17:23:08 +00:00
|
|
|
ast_register_application2(app_bridge, bridge_exec, NULL, NULL, NULL);
|
|
|
|
res = ast_register_application2(parkedcall, parked_call_exec, NULL, NULL, NULL);
|
2004-08-03 06:31:20 +00:00
|
|
|
if (!res)
|
2008-11-01 21:10:07 +00:00
|
|
|
res = ast_register_application2(parkcall, park_call_exec, NULL, NULL, NULL);
|
2004-01-30 05:49:44 +00:00
|
|
|
if (!res) {
|
2012-03-20 17:31:28 +00:00
|
|
|
ast_manager_register_xml_core("ParkedCalls", 0, manager_parking_status);
|
|
|
|
ast_manager_register_xml_core("Park", EVENT_FLAG_CALL, manager_park);
|
|
|
|
ast_manager_register_xml_core("Bridge", EVENT_FLAG_CALL, action_bridge);
|
2004-01-30 05:49:44 +00:00
|
|
|
}
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
|
|
|
|
res |= ast_devstate_prov_add("Park", metermaidstate);
|
2011-08-09 23:17:13 +00:00
|
|
|
#if defined(TEST_FRAMEWORK)
|
2010-03-10 20:51:23 +00:00
|
|
|
res |= AST_TEST_REGISTER(features_test);
|
2011-08-09 23:17:13 +00:00
|
|
|
#endif /* defined(TEST_FRAMEWORK) */
|
METERMAIDS:
-----------
- Adding devicestate providers, a new architecture to add non-channel related
device state information, like parking lots, queues, meetmes, vending machines
and Windows 98 reboots (lots of blinking on those lights)
- Adding provider for parking lots, so you can subscribe to the status of a
parking lot
- Adding provider for meetme, so you can have a blinking lamp for a meetme
( Example: exten => edvina,hint,meetme:1234 )
- Adding support for directed parking - set the PARKINGEXTEN before you manually
call Park() and you will be parked on that space. If it's occupied, dialplan
execution will continue.
This work was sponsored by Voop A/S - www.voop.com
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@36055 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2006-06-26 16:43:21 +00:00
|
|
|
|
2001-12-27 11:07:33 +00:00
|
|
|
return res;
|
|
|
|
}
|
2012-03-29 20:01:20 +00:00
|
|
|
|